julian.reschke at gmx.de
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.
>> - "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
>> 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.
>> 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?
<!DOCTYPE html SYSTEM 'about:legacy-compat'>
(per http://dev.w3.org/html5/spec/single-page.html#the-doctype, assuming
we want to do HTML5)
>> Observation: HTML5 recommends something simpler
> <meta charset="utf-8">
> Will change.
>> 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>
> <p>BAD PROSE!</p>
> I'll add that.
>> <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
More information about the rfc-interest