- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Fri, 24 Jul 2009 16:00:37 +0000
- To: Håkon Wium Lie <howcome@opera.com>, John Daggett <jdaggett@mozilla.com>
- CC: Tab Atkins Jr. <jackalmage@gmail.com>, www-font <www-font@w3.org>
>From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf >Of Håkon Wium Lie >Indeed. Supporting EOTx has many problems, and I'm not sure the people >arguing for "backwards compatibility" realize the extent of the >problems that implementors and designers will run into. The only implementer who needs to fix these problems is Microsoft. All that is being talked about is file format interop. If someone unambiguously stated they expected you to also match IE's legacy behavior, I missed it. Can you share a reference ? For what it's worth, that is not my expectation at all. I certainly never heard anyone inside Microsoft state that other browser vendors should implement EOT as well as IE's behavioral quirks. If that is only your own interpretation, consider it unfounded. >The EOT format is just one aspect of this, another is the bugs and >quirks in IE's @font-face. For example, consider this page: > > http://www.princexml.com/howcome/2007/tests/include-fonts.html > >It's a simple one-liner that includes a library of fonts, of which >only one font is used. All the fonts are labelled as "truetype", a >format which IE has chosen not to support. However, IE downloads /all/ >the 400+ TrueType files when it displays this document. The test was >written in June 2007 and Microsoft was notified of the problem at the >time, but it hasn't been fixed; even IE8 exhibits this behavior. I'm >sure there are many such issues if you start digging. > >As a browser vendor, we spend significant amount of resources >debugging IE and replicating its bugs and quirks. These resources >would have been better spent improving support for standards. If we >start supporting EOTx for backwards compatibility reasons, people will >also expect us to replicate all the bugs and quirks in this part of IE >because some page somewhere depend on it. If we don't, people will >consider /our/ browser to be buggy. Can you please elaborate on how the testcase you reference affected you, what code you wrote to match this IE 'quirk' and why you did it ? As I very much doubt you wrote any code to match this IE behavior, how does the example support your argument ? Who expects you to replicate this issue ? Oddly enough, I was under the impression the world had changed a great deal in the past decade and web authors demanded Microsoft fix its quirks, bugs and non-standard behaviors. You know, like all the work we did around CSS2.1 ? >Bowing to IE will also limit web designers; perfectly valid CSS code >cannot be used due to limitations in IE. This is true of any CSS feature that legacy IE releases do not implement correctly and has nothing to do with web fonts. More importantly, we would need to fix the issues you bring up if we implemented raw font linking as well lest that forces you to match our quirks, right ? Yet you have repeatedly asked that we just support raw fonts, told me it was very cheap for us to do so and never voiced any fear of the behavioral incompatibility issues that would result. If that was truly your concern, then surely you wouldn't want us to come close to raw font linking before we've addressed our @font-face bugs lest you're stuck matching our implementation. Right ? This, incidentally, is also true for any other proposal on the table, whether .webfont or ZOT. At a minimum, this should demonstrate we're talking about orthogonal issues. Now that EOT-Lite addressed your objections, you're moving the goalpost to justify ignoring it, claiming it will force you to do work no one honestly believes you would actually do. (It's brazen but a tad too obvious, imo; you've accustomed me to better than that) But if you do have web author feedback indicating these legacy IE issues would be more of a practical impediment to web font adoption than the lack of a common file format then cross-browser support for raw fonts, EOT, ZOT or XYZ are not the problem at all. As this would be significant, I invite you to share this valuable feedback with us. Or invite the authors here. You are only asked to treat the font file embedded in an EOT-Lite resource the same you would treat the raw version. No more. IE's issues and shortcomings are Microsoft's to fix. (And yours to name and shame, of course) Pretending otherwise is simply not truthful, imo. >Therefore, and for all the other reasons mentioned in the thread, I do >not feel like replicating IE and its EOT format. It's not a trivial >job and it will cause browser vendors and web designers much pain. As no one asked you to 'replicate IE' and you have failed to establish why it would be strictly necessary for you to do so in this case I suggest we move on to the next red herring on your list. I'm still naively hoping we will run out of them. Someday.
Received on Friday, 24 July 2009 16:01:21 UTC