[rfc-i] RFC Format - final requirements and next steps
Iljitsch van Beijnum
iljitsch at muada.com
Wed May 16 00:47:03 PDT 2012
On 16 May 2012, at 0:44 , Ole Jacobsen wrote:
> What makes you think "the person changing the parameters" has ANY idea
> about the intent of the designer?
I didn't think that, and I'm not sure why you bring it up.
Is there a reason why readers should comply with the wishes of the designers that designed the layout in which a text appears?
I am frustrated many times a day because web designers love tiny fonts that I find unpleasant to read. Small text look better because it fills the space in a more pleasing way. But actually reading it is a bad experience, especially on today's still relatively low resolution displays where you may end up with letters that are only a handful of pixels high.
> And why do you assume that he or she
> changed ANYTHING. Lot's of these issues are badly chosen defaults,
> something somebody else picked.
That may be the case in other areas of life, but I don't think there is any reason to think this would apply to a new RFC format. I imagine that such a format would be a lot like an ebook format in the sense that the user gets to decide the font size and probably even the font type, and a lot like a web page in the sense that the user can make the display window wider and narrower. The text in RFC will reflow based on these parameters, with the exceptions of ASCII art (I assume that will still be present to some degree in the future), code fragments and other fixed width elements.
>> 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.
> Yes, ironically we DON'T do that today, but it IS done in most modern
> publishing systems, and has been done for hundreds of years.
Right, and we're trying to reinvent the RFC format, not a general purpose publishing system.
>> 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.
> Sure, but the trick is to find a source format that allows this.
> The fact that even a simple ASCII diagram can get really messed up
> if only ONE line wraps (or you chose a variable-width font) tells
> us that this isn't a simple problem to solve.
But isn't this already solved today? It's easy enough to specify that text in HTML be displayed as preformatted, so lines don't wrap, even if that means they won't fit on the display.
>> To make a parallel with the publishing world: authors don't concern
>> themselves with the layout of their books
> Whoa! Define "authors" here. I would argue that authors have exactly
> "concerned themselves with layout" since the days of Gutenberg (at
> least). The fact that we have tools that allows untrained
> non-designers to do this today is a different matter, but don't assume
> please that authors do not or should not concern themselves with
I've written books, magazine articles, RFCs, articles on big websites. In all cases, my involvement in the design ranged from minimal to non-existant. (And not because I don't have any opinions on such matters.) Obviously when the author is also the publisher this is different.
More information about the rfc-interest