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:
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.
- 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.
Question: no support for index generation?
More information about the rfc-interest