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. :-)
