[rfc-i] Graceful degradation is key, was: Re: draft-hildebrand-html-rfc

[Julian Reschke]

On 2012-07-18 20:34, Martin Rex wrote:
> Could we please stop the pointless parts of this discussion?
>
> Try to get down to requirement that are *INDEPENDENT* from xml2rfc
> does or could do.  xml2rfc contains lots of meta-data, and can be
> extended to carry even more meta-data.
>
> What meta-data is necessary to create a HTML-page that floats
> is an entirely distinct question.  The requirements for a
> submission format must be modeled on the minimum meta-information
> that is necessary to create the desired output formats.
> ...

...and other information needed in the IETF publication process. That 
includes programmatic extraction of author names, email addresses, and 
abstract (submission tool!).

> Similar for the graphics bikeshedding.  Any graphics must be optional.
> So if another document author takes over a document (I-D or RFC), but
> doesn't have support for some graphics format in his authoring tools,
> he should be OK to leave out the graphics from his revisions of the
> document.  But that only works if the original document is complete
> without the graphics in the first place.

Following that argument we should also forbid esoteric source formats 
that make it hard to take over the *text* content of a given document.

And yes, we need to be careful with graphics formats.

> I also have strong doubts about graphics and accessibility.
> ASCII arts are not better than real graphics, but the limited
> capabilities it has should be a motivator to explain as much
> as possible with text -- and the latter is "accessible".

Yes. In particular, as demonstrated by Joe H., it's worthwhile to look 
into text-based formats that can be used to generate graphics from (such 
as sequence diagrams or state machines).

> Graphics, independent of whether it is bitmaps,SVG or ascii arts,
> should not be critical to the document, but illustrative.  At least,
> ASCII arts will reproduce in all environments that can show text
> (except for environments with broken software, that fail badly when
> trying to render ASCII texts, but that is clearly buggy app software,
> and needs to be fixed at the app software level).

I think the same can be said about most bitmapped graphics formats used 
on the Web (that is, GIF and PNG).

Best regards, Julian