[whatwg] Still more comments and questions on Web Apps 1.0

[Henri Sivonen]

Based on the 2006-02-24 version.

5.1.1.
I think the spec should suggest shift-return as the key combo for  
inserting a line separator to make it even more clear that plain  
return should break the block.

5.1.1.
"(Updating the default* DOM attributes causes content attributs to be  
updated as well.)"

attributes

6.1.
The canvas element is characterized as a bitmap canvas. However, it  
is conceptually a vector graphics drawing context. I think the spec  
should not require bitmapping. If I had a way to inform my UA I  
intend to print, I would sure prefer the UA collecting the canvas  
drawing operation in a CGPDFContext as opposed to a CGBitmapContext  
on OS X. (Compare with what the spec itself says about requesting the  
image as image/svg+xml.)

6.1.
Is omitting the height and/or width of canvas conforming?

6.1.1.3.
WA defines xor like this: "Exclusive OR of the source and destination  
images." Apple defines it more restrictively: "Exclusive OR of the  
source and destination images. Works only with black and white images  
and is not recommended for color images."
http://developer.apple.com/documentation/AppleApplications/Reference/ 
SafariJSRef/Classes/Canvas.html#//apple_ref/doc/uid/30001240-54491

I am not an expert here, but IIRC, the underlying PDF/Quartz imaging  
model does not allow general xoring. I think it is important to  
ensure that canvas can be implemented on top a Quartz 2D drawing  
context on OS X without breaking hardware acceleration or PDF output.

6.2.
The spec doesn't name any patent-free audio format that UAs would be  
required to support as a baseline. Linear PCM in WAV or AIFF would  
probably be sufficiently safe although not really suitable for the  
network.

Vorbis can still be subject to submarine patents. MP3 and AAC  
obviously won't do. IIRC, AMR is a potential lawyer bomb as well.

This is one of the few cases where HTTP content negotiation could  
actually be useful. Perhaps the spec should remind UA implementors to  
send an Accept header that lists the audio formats supported by their  
Audio object implementation (and no other media types) when loading  
the audio data.

8.2.
"Authors interested in using SGML tools in their authoring pipeline  
are encouraged to use the XML serialisation of HTML5 instead of the  
HTML serialisation."

Since HTML5 is not an application of SGML, SGML tools are  
inappropriate. I think authors interested in using SGML tools with (X) 
HTML5 should be actively discouraged to use SGML tools and encouraged  
to use XML tools instead.

8.2.
"This specification defines the parsing rules for HTML documents,  
whether they are syntactically valid or not. "

"Valid" used loosely. :-)

8.2.
"A leading U+FEFF BYTE ORDER MARK (BOM) must be dropped if present."  
Surely it should only be dropped for encodings where the BOM acts as  
an encoding signature. That is, with UTF-8 and UTF-16 it should be  
dropped but with UTF-16LE it should count as an erroneous garbage.

8.2.1. Attribute value (unquoted) state
I think in cases where an unquoted attribute value contains  
characters that were not formally allowed in unquoted values in HTML  
4.01 the document should be considered non-conforming. That way  
keeping document conforming would be a reasonable precaution against  
hairy interactions with legacy parsers out there.

8.2.1. Comment end state
Shouldn't the Anything else branch be a parse error?

8.2.1.1.
I think an NCR expanding to zero, above the Unicode range or to a  
surrogate should be a parse error.

8.2.2.1.
"Append that character to the Document node."

Having text nodes outside the root elements is at least a bit  
surprising if nothing else.

8.2.2.3.1. and later references to the stack of open elements
It is strange and potentially confusing that the notion of top and  
bottom is reversed compared to the conventional use of those terms in  
connection to stacks.

8.2.2.3.7.
In the "after head" phase even white space implies the start of body.  
Is that intentional?

8.2.2.3.7.
The algorithms to be run on opening li, dt and dd are do not say  
anything about parse errors when elements whose end tag is not  
optional get popped. Those should, in my opinion, count as parse errors.

8.2.2.3.7.
The insertion modes pertaining to tables specify the handling of  
comment tokens as parse errors and the comments are inserted on the  
foster parent. Is that intentional? It looks like an oversight.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/