[whatwg] Text APIs on <canvas>

[Ian Hickson]

On Fri, 9 May 2008, Vladimir Vukicevic wrote:
> On May 5, 2008, at 8:10 PM, Ian Hickson wrote:
> > 
> > I have introduced the following APIs:
> > 
> >   context.font
> 
> I think this should be "textStyle" -- both to match existing fillStyle/ 
> strokeStyle, and for consistency with the rest of the text functions.

I was about to make this change when Maciej suggested keeping 'font'... 
I'll leave this open for now and see what other people think.


> > I haven't provided a way to render text to or along a path, nor a way 
> > to do vertical text, nor a way to measure anything but the nominal 
> > layout width of text (e.g. there's no way to measure bounding boxes or 
> > get baseline metrics). I also haven't provided a way to render 
> > document fragments straight to a canvas.
> 
> Rendering text to a path or along a path are both useful operations; why 
> were they omitted?

I completely agree that we want those operations.

Specifically, we want two things: rendering text along a path, and 
rendering text _to_ a path.

However, with the current API, which has just one active path, it isn't 
possible to draw text to a path that is itself drawn around a path. I 
think it would be bad to not provide this in a generic way -- we really 
just need to introduce path _objects_, at which point this all becomes 
much easier.

Path objects have been requested for other reasons (e.g. so that you can 
stamp out different paths without having to reconstruct them each time) 
and so my preference would be to delay rendering text along a path and 
text to a path until such time as we have Path objects as a primitive.

I would guess that Path objects would be the next thing that we would add 
to <canvas>.


> I don't think the restriction that "putImageData" must only work with 
> objects returned by create/get is a good one

This restriction was made because it allows for dramatic (many orders of 
magnitude) optimisations. With createImageData(), the use cases for custom 
imageData objects should be catered for -- what are the cases where you 
would need another solution? (Note that hand-rolling imageData objects is 
dangerous since you don't know what resolution the backing store is using, 
necessarily, which is something else that createImageData() solves.)


> but it would be good to have some way to mark sections of the spec as 
> stable/unstable --

I've gone through and added annotations for each of the canvas sections to 
distinguish the stable parts from the unstable parts. Does that work?


> otherwise someone's liable to take a snapshot and implement it, and then 
> have it change under them if a portion is still in flux.

In general, the spec is unlikely to change significantly _before_ the 
first implemenation. We get more feedback from the first implementation of 
anything than from people just looking at the spec. I agree that the first 
implementation should know what it's getting itself into, though. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'