Re: [whatwg] HTML 5: The l (line) element
On Tue, 19 Feb 2008 11:22:32 +0100, Christoph Päper [EMAIL PROTECTED] wrote: We could also consider to reuse |br| for this purpose and thus make it magic, i.e. it is empty by default and works like it has always done, but if /br is encountered it turns the preceding br... (but not br.../) on the same nesting level from an empty into a start tag. Actually, we can't. /br is a br start tag because of legacy. I don't see why l is so compelling by the way. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] HTML 5: The l (line) element
Christoph Päper wrote: Dave Hodder: Please consider adding the 'l' element (as found in XHTML 2). I think this has been discussed (much) earlier. Anyhow. We could also consider to reuse |br| for this purpose and thus make it magic, i.e. it is empty by default and works like it has always done, but if /br is encountered it turns the preceding br... (but not br.../) on the same nesting level from an empty into a start tag. That's not possible. /br already has magic processing, at least in quirks mode. It's treated the same as br. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] reply() extension to postMessage()
Ian Hickson wrote: ...this behavior could cause some somewhat nasty infinite recursion. So what if we made reply() asynchronous so that the the reply message event doesn't need to be dispatched on the original message posting document until after the original postMessage from the sender is finished processing? This problem exists today with postMessage() too. Do people think we should go fully asynchronous? Frankly, I'm not all that worried about someone accidentally triggering infinite recursion; it's easy enough to detect (by the error that's hit? I don't know IE/Opera behaviors here), and setTimeout is easy enough to use. I think I favor sync postMessage over async because async capabilities are a strict subset of sync capabilities. You can always use setTimeout with the sync model to get async behavior; if the model is async you can't replicate sync behavior. Jeff
[whatwg] Significant changes to globalStorage
I found three more occurrences of global storage area in the current version, in 4.10.6.2 and 4.10.7.1. And a minor typo in 4.10.5: hte -- the /ralf (I hope these hints are appreciated here...)
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
On Thu, Feb 14, 2008 at 5:44 PM, Aaron Boodman [EMAIL PROTECTED] wrote: On Thu, Feb 14, 2008 at 3:05 PM, Geoffrey Garen [EMAIL PROTECTED] wrote: Since postMessage API is looking more an more like the Gears worker messaging API (or better), can we go one step further and introduce workers into the HTML5, defined as invisible windows with limited capabilities: Why call these windows at all? They seem to have no relationship physical windows, or the JavaScript window object. No relation. It might be easier for some developers to get it if associated with the window. I think it's a bit of a rough metaphor myself, and did not call the object Window in my proposal, but WorkerContext. It seems to me that this is an area where if you give an inch, the developer wants another inch. If you have something called window, then you're just moving things around - instead of saying Where is my window?, developers get to say Why can't my window do X? Since this is all new ground, it might be more reasonable to define the set of things you want to have in your worker context, and then contrive to add those things to your UI context. That way you're explaining what is there, rather than excusing what is not there. [Anvil labeled Legacy Interfaces lands on Scott's head.] -scott
Re: [whatwg] Workers in HTML5
On Tue, Feb 19, 2008 at 2:58 PM, Anne van Kesteren [EMAIL PROTECTED] wrote: Given that most people don't know the difference between the Window and the global object and the global worker object will already contain a bunch of APIs identical to those on the Window object it seems to me that giving the object and interface a different name doesn't really help. I'm not necessarily sold on making the worker context be the global object. I always thought having the Window object be the global object was a bit unfortunate, myself. What if we had separate objects: - the global scope (with all the typical JS globals, and maybe XMLHttpRequest) - workerContext (with all the worker stuff, plus cookies, location, etc) Thoughts? - a
Re: [whatwg] Workers in HTML5
On Tue, 19 Feb 2008 22:46:44 +0100, Scott Hess [EMAIL PROTECTED] wrote: It seems to me that this is an area where if you give an inch, the developer wants another inch. If you have something called window, then you're just moving things around - instead of saying Where is my window?, developers get to say Why can't my window do X? Since this is all new ground, it might be more reasonable to define the set of things you want to have in your worker context, and then contrive to add those things to your UI context. That way you're explaining what is there, rather than excusing what is not there. [Anvil labeled Legacy Interfaces lands on Scott's head.] Given that most people don't know the difference between the Window and the global object and the global worker object will already contain a bunch of APIs identical to those on the Window object it seems to me that giving the object and interface a different name doesn't really help. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Workers in HTML5
On Feb 19, 2008, at 2:57 PM, Aaron Boodman wrote: On Tue, Feb 19, 2008 at 2:58 PM, Anne van Kesteren [EMAIL PROTECTED] wrote: Given that most people don't know the difference between the Window and the global object and the global worker object will already contain a bunch of APIs identical to those on the Window object it seems to me that giving the object and interface a different name doesn't really help. I'm not necessarily sold on making the worker context be the global object. I always thought having the Window object be the global object was a bit unfortunate, myself. What if we had separate objects: - the global scope (with all the typical JS globals, and maybe XMLHttpRequest) - workerContext (with all the worker stuff, plus cookies, location, etc) Thoughts? If XMLHttpRequest is one of the APIs available on background threads, does that include its XML parsing/serialization features (responseXML and the ability to pass a Document as the post data)? If so, then effectively the whole DOM API has to be available on the background thread, which may increase the implementation complexity a fair bit over having only selected APIs available. Regards, Maciej
Re: [whatwg] Workers in HTML5
On Tue, Feb 19, 2008 at 6:05 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: If XMLHttpRequest is one of the APIs available on background threads, does that include its XML parsing/serialization features (responseXML and the ability to pass a Document as the post data)? If so, then effectively the whole DOM API has to be available on the background thread, which may increase the implementation complexity a fair bit over having only selected APIs available. I think it should be spec'd with those features required. Gears probably won't implement the XML part initially. - a
[whatwg] Yet more image data questions
Hi All, I have a few more ImageData related questions (as you may have guessed from the subject) The first is relatively simple, 3.14.11.1.10 states If any of the arguments to createImageData() or getImageData() are infinite or NaN, or if either the sw or sh arguments are zero, the method must instead raise an INDEX_SIZE_ERR exception. I feel this should probably be extended to throw on negative sw and sh. Additionally sw and sh are both floats and can therefore have a fractional component, so this needs to be handled. I think we should specify the finite value clamps in device pixels, eg. If any of the arguments to createImageData() or getImageData() are infinite or NaN, or if either the sw or sh arguments are less than one when scaled to the device pixel space, the method must instead raise an INDEX_SIZE_ERR exception. The other issues relate to the data member of ImageData. Currently this is referred to as an int array, however the DOM does not define such an array, and certainly doesn't specify any kind of clamping (let alone clamping to a smaller range than that supported by the type). I think the behaviour of this array needs to be defined, and givevn that only Opera currently implements an actual ImageData type i've been looking at their implementation. Assuming we have an ImageData object with width, w and height, h then Opera provides a data member of CanvasPixelArray, with the following behaviour: * A readonly length property is provided return the value w*h*4 * Assignment to elements [0..w*h*4) (approximately) follows the behaviour defined in section 3.14.11.1.10 (assignment never throws NaN is stored a zero which i believe is preferable) * Assignment to elements outside [0..w*h*4) results in no clamping and does not alter the length property, this includes non-numeric properties * Iteration returns only the length property and those properties that have been added programmatically -- iteration does *not* include [0..w*h*4) By and large I am fine with this behaviour, although i would prefer that it were not possible to add arbitrary properties to the data array -- but i can't come up with a real justification for such a restriction :D --Oliver
