- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 17 May 2007 00:40:15 +0000 (UTC)
n Tue, 15 May 2007, Maciej Stachowiak wrote: > > > > > > Also, if it's meant to be required for implementations to allow > > > that, the spec should say so - it's not normally assumed that any JS > > > object with the right properties can be used anywhere that an > > > interface can be used. > > > > Isn't it? > > I wouldn't expect something like the following to work, and indeed it > does not in any browser I tried. I would not a JS object with all the > attributes and methods of the core DOM Text interface could be inserted > into the DOM and render either. > > <div id="container"> > <div id="test">test div</div> > </div> > > <script> > var myEvent = { type: "custom", target: document.getElementById("test"), > currentTarget: document > , eventPhase: 0, bubbles: true, cancelable: false, timeStamp: > Date() > , stopPropagation: function() { }, preventDefault: function() { > } > , initEvent: function(eventTypeArg, canBubbleArg, cancelableArg) > { this.type = eventTypeArg; this.bubbles = canBubbleArg; > this.cancelable = cancelableArg; } }; > > document.getElementById("container").addEventListener("custom", > function(event) { alert("event"); }, true); > document.getElementById("test").dispatchEvent(myEvent); > > </script> It seems to me based on this: http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-CustomEvent ...that at least some people expected that kind of thing to work. However, that's removed from the current DOM3 Events draft, so, ok. > It is typical for browsers to only accept objects that have the right > custom internal implementation, or in JS terms, the right value of the > [[Class]] internal property, as paramaters to DOM methods requiring a > DOM interface, except in special cases. Hm, valid point. I've added that as a requirement, and made ImageData explicitly override it. > > On Mon, 14 May 2007, Anne van Kesteren wrote: > > > > > > Just to keep this list in sync with #whatwg. It was suggested to > > > give both putImageData and getImageData a "high resolution" boolean > > > parameter which would indicate what type of ImageData object you > > > would get back. This would be fine by me. I'm not sure if that's > > > needed right away though. > > > > That's another option, indeed. We could address this when someone > > implements a high-res <canvas>. > > Done. The WebKit <canvas> implementation scales the backing store by the > Mac OS X system-wide UI scale factor. The code to create the scaled > backing store starts on line 186 of WebCore/html/HTMLCanvasElement.cpp. > See http://nightly.webkit.org for a downloadable copy. You can use > Quartz Debug.app to set the UI scale factor to something other than the > default value of 1.0. (Apple does not currently ship any systems with > the scale factor pre-set to anything but 1.0.) Do you have any experience with getImageData() and putImageData() that would help us here? I couldn't find any running non-demo code to test. If it turns out that browsers doing this ship soon, this may become a non-issue, since authors will find things break as soon as they try doing it wrong. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 16 May 2007 17:40:15 UTC