RE: EOT & DMCA concerns

>From: Jonathan Kew [mailto:jonathan@jfkew.plus.com]
>Sent: Wednesday, August 05, 2009 1:30 AM


>One concern I have is that if we all implement EOT-Lite (by whatever
>name) now, it will be more difficult for a new and better format to
>gain acceptance, and so we may end up with an inferior format in the
>long term for the sake of short-term gain.

That assertion has been made before but I'm not sure why that's true ?
If the new format is better, acceptance should not be an issue. If
.webfont and ZOT add so little value over a 100 bytes of header prefix
that the latter would delay their adoption then maybe they need thorough
questioning, given that they will take more design and coding time.

>If we introduce a format such as .webfont/.zot/etc at this point,
>there's a strong incentive for everyone to get on board; this will
>be reduced if there's EOTL as an available, interoperable solution
>even if it is technically less optimal.

Who are the people whose incentive will decrease ? I'm on board. I
don't think Tal, Erik et al. would drop out. Nor would Opera. But
then again, if 100 bytes of legacy header prefix is good enough to
significantly reduce interest in the alternatives, what does that
say about them ?

>I'm not convinced that the issue of backward compatibility with the
>legacy IE installed base is as valuable or crucial as some seem to
>think. For one thing, there are the rumored "quirks" in existing IE
>@font-face support, which may require custom CSS support anyway, in
>which case authors might as well be serving a separate format as well
>(i.e., EOT for legacy IE, new web fonts for others). At least in the
>case of IE6, which is said to be widely deployed among the slow-to-
>upgrade user base, the limitation of one font per family name is
>pretty damning.

First, I'd like to see web authors agree with that sentiment.

Second, I'm not sure I understand why the need for custom CSS makes it OK
to also require authors to manage to manage two file formats for the same
resource instead of a single one. Is known legacy pain a good reason to
add new and shiny pain ? :)

Although John has made that point as well, I do not understand why the value
of this proposal - or any other format - should be defined by IE6 quirks and
limitations. Especially when the alternatives will not work in IE6 at all. We
can't argue IE6 makes EOTL unattractive due to IE6's CSS limitations then suggest
falling back to EOT for IE6 since...EOTLs are EOTs. No difference.

If IE6 support is critical to them then authors will still deal with those
'pretty damning' issues. Raising the cost of using web fonts across all browsers
by a adding different format does not make their lives easier.

>If we disregard the non-upgrading IE6 user base, on the grounds that
>sites wanting to support them will have to use custom workarounds
>anyway, we're left with the IE7/8 users. Yes, there are lots of them.
>But there are also lots of Firefox 3.0 and 3.5 users, for example, not
>to mention Safari, Konqueror, Opera, etc. All these users would need
>to upgrade in order to see EOTL fonts.

The data shows that Firefox, Safari and Opera users have a much faster upgrade
cycle. There are many reasons for this, including the user population : many IE
'seats' are corporate/government for instance, and have very conservative upgrade
policies. As it generally takes 18 months for a new IE release to replace 50% of
its installed base and IE9 is no less than two years away, this is a long time for
authors and font vendors to wait. This is also what makes EOTL relatively more attractive,
despite known IE bugs. Whether the trade-off is worth it in practice really depends on authors.

>I don't think it is reasonable to let the outcome be dictated by an
>assumption that "IE users can't be expected to upgrade in order to see
>standard linked fonts; users of other browsers can".

It's not an assumption. It's a fact. Our installed base is very large and
a significant fraction of it upgrades at a very slow pace.

>Microsoft is just as capable as any other vendor of delivering an upgrade that adds
>support for a new font format, especially if it is a simple-to-
>implement format such as .zot or .webfont.

Even if we could just code up new features and push them in the upgrade pipeline at will
(which we can't and many of our paying customers have no desire for) that does not make
people deploy those bits any faster.

>It comes down to vendor priorities and resource allocation, and user choice.

Precisely. And many of our users do choose to upgrade slowly.

>If MS chooses to be slow about delivering such an upgrade, or if users choose to be
>slow about adopting it, they'll be no worse off than today; they will
>still see fallback fonts. I don't think that is such a disastrous
>outcome that we should allow it to push us into standardizing on a
>less-optimal web font solution.

Nobody is trying to push you into doing anything. But the fact that there is already a
very widely deployed solution that can be supported very cheaply makes it relatively more
attractive to font vendors (like Ascender) and authors (like Tab Atkins) than a brand
new format that may take another five years to reach a majority of the market. It may not
be optimal or ideal on narrow technical grounds, but it is pragmatic and reasonable to give
it careful consideration.

And if the fair and honest result comes out in favor of an alternative, then
the latter can only come out stronger for it, in my opinion.

Received on Wednesday, 5 August 2009 16:11:37 UTC