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
