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 22:12:38 +0000
To: John Daggett <jdaggett@mozilla.com>, www-font <www-font@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E020F8315@TK5EX14MBXC113.redmond.corp.microsoft.com>
> From: www-font-request@w3.org [mailto:www-font-request@w3.org] On
> Behalf Of John Daggett

> Okay, simple example.  One of the things font vendors have asked for
> is some form of same-origin restriction to prevent cross-site linking.
> So I imagine that EULA's will be written in such a way as to make this
> a requirement for usage (e.g. "font may only be used where same-origin
> usage is assured").
> If the goal of EOT-Lite is to allow a single file to work both in new
> versions of non-IE browsers and in old versions of IE, then there's no
> way to satisfy this requirement.  If all new versions of non-IE
> browsers implement EOT-Lite and same-origin checking then the EOT-Lite
> file can't be cross-site linked in non-IE browsers but can be
> cross-site linked in IE:

Just like I can cross-link to a raw font in Safari but it will fail in Firefox by default. Is
that OK with authors and all the free font licenses out there ?

But whether this issue conflicts with the EULA is up to font vendors to define. If it does require it,
there is, as you point out, no way to satisfy their requirement for IE users. Firefox, however, would
be all set...so I'm not sure why you'd want to change that ! :)

> With a new, distinct format this requirement can be satisfied with a
> root string EOT file for older versions of IE and a new format font
> for non-IE browsers:
>   CSS on bigfamouscompany.com:
>   @font-face {
>     font-family: Pretty Font;
>     src: url(fonts/prettyfont.eot); /* EOT version with
> bigfamouscompany.com root string */
>   }
>   @font-face {
>     font-family: Pretty Font;
>     src: url(fonts/prettyfont.webfont) format("webfont"); /* IE doesn't
> understand hints so it throws this rule out */
>   }
> This satisfies the EULA requirement for both new versions of non-IE
> browsers and legacy versions of IE.  It won't Akamai-ize well in the
> IE case due to the root string but them's the breaks.  When IE
> adds support for .webfont this problem will go away.

If there is such a requirement in the EULA then, yes. In the absence of an EULA to determine if this is an issue, I can't speculate. It's a very valid question for font creators though. And one that is not limited to IE and EOT-Lite. If any libre font license proscribes cross-site linking then the current Safari implementation may be an issue for raw font files as well.

Clearly, requiring two formats and managing rootstrings on one of them will be onerous for authors and, I believe, likely limit adoption. All the practical usability reasons you brought up against rootstrings still apply. And
as authors do seem to have a strong preference for a cross-browser solution, such an EULA could turn out to be too much of a burden in practice.

> This is what I mean about legacy behavior limiting the flexibility of
> a new standard, with EOT-Lite font vendors can't enforce same-origin
> restrictions which they seem to be asking for.

What I hear here are good reasons:
1. For font vendors to define their web font EULA terms;
2. To consider EOT-Lite as an interim solution at best;
3. For all browser vendors, including Microsoft, to agree on same-origin checks for font files (as you suggested) and other related issues; not sure why that would be specific to any one format though. I think interop demands we do it for all web fonts.
4. For me to get those bugs fixed in the next cycle :)
Received on Friday, 24 July 2009 22:13:26 UTC

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