Re: font proposal bogosities

On Fri, Jun 26, 2009 at 3:18 PM, Thomas
Phinney<tphinney@cal.berkeley.edu> wrote:
> On Fri, Jun 26, 2009 at 2:40 PM, Thomas Lord<lord@emf.net> wrote:
>> Two general sets of ideas seem to show up in the
>> font discussion that I think can be persuasively
>> argued against as general categories.
>>
>> These ideas are:
>>
>> 1. Requirements that browsers sometimes
>>   refuse to render with a font that is
>>   at hand to the browser.
>>
>> 2. New formats whose rationale is to be
>>   different from existing font formats.
>>
>>
>> Refutations:
>>
>> 1. A requirement that a browser simply
>>   decide to not render with a given font
>>   has the fatal flaw that it contributes
>>   nothing at all to interoperability.
>
> Actually, it contributes to interoperability with the font itself,
> which is a piece of software. The font is expected to behave in
> certain ways (even if that means NOT rendering), and the browser is
> making that happen.

Not quite.  An interop problem would be something breaking.
Displaying a font (even when the font itself claims that it shouldn't
be displayed) won't ever break anything.  There's nothing that is
exposed to users that will be negatively affected by a chosen font
being displayed (rather than a fallback font).

As the other Thomas said, there's no interop problem with displaying a
font in this idea.  The major reason we have specs at all is to
promote interop so that authors can write their pages once and users
can use anything to view it.  A 'broken' browser in this respect
doesn't harm this ideal in any way.

>>   And that bug is a bad bug: it can present a
>>   threat to life and limb when a life critical
>>   resource goes un-rendered in a time of desparate
>>   need.
>
> The user would get fallback to some other font. The results would be
> no worse than they are today.

Indeed, but especially in the consistently raised case of minority
languages, the situation today can be pretty sucky, and one of the
benefits of Webfonts is making the whole thing much less sucky.

> Making the results consistent across browsers would help make them
> predictable as well. If a given web site with an improperly handled
> font link doesn't render on any browser, nobody would expect
> otherwise.

Think about when this will actually happen, though.  An author writes
a page, and specifies some @fontface rules.  They then deliberately
use that font to style a web page.  The author certainly makes sure
that the font displays correctly on their dev machine.  Then things
get moved to a production server or whatever, and things break because
of non-updated root strings.  Which provides a better user experience,
the browser that pays attention to root strings (and does fallback to
another font) or the browser that ignores root strings and shows the
specified first-choice font?

Can you come up with a roughly equivalent scenario where the
"non-compliant" (scare quotes used just because there's nothing to be
non-compliant to yet) browser offers a worse user experience than the
"compliant" one?

> Giving more freedom to browsers to behave differently from each other
> in this regard would be the increased risk in terms of getting
> expected results.

I think it can be well argued that the browser that ignores root
strings will give *expected* results in more scenarios, even if
they're not *correct* results according to a theoretical spec.

~TJ

Received on Friday, 26 June 2009 20:40:21 UTC