[rfc-i] draft-hildebrand-html-rfc

Julian Reschke julian.reschke at gmx.de
Sat Jul 21 09:39:14 PDT 2012

On 2012-07-08 00:09, Joe Hildebrand (jhildebr) wrote:
> I just submitted a -00 draft of a potential HTML format for RFCs.
> The version you want to read is here:
> http://cursive.net/draft-hildebrand-html-rfc-2012-07-07.html
> ...

Feedback on draft-hildebrand-html-rfc-2012-07-07

"HTML RFC Format"

This needs to be

"HyperText Markup Language Request For Comments Format"

(ok, just kidding :-)

Most of what follows is nitpicking; this is because I believe that most 
of the recommendations are good. We either should do this, *or* use an 
extended version of the xml2rfc vocabulary.

3.1 Syntax

- I'd start with "XML 1.0 serialization of a conforming HTML5 document 
with additional constraints"

   (moving back to strict HTML 4.01 / XHTML would be possible but would 
make SVG a bit harder to specify)

- Many of the other points then follow from the above and COULD be 
repeated, but are not required to be called out as normative

- Pretty-printing needs to be done carefully if you do have ASCII art. 
Sometimes whitespace *is* significant :-)

- "Unicode codepoints that are unassigned at the time of publication 
MUST not be used." - not sure why. Early editions of XML 1.0 tried this; 
in the end they had to give up and jsut delegate to the Unicode specs.

On the pretty-printing in general: if we want to enforce this we better 
provide tools for pretty-printing.


"The HTML comprising the document MUST be valid according to the latest 
version of the HTML specification at the publishing, starting with the 
version commonly known as HTML5."

s/at the publising/at the time of publishing/ ?

Also, "latest" is not well-defined unless we say at which standards 
level (WD, CR...) and where (W3C, ...?)


Observation: that DOCTYPE is hard to generate with some XML serializers, 
and that's why HTML5 allows alternatives.


Observation: HTML5 recommends something simpler


Question: does this (local.css) really cascade over the inlined CSS?


Maybe just stick with "emphasis" and "strong emphasis"; and then say how 
they usually get rendered.


xml2rfc enforces (per DTD) that you can't have prose following a section 
ending. We should mention that.


List containment: that's just a HTML conformance requirement, right?

This reserves IDs containing with ":" for links to references, right?

Missing: I believe we should have a standard syntax for identifiying 
specific sections in other documents; see 

The bit about normative/informative is interesting and would require an 
extension to xml2rfc when we want to preserve it... Also, one of the two 
values probably should be the default.


"The height and width attributes SHOULD be used to specify the size of 
the image in pixels."

Why? That sounds like redundant information...

<figure> is new in HTML5; not sure how legacy browsers will parse it.

Wrapping up...

Question: no support for index generation?

More information about the rfc-interest mailing list