[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