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

Sat Jul 21 13:03:31 PDT 2012

On 2012-07-21 21:02, Joe Hildebrand (jhildebr) wrote:
> ...
>> 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.

Ok.

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

Ack. Just want to make sure that we don't hardwire something into a 
hard-to-change document if we don't have to.

Which reminds me: are we ok with non-ASCII characters being represented 
by their UTF-8 encoding? For those stuck in the previous millennium we 
could simply require ASCII encoding, and use character references for 
everything non-ASCII.

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

The "WHATWG" part of the HTML community.

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

Also allow

  <!DOCTYPE html SYSTEM 'about:legacy-compat'>

(per http://dev.w3.org/html5/spec/single-page.html#the-doctype, assuming 
we want to do HTML5)

>> 3.2.4
>>
>> Observation: HTML5 recommends something simpler
>
> This?
>
> <meta charset="utf-8">
>
>
> Will change.

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.

Exactly.

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

Yes. Observation: Windows XP is approaching EOL, and on Vista, you can 
run IE9 which doesn't have this problem.

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

I think a well made index is still useful, in particular, if you (ahem) 
... print the document.

Best regards, Julian