W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

RE: A way forward

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Fri, 24 Jul 2009 21:59:19 +0000
To: Thomas Lord <lord@emf.net>
CC: Håkon Wium Lie <howcome@opera.com>, John Hudson <tiro@tiro.com>, www-font <www-font@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E020F829E@TK5EX14MBXC113.redmond.corp.microsoft.com>
> From: Thomas Lord [mailto:lord@emf.net]
> Sent: Friday, July 24, 2009 2:41 PM

> I suggest a different framing of the issue as two
> questions:

You and I can frame in different ways, it does not follow
that others will follow you framing.

> (a) Does there exist some (any) reasonabler variation
> of EOT-lite for which, if the other browsers implement that
> support, the other browsers and existing versions
> of IE will all do the same, useful thing?

I have seen no evidence that there isn't. I am seeing concern over
known IE interoperability bugs and I absolutely acknowledge authors
will deal with them for some time. But as this concern is orthogonal
to the underlying file format being served, I don't understand why
it matters in assessing Ascender's proposal.

Hakon can't both tell me our quirks will force him to emulate legacy
behavior if he support EOT-Lite then suggest we implement raw TTF/OTF
support as if the exact same constraint did not apply.

If this were the real issue blocking adoption of EOT-Lite then no
other proposal on the table will address it. Changing the file format
does not fix IE parsing bugs and interop quirks.

> (b) Will restricted license type vendors agree to
> license in that variant?

That is also John's question and it is a fair one. That is up
to font vendors to answer. At least one - Ascender - has committed
publicly so far and even developed tooling.

Authors have expressed interest on this list and others. A fair hearing
is all I ask for.

> If the answer to both questions is "yes" then
> that is a strong argument for that variant of
> EOT-lite.
> If the answers are (a) - yes and (b) - no
> then that is a weaker but still positive argument
> for that variant of EOT-lite.
> If the answer has (a) - no, then there is no
> point to even considering any variant of EOT-lite.

That's a fine argument. Note that all I oppose here is Hakon's latest argument against EOT-Lite.
I find flat-out misleading, and quite possibly misinformed if not dishonest.

But however wrong Hakon's latest shtick may be, it does not follow EOT-Lite can work in practice.
If, as John pointed out, the font vendors' EULAs do require same-origin checks then IE can't comply.
Which throws all potential interop benefits out of the window. Now *this* is an argument against EOT-Lite
I can live with. Provided, of course, we have the evidence to call it.

Claiming EOT-Lite is bad for the web because Opera's @font-face would have to match IE's behavior is plainly nonsensical. Or theater. I don't really know which.
Received on Friday, 24 July 2009 22:00:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:40 UTC