Re: Firefox "Intent to Implement" WOFF2

On Fri, Oct 3, 2014 at 9:34 AM, Jonathan Kew <jfkthame@gmail.com> wrote:

> On 3/10/14 17:20, David Kuettel wrote:
>
>> On Fri, Oct 3, 2014 at 9:08 AM, Levantovsky, Vladimir
>> <Vladimir.Levantovsky@monotype.com
>> <mailto:Vladimir.Levantovsky@monotype.com>> wrote:
>>
>>     Great, thank you Jonathan and Chris!
>>
>>
>> Wow, that is absolutely fantastic!  Great work Jonathan!
>>
>> We will target enabling WOFF 2.0 support for Firefox (Gecko 35+) for
>> Google Fonts.
>>
>>
> Thanks, David.
>
> Note that we are likely to ship this, initially at least, behind a runtime
> pref, so you can't rely solely on the Gecko version to determine whether
> WOFF 2 is supported.
>

Correct, our goal would be to aid in (and help accelerate) the initial
verification prior to the full rollout.  Our goal is to help, work across
the industry and to Move the Web Forward.

>
> I think the proper approach for a webfonts service is to offer both WOFF2
> and WOFF [and EOT/TTF/SVG/anything else you care to provide] resources,
> with the appropriate format hints in the @font-face rule, allowing the
> browser to choose which resource to fetch according to its current
> capabilities.
>

You are right, supporting web fonts *should* have been that simple, but in
attempting to support all browser/versions has proved to be anything but.
I wouldn't want to derail this tremendously exciting thread, but to
elaborate...

Paul Irish (and others) have cataloged many of the challenges in attempting
to do so on this page:
http://www.paulirish.com/2009/bulletproof-font-face-implementation-syntax/

With advanced features (such as unicode-range
<http://caniuse.com/#search=unicode-range>) it becomes even harder (to
impossible) to write one CSS snippet that works properly across all
browsers/versions without significantly regressing the end-user
experience.  For example, there are browsers that simply download *all* of
the referenced fonts, rather than the minimum required set.  Given that a
font with full pan-unicode language coverage can easily top 20MB+ (and
given that rich pages typically use multiple-styles weights), one could
quickly break the web.  We are far from the goal of supporting all
languages for each font, but definitely would like to get there in time.

As with the initial WOFF 2.0 rollout for Chrome, we would definitely
leverage a bulletproof recipe for Firefox 35+, e.g. first linking to the
format('woff2') font file, followed by the format('woff') font file.

>
> Even once we ship with WOFF2 enabled by default (which may not be the case
> in the first release where we ship the code), it'll still be possible for
> users to disable it -- or for us to disable it in an update, e.g. if a
> nasty security issue were suddenly found in the decoder -- and then we'd
> want to fall back to requesting WOFF fonts. If a webfont service offers
> *only* WOFF2, based on sniffing the browser version, webfonts would break
> completely in this scenario, whereas offering multiple resources with
> format hints provides a graceful fallback.


Excellent points John, and we (across the working group) would all want to
work closely together to navigate these together, esp. during the birth of
WOFF 2.0.

Longer term though, this does raise interesting issues in terms of
conformance with the specification.  In disabling key features (aside from
security issues), would the browser continue to pass the conformance
tests?  I wouldn't know, but am eager to learn more.

The same format negotiation principle does apply to the service/integration
as well though.  The service very well could opt not to convert the fonts
into all formats -- which is largely the case today.  Some web font
services have already stopped converting the fonts to SVG, and similarly
some browsers have already stated their intent to remove support for them
(e.g. Chrome
<https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pYbbUcYvlYY>).
For other reasons (e.g. bandwidth/cost savings, licensing, etc) services
could opt to only support a few formats.  As with anything, there are a lot
of interesting trade-offs to consider...

>
>
> JK
>
>