> 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 transc
On Tue, Oct 7, 2014 at 4:53 PM, Patrick McManus 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/
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 environmen
On Wed, Oct 8, 2014 at 2:15 PM, Robert Kaiser wrote:
> 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 deci
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 with
On Wed, Oct 8, 2014 at 12:03 PM, Jonathan Kew 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-
On 8/10/14 16:48, Patrick McManus wrote:
On Wed, Oct 8, 2014 at 11:44 AM, Anne van Kesteren mailto:ann...@annevk.nl>> wrote:
On Wed, Oct 8, 2014 at 5:34 PM, Patrick McManus
mailto:mcma...@ducksong.com>> wrote:
> intermediaries, as I mentioned before, are a big reason. It provides a
On Wed, Oct 8, 2014 at 11:44 AM, Anne van Kesteren wrote:
> On Wed, Oct 8, 2014 at 5:34 PM, Patrick McManus
> 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
On Wed, Oct 8, 2014 at 5:34 PM, Patrick McManus 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-s
On Wed, Oct 8, 2014 at 11:18 AM, Jonathan Kew 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. Th
On 8/10/14 15:44, Patrick McManus wrote:
On Wed, Oct 8, 2014 at 6:10 AM, Gervase Markham 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 interm
On Wed, Oct 8, 2014 at 6:10 AM, Gervase Markham 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
On Wed, Oct 8, 2014 at 12:10 PM, Gervase Markham 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/
___
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 ac
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.
On Tue, Oct 7, 2014 at 9:39 AM, Henri Sivonen wrote:
> On Fri, Oct 3, 2014 at 3:11 A
On Fri, Oct 3, 2014 at 3:11 AM, Jonas Sicking 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");
>>
On Mon, Oct 6, 2014 at 11:07 PM, Zack Weinberg 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 ins
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/
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
f
On 3/10/14 01:11, Jonas Sicking wrote:
On Thu, Oct 2, 2014 at 9:42 AM, Jonathan Kew 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 (
On Thu, Oct 2, 2014 at 9:42 AM, Jonathan Kew 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) format
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
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
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 ch
On 2/10/14 16:20, Ralph Giles wrote:
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 red
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 wof
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).
T
27 matches
Mail list logo
