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

On Mon, 20 Mar 2006, Henri Sivonen wrote:
> 
> 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.

Done.


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

Fixed.


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

Could you elaborate on exactly what it is you think should be changed?


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

This should be clear now.


> 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

This is now defined in terms of Porter-Duff. Is that ok?


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

I can drop 'xor', I guess...


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

Wave PCM is now required. There's a defined mechanism for content 
negotiation on the client.


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

Changed.


> 8.2.
> "This specification defines the parsing rules for HTML documents, whether they
> are syntactically valid or not. "
> 
> "Valid" used loosely. :-)

No longer a problem now that we've defined "HTML validator". :-)

(let me know if you want this changed anyway)


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

Treating it as garbage will make a mess of the DOM. It seems like it would 
be very unlikely that that was intended rather than having intended the 
BOM to just be eaten despite the incantation being slightly off.

I agree it is an error (that's covered by the encoding specs and Unicode) 
but I don't see why we would want to actively go out of our way to punish 
authors in such cases.


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

I disagree. It doesn't cause ambiguities, the legacy browsers handle them 
fine, and it would just make authors think that HTML syntax was a black 
art with arbitrary rules. We have the opportunity here to clean up the 
rules, I think we should take it.


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

It is now.


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

It is now.


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

I don't disagree. Should we just drop these spaces on the floor? It 
doesn't seem like the best thing but I guess I'm not opposed. What do 
other people think?


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

I agree. I am, however, reluctant to change it at this point, lest I make 
a mistake.



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

This no longer appears to be the case.


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

Done.


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

This seems fixed now.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 8 June 2007 18:05:42 UTC