[whatwg] Canvas lack of drawString method
sh at kobjects.org
Wed Oct 18 14:12:12 PDT 2006
I think drawElement(elem) opens up a whole new can of worms:
- how would an application determine the size of the text box?
- where is the baseline position, needed for exact axis label positioning?
- there are probably issues with dynamically calculated text values
- code with lots of cross references to elements will be difficult to read
- it needs to be specified whether css properties are inherited from the
parent element of "elem".
- how much horizontal/vertical space is drawElement permitted to use for
- the implementation in actual browsers may be more complex than it
seems because of problems with internal data structures for rendering
hints and implicitly introducing the ability to render the same element
- what happens with contained plugins, canvas elements,
self-references... all this stuff needs to be well-defined
Moreover, drawElement() would not solve the drawText problem for
non-browser environments such as Rhino.
Gervase Markham wrote:
> Alfonso Baqueiro wrote:
>> The canvas component is very promising, but the lack of drawString
>> method could be a great error for its success, this lack is a huge
>> limitation, how could you resolve this problem?
> I've suggested this in the past as a solution to this problem: why not
> have a drawElement(elem) parameter?
> That way, you could build an accessible, readable version of the
> content inside the <canvas> tag, as alternative content, and copy
> labels or anything else into the <canvas> itself with
> drawElement(label). So the same content serves both as the accessible
> version and the used version.
> This would give us great flexibility, because the text you do have is
> controlled with all the power of the existing CSS and browser font
> model, obviating the need for font controls or font objects on the
> <canvas> API - which would inevitably be not as good as the CSS ones.
> And if browsers acquire downloadable font support, so does canvas.
> I would speculate wildly that it might even be easy to implement too.
> After all, I'm sure browsers have the ability to render the contents
> of a <div> tag to a drawing buffer...
More information about the whatwg