Intent to implement: WOFF2 webfont format

486 views
Skip to first unread message

Jonathan Kew

unread,
Oct 2, 2014, 7:03:17 AM10/2/14
to dev-pl...@lists.mozilla.org
The W3C WebFonts Working Group[1] has been working on designing and
specifying a new compressed font format for the web, aiming to give
significantly smaller file sizes than the existing WOFF format (to
reduce bandwidth requirements), while remaining cheap to decode (for
low-power devices).

The format is primarily based on earlier TrueType compression work
(MicroType Express) by Monotype, and a new entropy coder (Brotli)
developed by Google's data compression team in Zurich.

For more information about the WOFF2 format, see the FPWD spec[2] and
current Editors' Draft.[3]

WOFF2 is currently supported by Chrome and Opera,[4] and the Google
webfonts service is serving WOFF2-compressed fonts to browser versions
that are known to support it.[5]

I'm proposing to add WOFF2 support to Gecko, based on the "reference
implementation" code from the Google font and compression teams, found
at [6].

Support for WOFF2 will be controlled by a new boolean pref
"gfx.downloadable_fonts.woff2.enabled". Initially this defaults to false
for release builds, and true for nightlies; when we're ready to ship the
feature on-by-default, we can simply flip the pref to true for all channels.

This work is happening in bugs [7] and [8], which I hope to land "real
soon now" (in time for Gecko 35, if all goes well).

- JK


[1] http://www.w3.org/Fonts/WG/
[2] http://www.w3.org/TR/WOFF2/
[3] http://dev.w3.org/webfonts/WOFF2/spec/
[4] http://caniuse.com/#feat=woff2
[5] https://code.google.com/p/font-compression-reference/wiki/testing_woff2
[6] https://code.google.com/p/font-compression-reference/
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1066160
[8] https://bugzilla.mozilla.org/show_bug.cgi?id=1064737

Ralph Giles

unread,
Oct 2, 2014, 11:20:52 AM10/2/14
to Jonathan Kew, dev-pl...@lists.mozilla.org
On 2014-10-02 4:03 AM, Jonathan Kew wrote:

> The format is primarily based on earlier TrueType compression work
> (MicroType Express) by Monotype, and a new entropy coder (Brotli)
> developed by Google's data compression team in Zurich.

What kind of filesize reductions do you see over ttf and woff1?

-r

Jonathan Kew

unread,
Oct 2, 2014, 11:27:07 AM10/2/14
to Ralph Giles, dev-pl...@lists.mozilla.org
Results will vary considerably depending on the specific fonts involved,
but a compressed size that is around 25-30% smaller than WOFF 1.0 would
be typical for TrueType fonts.

See Appendix B of http://www.w3.org/TR/WOFF20ER/.

JK

Ehsan Akhgari

unread,
Oct 2, 2014, 12:17:38 PM10/2/14
to Jonathan Kew, dev-pl...@lists.mozilla.org
On 2014-10-02, 7:03 AM, Jonathan Kew wrote:
> The W3C WebFonts Working Group[1] has been working on designing and
> specifying a new compressed font format for the web, aiming to give
> significantly smaller file sizes than the existing WOFF format (to
> reduce bandwidth requirements), while remaining cheap to decode (for
> low-power devices).
>
> The format is primarily based on earlier TrueType compression work
> (MicroType Express) by Monotype, and a new entropy coder (Brotli)
> developed by Google's data compression team in Zurich.
>
> For more information about the WOFF2 format, see the FPWD spec[2] and
> current Editors' Draft.[3]
>
> WOFF2 is currently supported by Chrome and Opera,[4] and the Google
> webfonts service is serving WOFF2-compressed fonts to browser versions
> that are known to support it.[5]

Is support for WOFF2 feature detectible? Or do people need to hardcode
UA versions to know what UAs support it?

> I'm proposing to add WOFF2 support to Gecko, based on the "reference
> implementation" code from the Google font and compression teams, found
> at [6].
>
> Support for WOFF2 will be controlled by a new boolean pref
> "gfx.downloadable_fonts.woff2.enabled". Initially this defaults to false
> for release builds, and true for nightlies; when we're ready to ship the
> feature on-by-default, we can simply flip the pref to true for all
> channels.
>
> This work is happening in bugs [7] and [8], which I hope to land "real
> soon now" (in time for Gecko 35, if all goes well).
>
> - JK
>
>
> [1] http://www.w3.org/Fonts/WG/
> [2] http://www.w3.org/TR/WOFF2/
> [3] http://dev.w3.org/webfonts/WOFF2/spec/
> [4] http://caniuse.com/#feat=woff2
> [5] https://code.google.com/p/font-compression-reference/wiki/testing_woff2
> [6] https://code.google.com/p/font-compression-reference/
> [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1066160
> [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1064737
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Ilya Grigorik

unread,
Oct 2, 2014, 12:37:31 PM10/2/14
to
On Thursday, October 2, 2014 9:17:38 AM UTC-7, Ehsan Akhgari wrote:
> On 2014-10-02, 7:03 AM, Jonathan Kew wrote:
>
>
> > WOFF2 is currently supported by Chrome and Opera,[4] and the Google
> > webfonts service is serving WOFF2-compressed fonts to browser versions
> > that are known to support it.[5]
>
> Is support for WOFF2 feature detectible? Or do people need to hardcode
> UA versions to know what UAs support it?

You don't need UA detection, @fontface with format() hint does the trick:
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/webfont-optimization#defining-font-family-with-font-face

ig

Jonathan Kew

unread,
Oct 2, 2014, 12:42:25 PM10/2/14
to Ehsan Akhgari, dev-pl...@lists.mozilla.org
On 2/10/14 17:17, Ehsan Akhgari wrote:

> Is support for WOFF2 feature detectible?

Not directly, but it would be fairly easy for a site that really wants
to detect it via CSS+JS hackery to do so. There'd be some overhead to
such detection, though.

> Or do people need to hardcode
> UA versions to know what UAs support it?

I believe that's what Google Fonts currently does, though IMO a better
approach is to serve CSS that offers both WOFF2 and older (more
widely-supported) formats, using the @font-face src descriptor's "format
hint" to let the browser choose the optimal resource depending on what
it supports:

@font-face {
font-family: MyFont;
src: url(myfont.woff2) format("woff2"),
url(myfont.woff) format("woff"),
url(myfont.eot) format("embedded-opentype"),
url(myfont.ttf) format("truetype");
}

etc.

JK

Jonas Sicking

unread,
Oct 2, 2014, 8:12:22 PM10/2/14
to Jonathan Kew, Ehsan Akhgari, dev-pl...@lists.mozilla.org
On Thu, Oct 2, 2014 at 9:42 AM, Jonathan Kew <jfkt...@gmail.com> wrote:
>> Or do people need to hardcode
>> UA versions to know what UAs support it?
>
>
> I believe that's what Google Fonts currently does, though IMO a better
> approach is to serve CSS that offers both WOFF2 and older (more
> widely-supported) formats, using the @font-face src descriptor's "format
> hint" to let the browser choose the optimal resource depending on what it
> supports:
>
> @font-face {
> font-family: MyFont;
> src: url(myfont.woff2) format("woff2"),
> url(myfont.woff) format("woff"),
> url(myfont.eot) format("embedded-opentype"),
> url(myfont.ttf) format("truetype");
> }

Could we at least add woff2 to the Accept header when fetching fonts?

/ Jonas

Jonathan Kew

unread,
Oct 3, 2014, 4:37:15 AM10/3/14
to Jonas Sicking, Ehsan Akhgari, dev-pl...@lists.mozilla.org
Sounds like a good suggestion in principle.

Wondering what we currently send in that header, I looked at some font
requests in the DevTools Network panel... it seems we fetch fonts using

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

which doesn't look even remotely sensible. If we're going to adjust
this, we should probably not simply add woff2 to this but do a more
thorough cleanup job.

For comparison, Chrome appears to use simply

Accept:*/*

and Safari, at least according to its inspector, doesn't send an Accept
header at all when fetching fonts. (Or images, for that matter.)

I just filed bug 1077312. However, I don't think this needs to actually
block the implementation of WOFF2 support.

JK

ch...@w3.org

unread,
Oct 3, 2014, 12:45:14 PM10/3/14
to
On Friday, 3 October 2014 02:12:22 UTC+2, Jonas Sicking wrote:

> Could we at least add woff2 to the Accept header when fetching fonts?

If Internet Media Types for fonts were widely and consistently deployed, then that sort of server-mediated content negotiation (client sends list of accepted formats and q factors, sever decides what is best and sends it) would probably work.

However, they are not and never have been; also early attempts to creat a font/* top level type were blocked. Which is why @font-face uses a format hint instead. This is client-mediated content negotiation (content provides list of avbailable formats and a link to each, client decides what is best and asks for it).

This works well in practice. Thus, an ordered list of urls and formats in a scr descriptor remains the recommended deployment method; it needs no web server config changes and no ua detection, and is resilient to fonts in the wild being served as text/plain or application/octet-stream or whatever the sever defaults to for "no idea what this is".

Which is not to argue against sending sensible accept headers, but cleaning that up is orthogonal to woff2 deployment.

Zack Weinberg

unread,
Oct 6, 2014, 5:07:18 PM10/6/14
to
On 2014-10-03 4:37 AM, Jonathan Kew wrote:
> it seems we fetch fonts using
>
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>
> which doesn't look even remotely sensible.

Agree, but note that there are no official MIME types for most font
formats. (I *think* application/font-woff did get registered for
WOFF1.) Lots of people have just made up MIME types, including e.g.
application/x-ttf, application/ttf, font/ttf (inventing a whole
category!) and so on. I'm not aware of any significant changes in this
area since I wrote
https://www.owlfolio.org/htmletc/strawman-mime-type-for-fonts/ back in 2011.

As described in that post, I continue to think that
"Accept: application/font" plus client-side selection of URL based on
format() is the Right Thing.

> I just filed bug 1077312. However, I don't think this needs to actually
> block the implementation of WOFF2 support.

Also agree here.

zw

Anne van Kesteren

unread,
Oct 6, 2014, 5:33:58 PM10/6/14
to Zack Weinberg, dev-pl...@lists.mozilla.org
On Mon, Oct 6, 2014 at 11:07 PM, Zack Weinberg <za...@panix.com> wrote:
> https://www.owlfolio.org/htmletc/strawman-mime-type-for-fonts/ back in 2011.

I tried fixing this together with Håkon back in 2008:
https://annevankesteren.nl/2008/08/font-mime-types

We couldn't get agreement with the IETF fast enough so instead
browsers ignore MIME types for fonts as Safari was already doing:
http://www.alvestrand.no/pipermail/ietf-types/2008-August/002066.html
It was all rather sad.


--
https://annevankesteren.nl/

Henri Sivonen

unread,
Oct 7, 2014, 9:39:19 AM10/7/14
to Jonas Sicking, Ehsan Akhgari, dev-pl...@lists.mozilla.org, Jonathan Kew
On Fri, Oct 3, 2014 at 3:11 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>> @font-face {
>> font-family: MyFont;
>> src: url(myfont.woff2) format("woff2"),
>> url(myfont.woff) format("woff"),
>> url(myfont.eot) format("embedded-opentype"),
>> url(myfont.ttf) format("truetype");
>> }
>
> Could we at least add woff2 to the Accept header when fetching fonts?

Why? The CSS-level negotiation feature shown above works great and
doesn't involve any HTTP-level varying. (Also, like Anne says, fonts
MIME types are a sad story.)

I think we should treat Accept in general as a legacy mistake and not
try to make it do new tricks.

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

Patrick McManus

unread,
Oct 7, 2014, 9:53:44 AM10/7/14
to Henri Sivonen, Ehsan Akhgari, dev-pl...@lists.mozilla.org, Jonas Sicking, Jonathan Kew
content format negotiation is what accept is meant to do. Protocol level
negotiation also allows designated intermediaries to potentially transcode
between formats. imo you should add woff2 to the accept header.

Gervase Markham

unread,
Oct 8, 2014, 6:10:18 AM10/8/14
to Patrick McManus, Henri Sivonen, Ehsan Akhgari, dev-pl...@lists.mozilla.org, Jonas Sicking, Jonathan Kew
On 07/10/14 14:53, Patrick McManus wrote:
> content format negotiation is what accept is meant to do. Protocol level
> negotiation also allows designated intermediaries to potentially transcode
> between formats.

Do you know of any software which transcodes font formats on the fly as
they move across the network?

> imo you should add woff2 to the accept header.

Do you know of any software which pays attention to this header?

Given that other browsers don't set it, why would anyone else write such
software?

(This situation is basically "the Accept: problem".)

Gerv

Gervase Markham

unread,
Oct 8, 2014, 6:11:21 AM10/8/14
to Patrick McManus, Henri Sivonen, Ehsan Akhgari, dev-pl...@lists.mozilla.org, Jonas Sicking, Jonathan Kew
On 07/10/14 14:53, Patrick McManus wrote:
> content format negotiation is what accept is meant to do. Protocol level
> negotiation also allows designated intermediaries to potentially transcode
> between formats.

Do you know of any software which transcodes font formats on the fly as
they move across the network?

> imo you should add woff2 to the accept header.

Anne van Kesteren

unread,
Oct 8, 2014, 6:26:07 AM10/8/14
to Gervase Markham, Ehsan Akhgari, dev-pl...@lists.mozilla.org, Jonas Sicking, Jonathan Kew
On Wed, Oct 8, 2014 at 12:10 PM, Gervase Markham <ge...@mozilla.org> wrote:
> (This situation is basically "the Accept: problem".)

There's a bit more elaboration here for those new to it:

https://wiki.whatwg.org/wiki/Why_not_conneg


--
https://annevankesteren.nl/

Patrick McManus

unread,
Oct 8, 2014, 10:44:25 AM10/8/14
to Gervase Markham, Ehsan Akhgari, Jonathan Kew, Patrick McManus, Henri Sivonen, dev-pl...@lists.mozilla.org, Jonas Sicking
On Wed, Oct 8, 2014 at 6:10 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 07/10/14 14:53, Patrick McManus wrote:
> > content format negotiation is what accept is meant to do. Protocol level
> > negotiation also allows designated intermediaries to potentially
> transcode
> > between formats.
>
> Do you know of any software which transcodes font formats on the fly as
> they move across the network?
>

I'm not aware of font negotiation - but negotiation is most useful when
introducing new types (such as woff2). The google compression proxy already
does exactly that for images and people are successfully using the AWS
cloudfront proxy in environments where the same thing is done. Accept is
used to opt-in to webp on those services and that allows them to avoid
doing UA sniffing. They don't normally give firefox webp, but if you make
an add-on that changes the accept header to include webp they will serve
firefox that format. That's what we want to encourage instead of UA
sniffing.


>
> > imo you should add woff2 to the accept header.
>
>
as with webp, this is particularly useful to opt-in to a new format. I
agree that as a list of legacy formats and q-values is all rather useless,
but as a signal that you want something new that might not be widely
implemented its a pretty good thing. In this case its certainly better than
the txt/html based header being used.


> Do you know of any software which pays attention to this header?
>
>
above.

http request header byte counts aren't something to be super concerned with
within reason (uris, cookies, and congestion control pretty much determine
your performance fate on the request side). And it sounds like wrt fonts
the accept header could be made more relevant and actually smaller as well.

Jonathan Kew

unread,
Oct 8, 2014, 11:18:21 AM10/8/14
to Patrick McManus, Gervase Markham, Henri Sivonen, Ehsan Akhgari, dev-pl...@lists.mozilla.org, Jonas Sicking
On 8/10/14 15:44, Patrick McManus wrote:
>
>
> On Wed, Oct 8, 2014 at 6:10 AM, Gervase Markham <ge...@mozilla.org
> <mailto:ge...@mozilla.org>> wrote:
>
> On 07/10/14 14:53, Patrick McManus wrote:
> > content format negotiation is what accept is meant to do. Protocol level
> > negotiation also allows designated intermediaries to potentially transcode
> > between formats.
>
> Do you know of any software which transcodes font formats on the fly as
> they move across the network?
>
>
> I'm not aware of font negotiation - but negotiation is most useful when
> introducing new types (such as woff2). The google compression proxy
> already does exactly that for images and people are successfully using
> the AWS cloudfront proxy in environments where the same thing is done.
> Accept is used to opt-in to webp on those services and that allows them
> to avoid doing UA sniffing. They don't normally give firefox webp, but
> if you make an add-on that changes the accept header to include webp
> they will serve firefox that format. That's what we want to encourage
> instead of UA sniffing.
>

But the model for webfonts is explicitly *not* to have a single URL that
may be delivered in any of several formats, but rather to offer several
distinct resources with different URLs, and let the browser decide which
of them to request.

So the "negotiation" is handled within the browser, on the basis of the
information provided in the CSS stylesheet, *prior* to sending any
request for an actual font resource.

Given that this is the established model, defined in the spec for
@font-face and implemented all over the place, I don't see much value in
adding things to the Accept header for the actual font resource request.

Even where a service (like Google fonts, AIUI) is currently sniffing UA
versions and varying its behavior, it wouldn't help to advertise WOFF2
support via the Accept header for the font request, because that won't
result in them serving the appropriate WOFF2-supporting CSS to Firefox.
We need to get them to serve the right CSS; and once they do that
(either universally, or based on UA sniffing) the existing @font-face
mechanism will let us choose the best of the available resource formats
for our use.

>
> > imo you should add woff2 to the accept header.
>
>
> as with webp, this is particularly useful to opt-in to a new format. I
> agree that as a list of legacy formats and q-values is all rather
> useless, but as a signal that you want something new that might not be
> widely implemented its a pretty good thing. In this case its certainly
> better than the txt/html based header being used.
>
> Do you know of any software which pays attention to this header?
>
> above.
>
> http request header byte counts aren't something to be super concerned
> with within reason (uris, cookies, and congestion control pretty much
> determine your performance fate on the request side). And it sounds like
> wrt fonts the accept header could be made more relevant and actually
> smaller as well.

FWIW, when DNT was being created HTTP request header byte count seemed
to be a pretty strong concern, which (AIUI) was why we ended up with
DNT: 1 rather than something clearer like DoNotTrack: true.

JK

Patrick McManus

unread,
Oct 8, 2014, 11:35:42 AM10/8/14
to Jonathan Kew, Ehsan Akhgari, Gervase Markham, Patrick McManus, Henri Sivonen, dev-pl...@lists.mozilla.org, Jonas Sicking
On Wed, Oct 8, 2014 at 11:18 AM, Jonathan Kew <jfkt...@gmail.com> wrote:

>
> So the "negotiation" is handled within the browser, on the basis of the
> information provided in the CSS stylesheet, *prior* to sending any request
> for an actual font resource.
>
>
I'm not advocating that we don't do the css bits too. That's all cool.
Jonas's suggestion was also adding an appropriate accept bit.


> Given that this is the established model, defined in the spec for
> @font-face and implemented all over the place, I don't see much value in
> adding things to the Accept header for the actual font resource request.
>

intermediaries, as I mentioned before, are a big reason. It provides an
opt-in opportunity for transcoding where appropriate (and I'm not claiming
I'm up to speed on the ins and outs of font coding).

y'all can do what you want - but using protocol negotiation in addition to
the css negotiation is imo a good thing for the web.


> FWIW, when DNT was being created HTTP request header byte count seemed to
> be a pretty strong concern, which (AIUI) was why we ended up with DNT: 1
> rather than something clearer like DoNotTrack: true.
>
>
I know - but I disagree pretty strongly with the analysis there. The impact
is extremely marginal... and trust me, I'm very interested in HTTP
performance :)

Anne van Kesteren

unread,
Oct 8, 2014, 11:44:16 AM10/8/14
to Patrick McManus, Ehsan Akhgari, Gervase Markham, Jonathan Kew, Henri Sivonen, dev-pl...@lists.mozilla.org, Jonas Sicking
On Wed, Oct 8, 2014 at 5:34 PM, Patrick McManus <mcm...@ducksong.com> wrote:
> intermediaries, as I mentioned before, are a big reason. It provides an
> opt-in opportunity for transcoding where appropriate (and I'm not claiming
> I'm up to speed on the ins and outs of font coding).

If the format is negotiated client-side before a URL is fetched,
that's not going to help, is it?


--
https://annevankesteren.nl/

Patrick McManus

unread,
Oct 8, 2014, 11:50:01 AM10/8/14
to Anne van Kesteren, Ehsan Akhgari, Gervase Markham, Jonathan Kew, Patrick McManus, Henri Sivonen, dev-pl...@lists.mozilla.org, Jonas Sicking
scenario - origin only enumerates ttf in the css, client requests ttf
(accept: woff2, */*), intermediary transcodes to woff2 assuming such a
transcoding is a meaningful operation.

Jonathan Kew

unread,
Oct 8, 2014, 12:04:06 PM10/8/14
to Patrick McManus, Anne van Kesteren, Henri Sivonen, Ehsan Akhgari, Gervase Markham, Jonas Sicking, dev-pl...@lists.mozilla.org
Possible in theory, I guess; unlikely in practice. The compression
algorithm used in WOFF2 is extremely asymmetrical, offering fast
decoding but at the cost of slow encoding. The intent is that a large
library like Google Fonts can pre-compress their fonts offline, and then
benefit from serving smaller files; it's not expected to be suitable for
on-the-fly compression.

JK

Patrick McManus

unread,
Oct 8, 2014, 12:17:55 PM10/8/14
to Jonathan Kew, Ehsan Akhgari, Gervase Markham, Patrick McManus, Henri Sivonen, dev-pl...@lists.mozilla.org, Jonas Sicking
On Wed, Oct 8, 2014 at 12:03 PM, Jonathan Kew <jfkt...@gmail.com> wrote:

> Possible in theory, I guess; unlikely in practice. The compression
> algorithm used in WOFF2 is extremely asymmetrical, offering fast decoding
> but at the cost of slow encoding. The intent is that a large library like
> Google Fonts can pre-compress their fonts offline, and then benefit from
> serving smaller files; it's not expected to be suitable for on-the-fly
> compression.
>


accelerators like cloudflare and mod_pagespeed/mod_proxy exist to do this
kind of general thing as reverse proxies for specific origins.. they can
cache the transcoding locally. Obviously that's a lot harder for forward
proxies to do. Reverse proxies are often the termination of https:// as
well - so this transformation remains relevant in the https world we want.

Robert Kaiser

unread,
Oct 8, 2014, 5:15:39 PM10/8/14
to
Jonathan Kew schrieb:
> But the model for webfonts is explicitly *not* to have a single URL that
> may be delivered in any of several formats, but rather to offer several
> distinct resources with different URLs, and let the browser decide which
> of them to request.
>
> So the "negotiation" is handled within the browser

Right. And if I remember correctly, we also just invented the <picture>
element for HTML5 to do the same for images as it's actually *better* in
many regards to the dilemma we have with all the Accept: negotiation. Or
am I wrong there?

KaiRo

Jonas Sicking

unread,
Oct 8, 2014, 7:43:14 PM10/8/14
to Robert Kaiser, dev-platform
Sometimes client side negotiation is the better solution, sometimes
server side is.

It can be a pain in the ass to try to get your hosting provider to
install modules that handles content negotiation based on accept. Or
to switch service provider to one that lets you run server side
script. Or learn your server infrastructure to figure out how to add
negotiation. In those cases it's great that developers can handle it
on the client.

But there are also cases when it's a pain to figure out the client
side code to modify it to pass through the right parameters to do
negotiation on the client. Or to ask all your customers to rewrite
their apps to handle content negotiation. Or find all the places where
your referring to a given resource and replace it with logic to do
client side negotiation. In those cases it's good if the server has
access to all the information needed to serve the most appropriate
resource.

When we design the platform such that we require people to use a
particular solution we better be really sure that that solution will
work in all the (common) situations that people need the problem
solved. When we get it wrong, which so far happens a lot, people end
up with horrible workarounds, buggy apps, slower productivity and more
resource usage. In short, with a worse user experience.

We far too often close our eyes to the realities of web development in
an effort to keep the platform simple. However simple doesn't always
mean fewer features. When developers have to work around the lack of
features that doesn't make their jobs simpler.

That said, adding all the features isn't always the answer either of course.

/ Jonas

Gervase Markham

unread,
Oct 9, 2014, 6:28:36 AM10/9/14
to Patrick McManus, Ehsan Akhgari, Jonathan Kew, Henri Sivonen, dev-pl...@lists.mozilla.org, Jonas Sicking
On 08/10/14 15:44, Patrick McManus wrote:
> I'm not aware of font negotiation - but negotiation is most useful when
> introducing new types (such as woff2). The google compression proxy already
> does exactly that for images and people are successfully using the AWS
> cloudfront proxy in environments where the same thing is done. Accept is
> used to opt-in to webp on those services and that allows them to avoid
> doing UA sniffing.

OK. So it can work if every browser that supports the format puts in in
Accept: as soon as it begins support. That may be true of WebP; I don't
believe it's true of WOFF. Is it?

Gerv

Gervase Markham

unread,
Oct 9, 2014, 6:28:34 AM10/9/14
to Patrick McManus, Henri Sivonen, Ehsan Akhgari, dev-pl...@lists.mozilla.org, Jonas Sicking, Jonathan Kew
On 08/10/14 15:44, Patrick McManus wrote:
> I'm not aware of font negotiation - but negotiation is most useful when
> introducing new types (such as woff2). The google compression proxy already
> does exactly that for images and people are successfully using the AWS
> cloudfront proxy in environments where the same thing is done. Accept is
> used to opt-in to webp on those services and that allows them to avoid
> doing UA sniffing.

Henri Sivonen

unread,
Oct 9, 2014, 6:46:33 AM10/9/14
to Patrick McManus, Ehsan Akhgari, dev-pl...@lists.mozilla.org, Jonas Sicking, Jonathan Kew
On Tue, Oct 7, 2014 at 4:53 PM, Patrick McManus <mcm...@ducksong.com> wrote:
> content format negotiation is what accept is meant to do.

I'm aware, but I think format negotiation on the HTTP layer is a
misfeature that we shouldn't keep treating as if it was a good feature
(for reasons given in https://wiki.whatwg.org/wiki/Why_not_conneg ; I
used to believe in Accept a decade ago, but back then I believed in
XML, too).

On Wed, Oct 8, 2014 at 7:17 PM, Patrick McManus <mcm...@ducksong.com> wrote:
> accelerators like cloudflare and mod_pagespeed/mod_proxy exist to do this
> kind of general thing as reverse proxies for specific origins.. they can
> cache the transcoding locally.

I can see how *in theory* it seems attractive to cater to the idea of
the origin server serving bloated files and a drop-in reverse-proxy
magically doing things right thanks to HTTP headers. But (in no
specific order):
* The process for minting MIME types for fonts is so broken that it's
not worth bothering.
* The idea only works if other WOFF2-supporting browsers consistently
sent the MIME type (that's too hard to mint) in the Accept header,
too.
* It would seem more worthwhile to think this is a real use case if
there was ample evidence of optimizer software existing from TrueType
to WOFF1. Is there such evidence?
* If you really want to do this optimization and get to rewrite
responses with the origin server's permission, why not rewrite the CSS
to list various formats such that they get generated URLs (appended
query strings) and then make the font converter look at the query
string? (That is, if Cloudflare/mod_pagespeed truly want to do this,
the lack of Accept is not stopping them.)

> Obviously that's a lot harder for forward proxies to do. Reverse proxies are often
> the termination of https:// as well - so this transformation remains relevant in the
> https world we want.

Yeah, considering the https world we want, we should treat forward
proxies as adversaries and not something to cater to.

Patrick McManus

unread,
Oct 9, 2014, 12:02:27 PM10/9/14
to Gervase Markham, Ehsan Akhgari, Jonathan Kew, Patrick McManus, Henri Sivonen, dev-pl...@lists.mozilla.org, Jonas Sicking
> OK. So it can work if every browser that supports the format puts in in
> Accept: as soon as it begins support. That may be true of WebP; I don't
> believe it's true of WOFF. Is it?
>
>
you need to opt-in to the transcoding, yes. But you make it sound like you
can't use woff at all without transcoding, and that's not true. Doing the
right http thing doesn't interfere with also doing the right css thing.
Indeed we've been using woff with that crazy text/xml header - just
changing it to reflect our true preferences enables both scenarios.
Reply all
Reply to author
Forward
0 new messages