- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 15 May 2007 01:59:04 +0000 (UTC)
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