[whatwg] Still beating the drawString() dead horse...
sh at kobjects.org
Tue Nov 14 05:09:32 PST 2006
Mathieu HENRI wrote:
> Stefan Haustein wrote:
>> I have tried to sum up the requirements for
>> CanvasRenderingContext2D.drawString() at
>> The page contains an API proposal based on the Font/TextStyle object
>> approach that meets all those requirements, and also some motivation
>> why I have implemented this approach and not one of the alternatives
>> discussed here.
> I still think by introducing the drawString() method into Canvas we
> are opening the same can of worms that was open in SVG.
> If we go that way we will need a drawParagraph() method to draw multi
> line strings or blocks of text with wrapping and a bounding width. We
> also need to be able to stylize the text, i.e. changing the
> font-weight / color / font-style ... of any word.
I do no see how adding drawString() implies that drawParagraph() must be
added, too. In fact, you can implement all that stuff yourself in
Comparing SVG and Canvas is like comparing apples and oranges. Instead
of comparing Canvas to a declarative approach, why not compare it to the
Java Canvas class? Java 1.1 did not have any drawParagraph() method,
only drawString(), but you could still implement a whole text editor.
> The list goes on and on ... and HTML and CSS already cover it all.
HTML and CSS do not cover access to the font metrics. If HTML and CSS
are suitable for your use case, why not stick with HTML and CSS in the
first place? What is the use case for drawElement()?
For applications such as labels in dynamic maps, graphs, game scores and
data visualization, drawElement() simply does not seem adequate.
> The HTMLElement.drawElement() method should be no problem to implement
> since userAgents already do render HTMLElements.
Being able to tender HTML elements does not imply that it is simple to
render HTML elements out of context or multiple times. Even if it may be
simple in one particular browser implementation, that does not imply
that it is simple in others.
> Having it return an ImageData object will make it insanely simple to
> manipulate in Canvas.
Memory usage and slowness will also become insane, and upscaling will
become insanely ugly.
> The text elements/contents can easily be in the fall back content of
> the Canvas tag thus keeping it accessible.
If the text is usable on its own, it is probably better placed in
regular HTML content.
> Getting the bounding box of an HTMLElement is no problem either in
> fillRect() with the appropriate globalCompositeOperation.
The bounding box does not help to align a the beaseline of a label with
a given coordinate.
> Everything (almost) is there. Let's not re-invent a square wheele
The problem here is "almost". All other graphics libraries seem to roll
fine with this "square wheel", so perhaps it is a bit rounder than you
suggest? No, SVG is not a graphics library....
More information about the whatwg