On 8/10/14 15:44, Patrick McManus wrote:
On Wed, Oct 8, 2014 at 6:10 AM, Gervase Markham <g...@mozilla.org
<mailto:g...@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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
