[whatwg] Canvas spec issues
Ian Hickson
ian at hixie.ch
Mon May 14 18:59:04 PDT 2007
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list