- From: Charles Pritchard <chuck@jumis.com>
- Date: Thu, 12 May 2011 01:01:48 -0700
On 5/11/11 10:00 PM, Ian Hickson wrote:
> On Sun, 13 Feb 2011, Charles Pritchard wrote:
>
>> Could we remove the optional maxWidth parameter from fillText and strokeText
>> of CanvasRenderingContext2D.
>> I don't see them in use anywhere, they're not widely implemented, and I don't
>> see them fitting any particular common purpose.
>>
> Their intent is to ensure that when you have a specific amount of space in
> which text has to fit, and you don't know exactly what that space is or
> you don't know exactly what the text is, you can easily work around minor
> cases of limited space. For example, I use it on the issues chart:
>
There's no guarantee of legibility, there's no exposure as to the actual
size of the font
being used. It's not (or was not, in the recent past) implemented in
many browsers.
It serves only minor cases. It's unnecessary.
> gets there). When the variance is much bigger, you can't rely on just
> squeezing the text, you need something more clever.
....
> Yes, you can do it manually if your needs aren't met by the API.
>
Yes, you can use TextMetrics. So why have this added bloat?
Most of your philosophy regarding the Canvas API has been to keep out
unnecessary
and unimplemented items. I don't see how this one is any different.
If it were intended, to be more useful, I'd want to see it in
measureText as well,
so that measureText('string', maxWidth) would return a font size attribute.
In doing so, I could check to see if the font size is within appropriate
range
for legibility.
Your use case, in your data chart, could quite easily have been written
up without
the added attribute. That's why I'm bringing this up.
maxWidth doesn't flow with other judgments and reasoning put forward
about the canvas spec,
it's not commonly implemented. It's superfluous; easily programmed. And
it's not exposed in TextMetrics, making it difficult
to test for legibility.
Received on Thursday, 12 May 2011 01:01:48 UTC