On Apr 15, 2007, at 11:15 AM, Jordan OSETE wrote:
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").
I think you would want different methods for these if you had them.
One reason the API works this way is that in the CoreGraphics drawing
API on the Mac, there's no way to add anything to the clip region
directly, so it would be necessary to track all the context state
manually and union paths to support these operations. The
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).
Many graphics APIs (including CoreGraphics) have a built-in LIFO
model for save/restore, so it's likely to actually lead to worse
performance to support fine-grained save/restore on such systems.
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?
Changing the property would be a compatibility risk, but
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").
If we wanted to have more introspection of paths, I think it would
make sense to have a path object and let you get one for the current
path.
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).
You can achieve relative moves by doing a translation to the current
point when drawing; this is a more general version of what your
pathBase property would do.
Regards,
Maciej
