[whatwg] Canvas lack of drawString method
gerv at mozilla.org
Wed Oct 18 15:12:03 PDT 2006
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
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.
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
> - 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.
I mean, all you really need to support is stuff like:
<div class="box">Some text to play with</div>
> 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?
More information about the whatwg