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

Joe Hildebrand (jhildebr) jhildebr at cisco.com
Sat Jul 21 12:02:07 PDT 2012


Thanks for these great comments.


On 7/21/12 10:39 AM, "Julian Reschke" <julian.reschke at gmx.de> wrote:


>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 :-)

I'm happy to make that change anyway.

>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 agree with you.  If we decide to use xml2rfc as input, it might be nice
to use this format as the output anyway, so it's time well spent.

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

I like that way of characterizing it.

>   (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 :-)

In my code, but not in the text, I never modify anything inside a <pre>.
Will call it out.

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

I saw that more as a policy thing to enhance the readability of the doc.
If we think we may need to use a codepoint before it is formally adopted
(for example, if the Unicode Forum wanted to use this format), then it
would make sense to remove the requirement.

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

Agree.  There's a "pp" script in my tooling that does nothing but
pretty-print according to these rules.

>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/ ?

Yes.

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

I was hoping to avoid having to deal with the what seems like a desire
*not* to provide a stable reference on behalf of the HTML community.  This
should probably say something about the W3C, and whatever level we think
is appropriate.  "Widely-implemented at the time of publishing" may matter
quite a bit here, though.

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

I'm ok with changing this.  What do you recommend?

>3.2.4
>
>Observation: HTML5 recommends something simpler

This?

<meta charset="utf-8">


Will change.

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

Yes.  Tested with Chrome and FF, at least.

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

Yes.

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

So this would be invalid?

<div class='section' id='example'>
  <h2><a class='self-ref' href='#example'>1.</a> Example Section</h2>
  <p>This is a description of the example</p>
  <div class='section' id='nested'>
    <h3><a class='self-ref' href='#nested'>1.1.</a> Nested Section</h3>
    <p>This is a description of the nested section.</p>
  </div>
  <p>BAD PROSE!</p>
</div>


I'll add that.

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

>From what I'm reading from 3.2.5.1.5 of HTML (http://goo.gl/daqQJ), that's
right.  <p> contains "phrasing content", which doesn't include <ol> or
<ul>.

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

Right.  I'm not sure if this is right yet, though, particularly when
round-tripping to xml2rfc.

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

Yes.

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

Maybe.  If so, it would be more difficult to query for all of the
references of the type you want.

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

Agree, if all of the images are inlined.  If not, then it's nice for the
browser to be able to proceed in rendering before it pulls down the image.
 Maybe that doesn't matter as much as it used to when the web was young.

The tool already generates those, however.

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

We'll need to test.  I'm sure IE is going to have issues with it, much
like some of the other newer elements that folks want to use.

We're going to need to have requirements for browser support/testing.

>Wrapping up...
>
>Question: no support for index generation?

I'm not sure how important indexes are in environments that have search
affordances, so I didn't prioritize that.

If you'd like to point me to a use case, I'll figure something out, or I'm
willing to accept a pull request.

-- 
Joe Hildebrand



 



More information about the rfc-interest mailing list