RE: A way forward

> From: Håkon Wium Lie [mailto:howcome@opera.com]
> Sent: Friday, July 24, 2009 1:59 PM


> So, authors should code their page according to what works in IE, not
> according to standards?


Until we have a fix, yes. In this case, the workaround results in perfectly valid
CSS as format hints are optional.


> This is exactly what we're trying to move away from: one vendor
> dominating to the point where they can veto features.

What veto ? I hereby acknowledge this to be an IE bug for the second time
and will acknowledge it however many times you  want me to. It will be fixed. Just like
we fixed hundreds of CSS bugs in IE8 and made our new standards mode the default.

>The format hint is there for a reason and people should and will use it.
>When the resulting EOT page comes out looking differently in different
> browsers, who will get the blame?

I'm pretty darn certain we will. I can't speak for Norway but around here,
if it looks different in IE, it's assumed to be IE's fault. Especially if CSS
is involved !

And I'm pretty sure you'll help to make sure the blame is laid at our feet :)

> You fixed 65 bugs and not the glaring one above? And not the one I
> reported in June 2007? How could you miss them?

For the tenth time, Hakon, the bug above has absolutely nothing to do with EOT decoding which is
what you asked about.

So one more time: this bug as well as the other one you brought up would still be present if we enabled TTF/OTF
as you keep suggesting. They have no connection whatsoever to what underlying on-disk file format is involved.

You seem to assume that adding support for raw TTFs would bypass the issue above, as if this CSS bug were somehow a function of what file format is involved. That assumption is completely wrong and, frankly, quite puzzling. Accepting a new format will not change anything to the CSS parser code that incorrectly rejects the format hint.

So one more time: why is it that such bugs would force you to emulate IE's bugs when the format is EOT-Lite, but
you have zero concern about the exact same risk if the file is raw ? What does our bug fixing
- or lack thereof - have to do with it ? Why would you be uncomfortable with us 'dominating to the point where
we can veto features' when the file format is X but have no such concern when it is Y even though the issue will still be present ?

That just makes no sense at all.

> Now, if you fixed 65 issues, can you show us one EOT page that works
> in IEx and not in IEy? You may choose your own x and y as long as they
> are greater than 5 or so.

Why would any of these fixes automatically result in an incompatibility ? Why, for instance, would a memory leak fix result in x working but not y ? Why would a performance or security fix have such an impact ?

There are no quirks at the format level, Hakon. A TTF with or without an EOT-Lite prefix is still a TTF. All the issues you bring up are IE bugs no one but Microsoft is obligated to fix. Supporting TTF/OTF, ZOT or .webfont or anything else will not fix any of them. The burden is on you to prove anyone expects you to emulate IE's web
font handling quirks.

So at this point I have absolutely no idea what you're talking about anymore. I'm lost. Feel free to contact me privately if you'd like to arrange a phone call. This is too time-consuming.

Received on Friday, 24 July 2009 21:39:56 UTC