Re: [whatwg] Still more comments and questions on Web Apps 1.0
On Sun, 10 Jun 2007, Maciej Stachowiak wrote: On Jun 8, 2007, at 6:05 PM, Ian Hickson wrote: 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... PDF can't actually do the other porter-duff operators either (except SrcOver). Instead it has a different concept of blend modes which are supposedly more general but can't actually synthesize the porter-duff operators. However, on OS X the 'xor' operator will be supported at least as well on any given graphics context as, say, SrcAtop or DestAtop. In practice what happens on graphics contexts that can't natively support the operator is that a bitmap is generated. I would recommend against dropping XOR. Ok, 'xor' remains. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Still more comments and questions on Web Apps 1.0
On Fri, 8 Jun 2007, Michel Fortin wrote: 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? I'd agree they're mostly useless in a browser context, but when reading HTML with the intent of reserializing it later, preserving the whitespace around the document type declaration, the comments and the root element can be beneficial for the readability of the final output. I'd keep them there I agree... just like XML does. Sadly it doesn't... On Sun, 10 Jun 2007, Michel Fortin wrote: In that case, I guess it'd make sense to do the same for HTML. Yeah... On Sun, 10 Jun 2007, Henri Sivonen wrote: Yes, it makes sense to do the same. Otherwise there'd be particularly esoteric non-roundtrippable case when converting from HTML5 to XHTML5 and back to HTML5. Done. But now HTML5 can't round-trip the whitespace itself... Oh well. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Still more comments and questions on Web Apps 1.0
On Sat, 09 Jun 2007 23:03:54 +0200, Michel Fortin [EMAIL PROTECTED] wrote: I don't think XML does that, actually. See the first paragraph of http://www.w3.org/TR/xml/#syntax for the reason why this is so. White space outside the the root element is markup and not text. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Still more comments and questions on Web Apps 1.0
Le 2007-06-10 à 7:05, Anne van Kesteren a écrit : On Sat, 09 Jun 2007 23:03:54 +0200, Michel Fortin [EMAIL PROTECTED] wrote: I don't think XML does that, actually. See the first paragraph of http://www.w3.org/TR/xml/#syntax for the reason why this is so. White space outside the the root element is markup and not text. Yyou're right. I was indeed missing something. Thank you. In that case, I guess it'd make sense to do the same for HTML. Oh and I've said PHP 5's parser (libxml2) treat it as text; I've just realised there was an error in my test. In reality it does ignore whitespace at the root of the document. Sorry for the confusion. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Still more comments and questions on Web Apps 1.0
On Jun 10, 2007, at 15:31, Michel Fortin wrote: Le 2007-06-10 à 7:05, Anne van Kesteren a écrit : On Sat, 09 Jun 2007 23:03:54 +0200, Michel Fortin [EMAIL PROTECTED] wrote: I don't think XML does that, actually. See the first paragraph of http://www.w3.org/TR/xml/#syntax for the reason why this is so. White space outside the the root element is markup and not text. Yyou're right. I was indeed missing something. Thank you. In that case, I guess it'd make sense to do the same for HTML. Yes, it makes sense to do the same. Otherwise there'd be particularly esoteric non-roundtrippable case when converting from HTML5 to XHTML5 and back to HTML5. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Still more comments and questions on Web Apps 1.0
On Jun 8, 2007, at 6:05 PM, Ian Hickson wrote: 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... PDF can't actually do the other porter-duff operators either (except SrcOver). Instead it has a different concept of blend modes which are supposedly more general but can't actually synthesize the porter- duff operators. However, on OS X the 'xor' operator will be supported at least as well on any given graphics context as, say, SrcAtop or DestAtop. In practice what happens on graphics contexts that can't natively support the operator is that a bitmap is generated. I would recommend against dropping XOR. Regards, Maciej
Re: [whatwg] Still more comments and questions on Web Apps 1.0
On Sat, 09 Jun 2007 04:49:56 +0200, Michel Fortin [EMAIL PROTECTED] wrote: I'd agree they're mostly useless in a browser context, but when reading HTML with the intent of reserializing it later, preserving the whitespace around the document type declaration, the comments and the root element can be beneficial for the readability of the final output. I'd keep them there, just like XML does. I don't think XML does that, actually. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Still more comments and questions on Web Apps 1.0
At least, MSXML does not preserve white space even where mixed content is allowed. I get span a/span span b/span when I XSLT span a/span span b/span . I have to type #32; for all standalone spaces. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anne van Kesteren Sent: Saturday, June 09, 2007 11:26 AM To: Michel Fortin; Ian Hickson Cc: Henri Sivonen; whatwg List Subject: Re: [whatwg] Still more comments and questions on Web Apps 1.0 On Sat, 09 Jun 2007 04:49:56 +0200, Michel Fortin [EMAIL PROTECTED] wrote: I'd agree they're mostly useless in a browser context, but when reading HTML with the intent of reserializing it later, preserving the whitespace around the document type declaration, the comments and the root element can be beneficial for the readability of the final output. I'd keep them there, just like XML does. I don't think XML does that, actually. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Still more comments and questions on Web Apps 1.0
Le 2007-06-09 à 5:26, Anne van Kesteren a écrit : On Sat, 09 Jun 2007 04:49:56 +0200, Michel Fortin [EMAIL PROTECTED] wrote: I'd agree they're mostly useless in a browser context, but when reading HTML with the intent of reserializing it later, preserving the whitespace around the document type declaration, the comments and the root element can be beneficial for the readability of the final output. I'd keep them there, just like XML does. I don't think XML does that, actually. I've tested by dumping a tree made with PHP 5's XML parser (libxml2) before adding XML to my argument. Now, if I look at the XML spec under [2.10 Whitespace Handling][1]: An XML processor MUST always pass all characters in a document that are not markup through to the application. A validating XML processor MUST also inform the application which of these characters constitute white space appearing in element content. To me, all characters in a document also includes direct children of the document node. But perhaps I'm missing something. [1]: http://www.w3.org/TR/REC-xml/#sec-white-space Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [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
Re: [whatwg] Still more comments and questions on Web Apps 1.0
Le 2007-06-08 à 21:05, Ian Hickson a écrit : 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? I'd agree they're mostly useless in a browser context, but when reading HTML with the intent of reserializing it later, preserving the whitespace around the document type declaration, the comments and the root element can be beneficial for the readability of the final output. I'd keep them there, just like XML does. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
