[whatwg] Canvas spec issues

On Wed, 4 Apr 2007, Philip Taylor wrote:
> 
> Relating to data: URLs:
>
> "To prevent information leakage, the toDataURL() and getImageData() 
> methods should raise a security exception if the canvas ever had images 
> painted on it that originate from a domain other than the domain of the 
> script that painted the images onto the canvas." - is it true/obvious 
> that an image from a data: URL doesn't originate from any domain at all 
> and so it should be allowed?

No, it's neither true nor obvious (nor is it obvious that it isn't true).

I tried to make this clearer recently though, let me know if it's still 
confusing.


> Relating to gradients:
> 
> "Otherwise, if it is ... a CanvasGradient or CanvasPattern, then an 
> object supporting those interfaces must be returned. Such objects are 
> opaque and therefore only useful for assigning to other attributes or 
> for comparison to other gradients or patterns." - what does "opaque" 
> mean? It doesn't seem to be defined here.

It's a technical term meaning you can't get anything useful out of them.


> Should it be the case that "ctx.fillStyle === ctx.fillStyle" and 
> "ctx.fillStyle = grad; ctx.fillStyle === grad"? That seems necessary if 
> useful comparison is to be possible, but it doesn't seem to be what the 
> "must" statement says. And should it be that 
> "ctx.createLinearGradient(...) !== ctx.createLinearGradient(...)"?

Yes to all of those. I've tried to clarify it.


> Should it be that "ctx.fillStyle = grad; grad.addColorStop(...)" will 
> alter the currently-selected fill style, i.e. fillStyle has to store a 
> reference to the gradient instead of a copy? (If so, then "ctx.fillStyle 
> = grad; ctx.fillStyle.addColorStop(...)" should work too, which is 
> nice.)

Yes. That should be clearer now.


> "Immediately before the 0 offset and immediately after the 1 offset, 
> transparent black stops are be assumed." and "any points beyond the 
> start or end points are a transparent black."
> 
> That is not implemented interoperably [3], and it has been suggested [4] 
> that Firefox's behaviour might be better. FF extends the outermost 
> colour stops outwards forever - that is the most powerful approach, 
> since you can manually add transparent-black or black stops to reproduce 
> the behaviours of Opera (equivalent to the current spec) and Safari.

Fixed.


> One issue with FF's behaviour is what to do when a linear gradient has 
> zero length (i.e. x0,y0 == x1,y1) - it could just be defined to be 
> equivalent to the first colour stop, which seems to be what FF does.

I've made it paint nothing for now.


> What if multiple stops are added at the same offset? I would say 
> something along the lines of: "If there is already a stop at the same 
> /offset/, the new color stop must be treated as if its /offset/ is 
> greater than that of the earlier stop." i.e. the first stop added will 
> be closest to offset 0, and the last will be (infinitesimally) closest 
> to offset 1. Firefox and Opera appear to implement it that way; Safari 
> doesn't seem to have a consistent order at all. See [5].

I've effectively done that.


> Some points on pedantic standardese (given that [6] indicates it's 
> desirable to be precise about normative statements) (though I'm 
> uncertain on the correctness of some of these points, so please disagree 
> if I'm wrong):
> 
> "The width attribute defaults to 300, and the height attribute defaults 
> to 150." - should have "must"s.

The musts are in other parts of the spec. The "defaults" in this case is 
just a definition. (Equivalent to "The default is...".)


> "String comparisons should be literal and case-sensitive." - 
> s/should/must/

Fixed.


> "The save() method pushes ... The restore() method pops ... If there is 
> no saved state, the method does nothing." - should have "must"s.

Fixed.


> globalCompositeOperation: "It must be set to a value from the following 
> list ... User agents must only recognise values that exactly match the 
> values given above." - but that conflicts with the 
> vendorName-operationName extensions, because authors and UAs have to use 
> values not in that list if they're going to use that extension 
> opportunity; and the vendorName-operationName syntax is only a "should", 
> so a conforming vendor could define their own operator called e.g. 
> "moz-saturate" (or called "over" if they had a good reason) (according 
> to that "should") but nobody would be able to ever use it (according to 
> the "must"s).

That's exactly correct. Using extensions make the script non-conforming, 
but providing them doesn't make the UA non-conforming.


> "strings should be parsed as CSS <color> values" - s/should/must/

Fixed.


> The colour parsing refers to [CSS3COLOR]. No profile is described, so 
> presumably all of CSS3 Color should be supported. In that case: what 
> should "currentColor" do, since its CSS definition makes no sense here?

It makes sense -- it's the value of the 'color' property.


> (By the way, after reading CSS3 Color, I can appreciate WA1's writing 
> style and the way that it doesn't have obvious errors and omissions and 
> ABC...)

Heh. :-)


> "Immediately before the 0 offset and immediately after the 1 offset, 
> transparent black stops are be assumed." - syntax error, and should have 
> "must".

That text is now gone.


> "Once a gradient has been created (see below), stops must be placed 
> along it to define how the colors are distributed along the gradient." - 
> is that meant to be "must"? (i.e. authors are non-conforming if they 
> don't specify any stops and use the all-transparent-black behaviour.)

That should be better now.


> "attribute DOMString shadowColor; // (default black)" - later it says 
> "transparent black".
> "attribute DOMString globalCompositeOperation; // (default over)" -
> later it says "source-over".

Fixed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 14 May 2007 18:59:04 UTC