[whatwg] Still beating the drawString() dead horse...
sh at kobjects.org
Tue Nov 14 04:22:23 PST 2006
the problem is that we need to draw the line somewhere. In my opinion,
go into the core API, because there are so many different ways to do it.
For instance, what shall the implementation do if the text does not fix
in the box? An alternative may be to have only a width parameter and
return the rendered height, but then the next logical step is to ask for
the calculation without the rendering....
drawString() has a clear and simple use case: Labels (e.g. in Maps) and
calculated values (scores, numbers, ...).
Everything beyond is a separate use case that should be discussed
separately. I think the main problem here is that drawElement() was
suggested as a kind of replacement for drawString(), but it is actually
something completely different, that should be discussed separately.
drawElement() does not really remove the need for a simple API. I feel
like asking for a scissor, but being told that a combine harvester is
much more powerfull... That may be true, but it is also a bit
unpractical, lets say for something like a hair cut.
Martin Atkins 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.
> Some comments:
> void drawString(in float x, in float y, in DOMString text);
> attribute DOMString verticalAlign;
> attribute DOMString textAlign;
> I'm guessing from the function signature that what is actually
> changing here is how the coordinates (x,y) relate to the rendered
> text. a textAlign of right will presumably cause the text to be drawn
> with the rightmost edge at x.
> However, it'd also be useful to be able to render formatted blocks of
> text, like this:
> void drawString(in float x1, in float y1, in float x2, in float y2,
> in DOMString text)
> ...which wrap text and would make a textAlign of "justify" meaningful.
> Suddenly a bunch more CSS properties become attractive (margins and
> letter spacing, for example) but I think line-height alone would do
> for now.
> Rendering formatted blocks of text seems to me to be such a common
> thing that the canvas API should support it natively.
> This does, of course, require more functions on TextStyle to measure
> the extent of a block of text. This could probably be confined to just
> the following:
> float getBlockHeight(in DOMString s, float width)
> I think that a good use-case for this would be replacing regular
> document elements with canvases, either using bare script or using
> XBL. You point out in your document that drawElement(e) is tricky, but
> for limited cases it would be nice to be able to obtain the computed
> style of the canvas element to use for rendering, so that the text can
> match the style of the surrounding document.
> This can be as simple as one method on the canvas context to fetch the
> computed style, which would presumably return null in a non-browser
> implementation of the API.
> CanvasTextStyle getInheritedStyle();
> For example, this could be used to create some kind of visual effect
> (fancy headings?) or to render a graphical element from some XML
> namespace that isn't supported in browsers yet.
More information about the whatwg