[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.

3.2.1

"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, ...?)

3.2.2.

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

3.2.4

Observation: HTML5 recommends something simpler

3.2.5

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

3.2.6

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

3.2.8

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

3.2.11

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


3.2.12.2.

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 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext-rfc2629.xref>.

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.


3.3.1:

"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