[whatwg] Canvas lack of drawString method

[Stefan Haustein]

Gervase Markham wrote:
> Stefan Haustein wrote:
>> 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 answer to all of these things is that the browser renders all the 
> elements in the page as it would if the <canvas> were not supported 
> and the alternate content were being used. It then basically 
> screenshots the area corresponding to the element (yes, I know this 
> needs careful definition) and draws that into the canvas.
I do not see how your statement answers any of my questions except from 
the last one. You can specify some CSS constraints, but how do you 
determine the actual rendering height of a text box with a specific 
width? How do you determine the pixel position of the baseline? The 
cross reference and the dynamic text issues are not addressed at all.
> Like I said, we want to leverage the browser's deep and complex 
> knowledge of text rendering as much as possible, and just take the 
> resulting pixel output as it would be shown to the user.
>> - 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
> Indeed. I know it's easy to state and there are edge cases. But we 
> could put limits on it like e.g. no plugins, no <object>, and still 
> have something very useful for rendering text.
So I assume we agree that the element rendering proposal would still 
need significant specification work and is probably much more difficult 
to implement. The element rendering approach may make working with bulk 
text simpler, but this case is already handled quite fine by HTML 
outside the Canvas element. By asking for too much, we may end up with 
nothing at all.

Andrew has provided a clear and simple proposal that can easily be 
implemented without too much consideration of side effects. Putting 
labels on maps, precise text positioning, starwars-like 3d scrolling 
text, labels for game characters or in physics simulations, all the 
stuff that could only be done in a canvas element, is trivial to 
implement with the drawText() approach, but seems much more complex or 
impossible with the element rendering approach.
>> Moreover, drawElement() would not solve the drawText problem for 
>> non-browser environments such as Rhino.
> How are we anticipating <canvas> might be used in a non-browser context?
Canvas and some other parts of the spec (e.g. connections) may make a 
lot of sense for Javascript outside of the browser context.  This may be 
outside of the scope of WHATWG, but if we can take out some building 
blocks and use them somewhere else, this is at least a sign of good and 
modular API design.

Best regards,
Stefan