[whatwg] Canvas Proposal: aliasClipping property

[Charles Pritchard]

My proposal for an aliasClipping property did not get much of a 
response. I suppose
this topic is really one to be mediated between Chrome and Firefox 
developers, as
they have taken two valid approaches to clipping.

Marius Gundersen writes:

"This sounds like a very good proposal, but can we extend it to include 
other
things than just drawImage? I'm not sure how useful it would be, but it
could perhaps include all the other drawing options, like stroking and
filling paths created with lineTo, arc, etc."

To Marius, I responded that indeed it would work with other things;
use a fillRect across the extent of your clipping path. And there you 
go, aliased paths.

Robert O'Callahan writes:

I think "feathered" isn't a good term. It's vary rarely used ... I would 
just have boolean property named "antialias".

To Robert:

As there are no boolean types in the Canvas spec, I thought I'd stick 
with the current theme, and use
a string. Though feathered is rarely used, I don't see why that's much 
of an issue.


To the Entire Group (Please shout at me if you are on a Chrome or 
Firefox dev-team):

I'd like to revise the proposal to again try to mediate the two 
different clipping methods.
I'd certainly like to find a common naming scheme everyone agrees with. 
I'd like to grow
this proposal to encompass the Chrome and Firefox implementations of 
globalCompositeOperation.

There are two completely different renderings for various compositon 
modes in Chrome and Firefox.
Chrome developers have certainly posted as to why they chose their 
method. Firefox devs have certainly
taken their stand. I think they're both valid operations, but I'd like 
to have some unity.

I propose that we add a property (lets find a name):
strictClipping = "loose" (default) | "strict".

The "loose" mode being the default, would be exemplified by Mozilla's 
implementations,
and the "strict" mode is well implemented by Chrome.

This would effect "clip()", source-in, source-out, destination-atop, and 
some other composition modes.
It would allow us to create aliased paths (via fillRect and clip) as 
well as add versatility to the composition
operators. Most importantly, it would unify Chrome, Firefox and WebKit 
in their Canvas implementations,
in their next release.