[rfc-i] RFC Format - final requirements and next steps

Iljitsch van Beijnum iljitsch at muada.com
Tue May 15 15:13:11 PDT 2012

On 15 May 2012, at 23:52 , Ole Jacobsen wrote:

> The downside is that it 
> MAY completely ruin carefully designed and "beautiful" pages that were 
> /designed/.

I don't see how that can possibly be a downside. Obviously the person changing the parameters and thereby ruining the design thinks the ruination is an improvement, because she or he wouldn't be making the changes otherwise.

The only possible issue is if we were to prefer that RFCs always look the same, because that gives us something we find important. I think it's pretty obvious that this is not the case for the majority of the people in this discussion.

>> "Re-flowable text" naturally follows from different device sizes.

> That seems to be the current thinking, how "natural" it is I think
> we could debate, designers certainly would debate it.

I'm sure the people who design iPad magazines find it really useful to render each page to a bitmap so the output looks exactly as intended. Many users find this practice extremely frustrating.

> Artwork moves when the text reflows, or perhaps the artwork stays put
> while the text "moves" (reflows). That means you can no longer say:
> "...the diagram to the right shows..."

Do we do that today? Unless my memory is failing me I've never seen ASCII art with the text continuing beside it in an RFC.

> By "good design" I am referring to "readability" and "clarity." 
> Perhaps these are over-used terms in this context, but I would not
> want to throw out "design intent" in favor of output device 
> "flexibility". To put this a different way: I would much rather have
> a more "modern" format that looks good when printed and displays well
> on "large" screens rather than optimizing the output for my iPhone.

This is a false dichotomy. We want to move away from imposing the formatting that works best on a given output device on the file format. If the file format is flexible, it can adapt to a large range of display options. If the file format is HTML, CSS can be used to adapt it to different displays and different user preferences without the need to perform conversions or modify the original file.

To make a parallel with the publishing world: authors don't concern themselves with the layout of their books, they just tag headlines, different kinds of text, table and image captions etc etc with the right style so later the designer can apply the chosen design. The difference here is that rather than having one design, or perhaps one for print and one for the ebook, there can/will be many designs.

More information about the rfc-interest mailing list