[whatwg] Canvas suggestions

[Jordan OSETE]

Hello folks at the WHATWG.
Some simple suggestions about the great <canvas> tag:


Clipping-paths:
---------------
Right now if i understand it correctly, the clip() function creates a 
new clipping path, being the intersection of the last clipping path.
I have not seen any way to actually come back to a full clipping path, 
apart from calling restore() if you have saved it before, wich forces to 
save the clipping path each time you want to modify it.
Also we can only intersect it, but not substract it or add anything to 
the current clipping path, wich are usual cliping path operations in 
drawing software.

A way to fix both would be to have some kind of property of the 
2Dcontext object to select the operation (like globalCompositeOperation 
for painting). Operations like "add", "substract", "replace", 
"intersect" and "xor" come to mind (defaulting to "intersect").


Save-restore:
-------------
Instead of having a last-in-first-out-like save-restore mecanism, why 
not return an object with save() that could be restored with restore(obj)?
Maybe changing the names of the methods to keep it backward compatible.
This would give much additionnal flexibility.

Also, maybe saving everything at once is not always needed. Independant 
save/restore methods for clipping paths, actual paths, transformations, 
stroke/fill styles and shadows (have i forgotten something?) would be 
even more versatile, and allow for better performance sometimes (saving 
only what is needed).


Color / style:
--------------
Reading colors can be complex. Right now it returns a string either in 
the form #xxxxxx or rgba(...), depending on the alpha value. It means 
the reader must be able to parse both, because he never knows if the 
color's alpha is 255 or less. Maybe always returning rgba() would be 
easier to parse? Or a second property wich would return an array of the 
integer/float RGBA values when read?


Path API:
---------
Currently, there are only ways to _set_ the last point of a subpath 
(through any of the xxxxTo() commands), but not to read it. Since it 
must be kept in the UA's memory anyway, why not have a getLastPoint() 
function? If not, it forces the user to keep himself track of the last 
point (or (s)he needs to override all of the xxxxTo functions to do that 
"transparently").

Less important, but probably easy to implement as well: relative xxxxTo 
commands. I mean relative to the last point. Maybe new functions like 
moveToRel/lineToRel/etc., or a context property "pathBase" to set the 
base for path API moves ("absolute" and "relative"). The latter would 
avoid creating thousands of functions (especially if another kind of 
coordinates must be added in the future).


Sorry for the long mail, and keep up the good work. :-)