[whatwg] Proposal to remove a paragraph from canvas spec
ian at hixie.ch
Thu May 12 20:19:38 PDT 2011
On Tue, 3 May 2011, Matthew Delaney wrote:
> The paragraph in the canvas spec that reads...
> "Shadows are only drawn if the opacity component of the alpha component
> of the color of shadowColor is non-zero and either the shadowBlur is
> non-zero, or the shadowOffsetX is non-zero, or the shadowOffsetY is
> ...I've found must have been modeled after a bug originally from
> CoreGraphics. As you can see in this simple animation of a shadow blur
> being reduced from 20 down to 0, this "edge case" outlined in the above
> paragraph produces undesirable behavior at the end of the animation:
> This outlined edge case really only affects a particular case of when
> the composite operation is set to destination-atop, which should result
> in the shadow landing "on top of" its source, and both the offsets and
> blur are of course 0. In the animation sample linked above, this case is
> the end state of the animation (the rect turning all blue all of a
> 1) This behavior is obviously not ideal (see the linked animation above)
> and is really just a bug
> 2) I can't imagine this particular edge case popping up all that often
> (think: using destination-atop and having both the shadow offsets and
> the blur 0 so that the shadow would otherwise be totally eclipsed by the
> 3) The only major browsers I've found to support this edge case are
> Firefox4 (but not versions less than 4) and CG/Skia ports of WebKit
> browsers (because this is where the bug originated)
> ...I'm proposing this:
> 1) Strip out this edge case paragraph in the spec (yay, cleaner spec!)
> 2) Notify Firefox team that they should strip out this hack in their
> code for the edge case.
> 3) Quickly fix WebKit ports
> 4) File a bug against CG on this faulty behavior (just did that) and
> hope that it can be fixed in future releases.
> 5) Ask philip/W3C nicely to update his/the test at
> I also posted more info here:
> I realize this is somewhat nit-picky, but it's clearly a bug (unless I'm
> missing something obvious) that I think we can all quickly rectify.
> Additionally, I've found a handful of other similar things in the canvas
> spec that I will write about shortly, but wanted to test the waters of
> emailing this list first to see how hard it is to push this "easier"
> issue. ;-)
On Wed, 4 May 2011, Robert O'Callahan wrote:
> See the thread "<canvas> shadow compositing oddities" from July 2008. In
> that thread, Eric Butler points out that always drawing shadows has
> problems with operators other than dest-atop. For example, with
> source-in, always drawing a fully transparent shadow would mean that
> source-in acts just like clear!
> So as well as being compatible with CG, this behavior was thought to be
> desirable because it provides a simple way for shadows to be completely
> disabled by default, without requiring authors having to explicitly
> enable shadows.
> So here are some options:
> 1) leave the spec as-is
> 2) introduce explicit API to enable/disable shadows (would break a lot
> of Web content at this point, probably not realistic)
> 3) remove the no-shadow special case, as you suggest (breaks some
> operators, probably not a good idea)
> 4) remove the no-shadow special case, but add a special case to not draw
> shadows for operators other than source-over
> I think I prefer #4. I have yet to hear of any use-case that needs
> shadows with an operator other than source-over, and it would probably
> simplify the spec and implementations a little bit.
#4 seems fine to me. Does anyone object to #4? I propose waiting until
browser vendors implement this (to test that it is not a compatibility
problem), and then updating the spec accordingly.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg