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
On Tue, Oct 7, 2014 at 4:53 PM, Patrick McManus mcma...@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
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
On Wed, Oct 8, 2014 at 12:10 PM, Gervase Markham g...@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/
On Wed, Oct 8, 2014 at 6:10 AM, Gervase Markham 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
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
On Wed, Oct 8, 2014 at 11:18 AM, Jonathan Kew jfkth...@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
On Wed, Oct 8, 2014 at 5:34 PM, Patrick McManus mcma...@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
On Wed, Oct 8, 2014 at 11:44 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 5:34 PM, Patrick McManus mcma...@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
On 8/10/14 16:48, Patrick McManus wrote:
On Wed, Oct 8, 2014 at 11:44 AM, Anne van Kesteren ann...@annevk.nl
mailto:ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 5:34 PM, Patrick McManus
mcma...@ducksong.com mailto:mcma...@ducksong.com wrote:
intermediaries, as I mentioned
On Wed, Oct 8, 2014 at 12:03 PM, Jonathan Kew jfkth...@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
On Wed, Oct 8, 2014 at 2:15 PM, Robert Kaiser ka...@kairo.at 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
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);
}
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 hsivo...@hsivonen.fi wrote:
On Fri,
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*
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
On 3/10/14 01:11, Jonas Sicking wrote:
On Thu, Oct 2, 2014 at 9:42 AM, Jonathan Kew jfkth...@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
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
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).
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
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
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
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]
On Thu, Oct 2, 2014 at 9:42 AM, Jonathan Kew jfkth...@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
24 matches
Mail list logo
