RE: Next step?

On Wednesday, August 12, 2009 2:35 AM Thomas Phinney wrote:
> 
> I think there are two elements:
> 
> 1) finishing formalizing the specs. Both EOTL and Web OTF are pretty
> close already.
> 
> 2) determine what the actual recommendation is. Does it include all
> three of naked fonts, EOTL and WebOTF, or some subset? Does it say
> that if one supports any format, one must support all three? Is it
> silent on that issue? Or does it play favorites as to which format(s)
> are important?

I agree that Recommendations shouldn't "play favorites", and I don't see
why a future Recommendation should even address this issue. The subject
of a Recommendation on web font support, IMO, should be centered around
providing a clear specification of what the web font format(s) is(are).

> 
> I believe the set of questions around (2) are the thorny ones. I
> expect that a recommendation saying that user agents supporting web
> fonts MUST support WebOTF, and MAY support naked fonts and/or EOTL
> would be the closest to a compromise that just maybe everyone involved
> could live with.

The goal of W3C Recommendation is to define an interoperable data
format. In order to fulfill this goal, the Recommendation should
identify the components that are absolutely critical for achieving an
interoperable solution, and, IMO, these are the cases when "MUST" would
be applicable and must be used (ideally, these are the only parts a
Recommendation should define; I agree with Roc that "in Web specs
"SHOULD" requirements indicate a looming interoperability problem"). For
example, if we want WebOTF format to provide web authors with the option
to use ZOT-compressed fonts, the Recommendation needs to say that ZOT
compression MUST be supported by UA in order for it to truly be an
option for developer. I agree that any attempt to establish a dependency
between different formats would be thorny.

>From the pragmatic point of view, I believe we all agree that supporting
EOTL would allow web fonts be available to authors right away. We do not
have much flexibility in defining the EOTL format because of the legacy
IE support, and it is clear that EOTL isn't an "ideal" solution.
However, it is exactly because of its compatibility with the legacy IE
browsers (which captured significant share of the web users) that
implementing EOTL would bring a real value for the web.

As a long term solution, WebOTF seems to be the one that we can get as
close to an "ideal" solution as possible, considering the components
such as font compression, metadata, etc. Some browser vendors will
probably implement it *right away* but given the dynamics of the browser
releases and upgrades (IE9 will be available in a couple of years and it
may take a while before a significant number of users switch to it from
the earlier IE versions) web authors won't be able to benefit from
WebOTF for the next 4-5 years. 

Not having EOTL supported and just waiting 5 years or so, before WebOTF
is available doesn't seem to be a viable option. Some people may argue
that in the meantime authors may resort to a technique that requires
sniffing a browser and serving fonts in different formats for different
UA - I think this will be a burden in web font adoption. I also believe
that having real-life feedback from web authors based on their
experience with EOTL would be a valuable ingredient in making WebOTF an
ideal format.

Regards,
Vladimir

Received on Wednesday, 12 August 2009 14:56:45 UTC