- From: Philip Taylor <excors+whatwg@gmail.com>
- Date: Tue, 29 Jul 2008 14:29:03 +0100
On Sun, Jul 27, 2008 at 8:06 PM, Eric Butler <ebutler at mozilla.com> wrote: > [...] > However, following the spec's drawing model, there are a few operators that > behave rather unexpectedly if the shadow color is left at its default value. > For instance, since A in B always results in transparency if either A or B > is fully transparent, source-in will always simply clear the clipping region > to fully transparent no matter what the source and destination are. Oops - that does seem quite broken. (It's probably my fault - I didn't notice that problem when I was looking at how shadows should work...) > It would seem Safari isn't quite following the spec here, since it appears > to never draw shadows when the shadow color is fully transparent or > something and doesn't encounter these issues. As far as I can tell: It never draws shadows when shadowColor.alpha < 1/256, regardless of the other attributes. Also, it never draws shadows when blur=0 and abs(offsetX) <= 1 and abs(offsetY) <= 1, regardless of the colour. In the cases where it does draw shadows, there's also an issue that its compositor ignores the area outside the shape that's being drawn (instead of treating it as transparent-black, as is required by the spec and implemented by Opera and (usually) Firefox) - so in cases like http://philip.html5.org/demos/canvas/shadow-composite.html with the source-in mode, WebKit fails to clear the area outside the shape/shadow to transparent-black. (I'm testing with Safari 3.0.4 - I hope not much has changed since then). That is probably a sufficiently unusual situation that it's sensible for the spec to stay as it is and require WebKit to change, though the spec still needs to change for the default shadows-disabled case. -- Philip Taylor excors at gmail.com
Received on Tuesday, 29 July 2008 06:29:03 UTC