In addition to the standard values for globalCompositeOperation (and
ignoring 'darker'), Gecko supports:
clear: The Porter-Duff 'clear' operator, which always sets the
output to rgba(0, 0, 0, 0).
over: Synonym for 'source-over'. The code says not part of spec,
kept here for compat. (It looks like FF1.5 had a broken
'source-over', and implemented 'over' like a correct 'source-over'.
'source-over' was fixed in FF2.0, and 'over' left unchanged.)
(See
http://lxr.mozilla.org/mozilla/source/content/canvas/src/nsCanvasRenderingContext2D.cpp#1703.)
WebKit supports:
clear: Same as above.
highlight: Synonym for source-over. (See
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSCompositeHighlight
- NSCompositeHighlight: Deprecated. Mapped to
NSCompositeSourceOver.)
(See
http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/platform/graphics/GraphicsTypes.cpp#L34.)
Opera is very nice and doesn't do anything wrong.
The spec clearly defines the behaviour here: any attempts to set such
values must be ignored.
'clear' is pretty useless, since it's exactly equivalent to doing
globalAlpha = 0; globalCompositeOperation = 'copy' or (depending on
the transform matrix) clearRect(0, 0, w, h). The spec already omits
the Porter-Duff 'B' operator (which sets the output to be equal to the
destination bitmap, i.e. is equivalent to not drawing anything at
all), so it does not seem reasonable to argue for adding 'clear' just
for completeness. I can't think of any other reasons for it to be
added to the spec, other than for interoperability.
As far as I can imagine, for each non-standard value, the possible
situations are:
* No content relies on that value.
= Web browsers should remove support for it: it has no purpose, and
it may result in authors accidentally using that value and becoming
confused when their code doesn't work in other browsers which will be
irritating for everyone and it will evolve into the next situation:
* Web content relies on that value.
= It should be added to the spec, because it's necessary for
handling web content.
* Non-web, browser-specific content (extensions, widgets, etc) relies
on that value, and web content doesn't.
= It should be disabled except when run in the extension/widget/etc
context, to avoid the problems as in the first case. That may cause
minor confusion to the extension/widget/etc authors about why their
code [which is relying on undocumented features] works differently if
they run it on the web instead, but that seems insignificant compared
to having interoperability problems on the web.
* Nobody cares.
= Nothing happens.
Am I missing any issues here? Would any browser developer think one of
the first three situations applies, and be willing to make the
necessary changes in that case?
--
Philip Taylor
[EMAIL PROTECTED]
