- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 15 May 2007 20:37:27 -0700
On May 15, 2007, at 5:29 PM, Ian Hickson wrote: > On Sun, 13 May 2007, Maciej Stachowiak wrote: >>> >>> (Given that you can create them yourself I'm not sure why ImageData >>> has readonly attributes, but maybe that would save some additional >>> checking...) >> >> Ironically, due to the readonly attributes you couldn't just use a >> vanilla JS object as the implementation, even though you have to >> accept >> is as a value. > > I can make them non-readonly if people want. I don't think it matters very much. >> 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. 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. <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> > 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.) Regards, Maciej
Received on Tuesday, 15 May 2007 20:37:27 UTC