On Tue, Feb 7, 2012 at 11:31 AM, Asa Dotzler <
a...@mozilla.org> wrote:
> On 2/7/2012 1:02 AM, Henri Sivonen wrote:
>>
>> On Tue, Feb 7, 2012 at 10:09 AM, Asa Dotzler<
a...@mozilla.org> wrote:
>>>
>>> I'd like to better understand why we think it's the right trade-off to
>>> break
>>>
>>> major websites in order to shave a some bits off of our HTTP headers.
>>>
>>>
http://hsivonen.iki.fi/accept-charset/
>>>
https://bugzilla.mozilla.org/show_bug.cgi?id=572652
>>>
>>> What is the user benefit here that outweighs the loss of compatibility
>>> with
>>> a major site -- in this case, the second most popular translation service
>>> on
>>> the Web?
>>
>>
>> First of all, breaking one major site is nothing new. For example
>
>
> I don't accept that as justification for doing more of it. "We get a major
> win" might be good enough justification but "We've done it in the past"
> isn't good enough, IMO.
I agree that that's not justification enough. I responded that way
because your message made it look like you were saying this was some
kind of new phenomenon. Upon re-reading what you said, I don't think
the wording of your message actually suggested anything about the
recency of the phenomenon. Sorry.
(Quotes re-ordered below.)
> You're making a case for breaking sites when there is a clear win for the
> platform AND we have reasonable confidence that the major sites will fix
> themselves
...
> Sometimes breakage is hard to avoid. I get that. Sometimes breaking sites
> gives the platform a big boost. I get that. This, IMO, is not one of those
> cases.
...
> This is not new bloat. We've been carrying it forever. We could have
> continued to carry it.
The DOM namespace unification thing that broke Facebook (and that
Safari had already done so Facebook had a code path for it) was bloat
we had been carrying around forever. Before making the change *and
some further changes that it enabled*, we didn't know what the full
benefit would be. The change turned out to be an overall DOM
performance win even though it was originally motivated by code
aesthetics, simplicity and maintainability.
As for breaking Facebook by introducing native JSON, we *could* have
told TC39 to give the entry point to native JSON a different name
since the name they used was taken by Facebook.
We don't *have to* break some Google code by taking away or changing
moz-prefixed animation APIs. We *could* keep the moz-prefixed stuff
around forever while *also* implementing the W3C spec without prefix.
We didn't *have to* break some Google code by moving the version
number in the UA string to double digits. We *could* have done what
Opera did and carry around a longer UA string around forever.
What's out of the ordinary here is that the patch got backed out from
four release trains.
> Apparently Chrome isn't in a hurry to drop it and
> they're hyper-sensitive to performance issues. I just don't get the rush
> knowing it was going to break things that were not likely to get fixed with
> haste.
The more likely explanation is that there's a ton of stuff in a
browser and they didn't happen to notice the situation around this
particular thing. A couple of people on their team seemed to act as if
they considered sending Accept-Charset a bug in Chrome after the
correction in
http://hsivonen.iki.fi/accept-charset/ alerted them to
it.
In a way, it's sad that we can't be leading on stuff like this. This
wouldn't have happened if IE hadn't already been the leader. And now
it seems that we should be waiting for Chrome to move before us, too.
:-(
> When this broke yahoo search with non-ascii characters and babelfish we
> backed it out. I was there when we did it the first couple of times. I
> wasn't there advocating for backing it out later because I'd assumed we all
> agreed that breaking Yahoo was not an acceptable cost for this "win". At
> some point, half of the Yahoo breakage was fixed by Yahoo and people decided
> that was good enough.
FWIW, I was a bit surprised to see that patch made it to release
before Y! fixed Babelfish.
> Except that we knew about it ahead of time and they weren't in any hurry in
> fixing it.
Although I was surprised that the patch made it to release before
Babelfish had been fixed, in retrospect, I think deferring the patch
indefinitely would have set a bad precedent. I think we shouldn't be
signaling to Google / Facebook / Yahoo! / Live.com/Hotmail/Bing that
we'll refrain from aligning Gecko with IE or Safari behavior if they
put us on a different code path by browser sniffing and are slow to
fix it.
If we are no longer OK with breaking sites/app in a "too big to fail"
category, I think we should start doing Safari/Chrome-style (not
IE-style or Opera-style) site-specific hacks instead of letting others
make us defer alignment with IE/Safari by multiple release trains.
> (Do we even have data that gives us any confidence at all that
> other much smaller sites weren't broken by this?)
We never have confidence beyond not seeing an influx of bug reports.
> Winning over users is much more
> difficult and losing them is a whole lot easier.
Indeed.
(Trying to move this to dev-platform again, since this thread is
really about how we change Gecko instead of how we change Firefox
around it.)