Re: A way forward

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:

  CSS on bigfamouscompany.com:
  
  @font-face {
    font-family: Pretty Font;
    src: url(fonts/prettyfont.eot); /* EOT-Lite version with null root string */
  }
  
  CSS on mytinylittlesite.com:
  
  @font-face {
    font-family: Pretty Font;
    src: url(http://bigfamouscompany.com/fonts/prettyfont.eot);
  }
  
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.

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.

John Daggett
Mozilla Japan

Received on Friday, 24 July 2009 20:25:47 UTC