Re: Announcing new font compression project
Raph Levien <[email protected]> Fri, 30 Mar 2012 17:06:10 -0700
| Newsgroups | gmane.comp.web.fonts |
|---|---|
| Message-ID | <CAFQ67bPjJVktx=DmfZcU7bBSQPvh2NHc_oanDXMwWSvSKt6D9g@mail.gmail.com> |
--20cf3074afc47f88e204bc7eb9d7 Content-Type: text/plain; charset=ISO-8859-1 It's a good question. In the interim, yes, you have to do multiple WOFF versions if you want the best compressed file the browser can handle. It will be some time before webmasters are able to completely ignore IE 6-8, though, so the reality is that people already have to do multiple versions, typically use toolkits of one kind or another to do it, and this just becomes one more choice. If you want to deploy something simple, just plain WOFF (version 1) is definitely an option. Simple sites that just use a latin font or two might find this approach preferable. For use cases such as CJK, though, the added compression would definitely be worthwhile. And, most modern browsers are getting better at updating and thus being able to deliver the latest version of standards implementation. I suspect that the time gap between, say, 95% of the installed base of browsers being able to support WOFF and 95% of the installed base being able to support WOFF 2 is, in fact, going to be pretty slim. This proposal is all about tradeoffs between added performance and complexity. If you didn't care about the file sizes, the added complexity wouldn't be worth it. Google does care about the performance, but again, this is definitely something that should be discussing and thinking through to make sure we're getting the tradeoffs right. Raph On Fri, Mar 30, 2012 at 4:50 PM, Tal Leming <[email protected]> wrote: > > On Mar 30, 2012, at 7:25 PM, Tab Atkins Jr. wrote: > > > On Fri, Mar 30, 2012 at 3:34 PM, Tal Leming <[email protected]> wrote: > >> On Mar 30, 2012, at 5:47 PM, Tab Atkins Jr. wrote: > >>>> Raph, presuming that this new compression method is judged worthwhile > -- > >>>> which seems likely --, how do you see it progressing? Is this > something that > >>>> you hope to be adopted by W3C as e.g. WOFF 2.0? > >>> > >>> Yes, that's the goal we're hoping for! > >> > >> Are you concerned that this will give WOFF, "the interoperable webfont > wrapper", interoperability problems? > > > > WOFF is interoperable because all the browsers agreed to implement it. > > I have a faint recollection of how that all went down. ;-) > > > Our hope is that this proposal is good enough to get the same > > treatment. > > What I mean is, I'm wondering about web authors having to deploy multiple > WOFF versions of the same font to cover all browsers that support WOFF. > Obviously WOFF 1.0 would hopefully still be supported so they could always > use that. But, if they want the smaller files and they want to target older > browsers, we're back to deploying multiple resources in a convoluted way. > > Don't get me wrong. Smaller files is a great goal and the early drafts > that Raph sent were very interesting. I just want to make sure that some > thought has been given to avoiding creating the problem that we set out to > solve in the first place. > > Tal > --20cf3074afc47f88e204bc7eb9d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It's a good question.<div><br></div><div>In the interim, yes, you have = to do multiple WOFF versions if you want the best compressed file the brows= er can handle. It will be some time before webmasters are able to completel= y ignore IE 6-8, though, so the reality is that people already have to do m= ultiple versions, typically use toolkits of one kind or another to do it, a= nd this just becomes one more choice.</div> <div><br></div><div>If you want to deploy something simple, just plain WOFF= (version 1) is definitely an option. Simple sites that just use a latin fo= nt or two might find this approach preferable. For use cases such as CJK, t= hough, the added compression would definitely be worthwhile.</div> <div><br></div><div>And, most modern browsers are getting better at updatin= g and thus being able to deliver the latest version of standards implementa= tion. I suspect that the time gap between, say, 95% of the installed base o= f browsers being able to support WOFF and 95% of the installed base being a= ble to support WOFF 2 is, in fact, going to be pretty slim.</div> <div><br></div><div>This proposal is all about tradeoffs between added perf= ormance and complexity. If you didn't care about the file sizes, the ad= ded complexity wouldn't be worth it. Google does care about the perform= ance, but again, this is definitely something that should be discussing and= thinking through to make sure we're getting the tradeoffs right.</div> <div><br></div><div>Raph</div><div><div><br><div class=3D"gmail_quote">On F= ri, Mar 30, 2012 at 4:50 PM, Tal Leming <span dir=3D"ltr"><<a href=3D"ma= ilto:[email protected]">[email protected]</a>></span> wrote:<br><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex"> <div class=3D"im"><br> On Mar 30, 2012, at 7:25 PM, Tab Atkins Jr. wrote:<br> <br> > On Fri, Mar 30, 2012 at 3:34 PM, Tal Leming <<a href=3D"mailto:tal@= typesupply.com">[email protected]</a>> wrote:<br> >> On Mar 30, 2012, at 5:47 PM, Tab Atkins Jr. wrote:<br> >>>> Raph, presuming that this new compression method is judged= worthwhile --<br> >>>> which seems likely --, how do you see it progressing? Is t= his something that<br> >>>> you hope to be adopted by W3C as e.g. WOFF 2.0?<br> >>><br> >>> Yes, that's the goal we're hoping for!<br> >><br> >> Are you concerned that this will give WOFF, "the interoperabl= e webfont wrapper", interoperability problems?<br> ><br> > WOFF is interoperable because all the browsers agreed to implement it.= <br> <br> </div>I have a faint recollection of how that all went down. ;-)<br> <div class=3D"im"><br> > Our hope is that this proposal is good enough to get the same<br> > treatment.<br> <br> </div>What I mean is, I'm wondering about web authors having to deploy = multiple WOFF versions of the same font to cover all browsers that support = WOFF. Obviously WOFF 1.0 would hopefully still be supported so they could a= lways use that. But, if they want the smaller files and they want to target= older browsers, we're back to deploying multiple resources in a convol= uted way.<br> <br> Don't get me wrong. Smaller files is a great goal and the early drafts = that Raph sent were very interesting. I just want to make sure that some th= ought has been given to avoiding creating the problem that we set out to so= lve in the first place.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> Tal<br> </font></span></blockquote></div><br></div></div> --20cf3074afc47f88e204bc7eb9d7--