[whatwg] Still more comments and questions on Web Apps 1.0
Henri Sivonen
hsivonen at iki.fi
Mon Mar 20 13:48:19 PST 2006
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/
More information about the whatwg
mailing list