[whatwg] postMessage and serialization
Has the topic of automatic serialization and deserialization of objects passed across postMessage() come up already? It seems like boolean, number, string, arrays, and objects should be supported. I realize that you can just use a json library, but I wonder why we should force every application that wants to use postMessage() to include a json library when the browser can just do the right thing automatically. - a
Re: [whatwg] HTML 5 vs. XHTML 2.0
How should advertisements be marked up? blink -- Charles
Re: [whatwg] HTML 5 vs. XHTML 2.0
Ian Hickson wrote: On Sat, 13 Nov 2004, Henri Sivonen wrote: Anyway, I do think it's a problem for styling, automatic content extraction and non-CSS presentation that HTML lacks the markup for indicating which parts of the page are content proper and which are navigation and other chrome. Therefore, a footer element for isolating navigation and legal stuff from content would make sense. (Already suggested in http://lists.w3.org/Archives/Public/www-html/2002Aug/0229.html at the end of the message.) I hope the nav, footer, and article elements help this case. How should advertisements be marked up? - Brian
Re: [whatwg] html start tag token in the root element phase
On 29/06/2007, Henri Sivonen [EMAIL PROTECTED] wrote: If the spec dealt with the html start tag token directly in the root element phase, the parse error in the main phase wouldn't need to be conditional. (Implementations that experience a perf benefit from not mutating the attributes of a node probably want to hoist the html node creation to the root element phase for perf reasons, too.) There's also an issue with: !doctype html foo html not producing any parse error, because the html is the first start tag token (at least under my interpretation) and therefore is considered valid. Handling html specially in the root element phase seems like a reasonable way of fixing this. -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] More random comments on the putImageData definition
On Feb 11, 2008 2:57 PM, Oliver Hunt [EMAIL PROTECTED] wrote: On Feb 10, 2008, at 5:44 PM, Robert O'Callahan wrote: On Feb 11, 2008 1:05 PM, Oliver Hunt [EMAIL PROTECTED] wrote: i was thinking having a style property, say, canvas-dpi: auto|device or something, where the default auto value automagically does the evil downsampling the moment a data routine is used, and device would result in the right thing. That said neither of these are particularly nice. OTOH it would allow those who use get/putImageData to implement a basic video buffer (eg. the msx demo, etc) to continue to do so. Wouldn't it be equivalent, yet simpler, to just define get/putImageData to do the evil 'auto' thing, and have additional methods to do the right 'device' thing? Not really -- a developer would need to do work to handle browsers that did not support the newer hidpi apis. The alternative (a css property or whatever) would allow a developer to use a single API, but tell the browser that they were aware that there may not be a 1:1 ratio between the requested region and the amount of data returned -- effectively it would be a flag to say hey i actually do know the spec, and am not blindly expecting this to work on everyone else's computer just because it works on mine OK, but I wouldn't use a property, I'd use a content attribute, because you want to be able to work with canvas elements that aren't in a document and thus don't really have style. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Calendar subscription as a feed?
Dan Mosedale wrote: Dan Mosedale wrote: One nice property of the webcal: URI scheme is that any user-agent can reasonably infer the intended use (which is likely to carry the semantic that the URI will be around for a longer period of time) simply from the URI. So this URI can simply be included in any sort document (mail message, text file) without losing that bit of information. By itself, rel=feed doesn't provide this. I just skimmed the slightly (2006) Link header draft after noticing Ian mentioning it in a recent thread here, and if that were to make it back into HTTP, it would seem to solve this information loss bit nicely. Could you elaborate how one could use Link header to prevent information loss? In cases where one user sends a http://...; URI to another user in e.g. plain text email message how can a Link header prevent loss of information when compared to webcal: URI? We already have +xml suffix for mimetypes, perhaps we should also have +subscription or +feed? Or did you mean that similar information would be encoded as Link header? -- Mikko signature.asc Description: OpenPGP digital signature
Re: [whatwg] More random comments on the putImageData definition
On Feb 11, 2008, at 12:33 AM, Robert O'Callahan wrote: ... I was assuming no-one supported getImageData/putImageData during those 5 years. Then there would be no content using it that would be broken. Alas there are already sites depending on it, so we're doomed On Feb 11, 2008, at 12:37 AM, Robert O'Callahan wrote: On Feb 11, 2008 2:57 PM, Oliver Hunt [EMAIL PROTECTED] wrote: Not really -- a developer would need to do work to handle browsers that did not support the newer hidpi apis. The alternative (a css property or whatever) would allow a developer to use a single API, but tell the browser that they were aware that there may not be a 1:1 ratio between the requested region and the amount of data returned -- effectively it would be a flag to say hey i actually do know the spec, and am not blindly expecting this to work on everyone else's computer just because it works on mine OK, but I wouldn't use a property, I'd use a content attribute, because you want to be able to work with canvas elements that aren't in a document and thus don't really have style. Ah good point, i had not considered that. I agree, an attribute would probably be better (although the concept itself is still icky) Rob --Oliver
Re: [whatwg] HTML 5 vs. XHTML 2.0
On Mon, 11 Feb 2008, Brian Smith wrote: How should advertisements be marked up? aside is probably the most appropriate element at the moment. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
