W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2006

[whatwg] Canvas lack of drawString method

From: Stefan Haustein <sh@kobjects.org>
Date: Wed, 18 Oct 2006 23:12:12 +0200
Message-ID: <453698AC.2070901@kobjects.org>
Hi Gervase,

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 
rendering?
- 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 
twice.
- 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.

Best regards,
Stefan




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...
>
> Gerv
Received on Wednesday, 18 October 2006 14:12:12 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:48 UTC