W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2008

[whatwg] Canvas patterns, and miscellaneous other things

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 31 Jan 2008 02:02:42 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0801310123560.3212@hixie.dreamhostps.com>
On Sat, 23 Jun 2007, Philip Taylor wrote:
>
> What should happen if you try drawing a 0x0-pixel repeating pattern? (I 
> can't find a way to make a 0x0 image that any browser will load, but the 
> spec says you can make a 0x0 canvas. Firefox and Opera can't make a 0x0 
> canvas - it acts like it's 300x150 pixels instead. Safari returns null 
> from createPattern when it's 0x0.)

I've made this do the same as passing an incomplete Image object.


> On a somewhat related note: What should "canvas.width = canvas.height = 
> 0; canvas.toDataURL()" do, given that you can never make a valid 0x0 
> PNG? (Firefox and Opera make the canvas 300x150 pixels instead, so you 
> can't actually get it that small. Safari can make it that small, but 
> doesn't implement toDataURL.)

I've made toDataURL() return "data:," if it's faced with a 0-pixel image. 
It's arbitrary, but I guess it represents the image, at least!


> Similarly, what should toDataURL do when the canvas is really large and 
> the browser doesn't want to give you a data URI? (Opera returns 
> 'undefined' if it's >= 30001 pixels in any dimension, and crashes if 
> it's 30000 in each dimension. Firefox (2 and trunk) crashes or hangs on 
> Linux if it's >= 32768 pixels in any dimension, and crashes on Windows 
> if it's >= 65536 pixels).

User agents may impose implementation-specific limits on otherwise 
unconstrained inputs, e.g. to prevent denial of service attacks, to guard 
against running out of memory, or to work around platform-specific 
limitations. (See ...#hardwareLimitations.)


> More generally, the spec says "If the user agent does not support the 
> requested type, it must return the image using the PNG format" - what if 
> it does support the requested type, but still doesn't want to give you a 
> data URI, e.g. because it's the wrong size (too large, too small, not a 
> multiple of 4, etc) or because of other environmental factors (e.g. it 
> wants you to do getContext('vendor-2d').enableVectorCapture() before 
> toDataURL('image/svg+xml'))? (Presumably it would be some combination of 
> falling back to PNG (if you asked for something else), returning 
> undefined, and throwing exceptions.)

The spec doesn't define "support the requested type". I could definitely 
see arguing that support of the requested type is dependent upon other 
factors, so that returning a PNG is ok. Throwing exceptions in the face of 
hardware limitations (data too big) is always allowed, as noted above. 
Also, browsers could crop or extend or stretch the image if the image 
format requires a particular multiple in its output dimensions. That's 
just part of outputting the image.


> "If the empty string or null is specified, repeat must be assumed." - 
> why allow null, but not undefined or missing? (It would seem quite 
> reasonable for createPattern(img) to default to a repeating pattern). 
> (Currently all implementations throw exceptions for undefined/missing, 
> and Opera and Safari throw for null.)

'undefined' is a JS-specific thing, and I'm assuming that the DOM Bindings 
for JS spec will define how 'undefined' really means 'null'. Same with 
missing arguments.


> 'complete' for images is underspecified, so it's not possible to test 
> the related createPattern/drawImage requirements. (Is it set before 
> onload is called?

As defined, yes. I've called this out, but it was already unambiguous.


> Can it be set as soon as the Image() constructor returns?

No, since you can't have an image set from the Image() constructor (it 
doesn't take a URI argument).

(I'm aware that this doesn't match implementations.)


> Can it be set at an arbitrary point during execution of the script that 
> called the Image() constructor?

As defined, yes.


> Is it reset when you change src? [...])

Yes, according to the spec today, since the definition is dependent on 
the src attribute.

I'm not really sure I agree that it's underspecified, to be honest. 
However, feel free to raise this again if you want it changed (if possible 
in a separate e-mail).


> About radial gradients: "If x0 = x1 and y0 = y1 and r0 = r1, then the 
> radial gradient must paint nothing." - that conflicts with the previous 
> "must" for following the algorithm, so it's not precise about which you 
> must do. It should probably say "If ... then the radial gradient must 
> paint nothing. Otherwise, radial gradients must be rendered by following 
> these steps:".

Fixed.


> "<code title="dom-attr-complete">complete</code>" (twice) - looks like 
> it should be dom-img-complete, so it points to #complete.

Fixed.


> "createPattern(image, repetition)" - the parameters should be in <var>s.

Fixed.


> "The images are not be scaled by this process" - s/be //

Fixed.


> "interface HTMLCanvasElement : HTMLElement {
>          attribute unsigned long width;
>          attribute unsigned long height;"
> ^ incorrect indentation (should have two more spaces).

Fixed.


> Somewhere totally unrelated:
> "interface HTMLDetailsElement : HTMLElement {
>   attribute boolean open;"
> ^ incorrect indentation (should have nine more spaces).

Fixed.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 30 January 2008 18:02:42 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:00 UTC