WebKit, screwing faithful users since 2002
August, 13th 2010And I mean that in the nicest of ways.
Just last week WebKit faced a dilemma, a dilemma that has plagued tech industries since their inception: backwards compatibility. The WebKit team’s response so perfectly higlights the different between the thinking at Apple and Microsoft that I thought it was worth highlighting:
From Microsoft’s point of view (full disclosure, this was written in 2004):
Look at the scenario from the customer’s standpoint. You bought programs X, Y and Z. You then upgraded to Windows XP. Your computer now crashes randomly, and program Z doesn’t work at all. You’re going to tell your friends, “Don’t upgrade to Windows XP. It crashes randomly, and it’s not compatible with program Z.” Are you going to debug your system to determine that program X is causing the crashes, and that program Z doesn’t work because it is using undocumented window messags? Of course not. You’re going to return the Windows XP box for a refund. (You bought programs X, Y, and Z some months ago. The 30-day return policy no longer applies to them. The only thing you can return is Windows XP.)
And now, from Apple’s point of view:
One of the challenges we’ve encountered in switching to the HTML5 parsing algorithm is that some HTML documents rely on WebKit-specific parser quirks. For example, some websites use self-closing script tags (e.g., <script src=”…” />). WebKit is the only major rendering engine that supports this syntax (other browsers ignore the trailing “/” and look for a “</script>” tag). By implementing HTML5, we improve interoperability with other browsers at the cost of compatibility with some WebKit-specific content. In the long run, however, we believe these changes are good for the web platform as a whole.
So, what to do; branch your rendering engine and force new websites to explicitly ask for modern parsing or force existing websites to update their code?
We know Microsoft chose the former and the WebKit team the later. I don’t know that either approach is wrong, but my personal opinion leans towards the WebKit approach. It’s not helping anyone that IT administrators in 2010 can still rely on a rendering engine from the ’90s.
Comments
I see the former point, because I watch it happen every day. A person says that they hate their smart phone, when its a slow computer that’s really the issue, etc.
But thank god webkit is choosing to do things right. Follow the damned spec, and let it be the fault of people who do silly browser sniffing and use non-standard markup.
Posted at 01:14 PM on August 13, 2010
Greg, just to play devil’s advocate, what about when the spec either changes between versions or doesn’t do a good job explaining the implementation:
http://www.css3.info/border-radius-apple-vs-mozilla/
In some cases it’s not always the fault of “people who do silly browser sniffing and use non-standard markup.” I think there’s a bigger need for the spec to do a better job defining how backwards compatibility should be handled.
Posted at 01:19 PM on August 13, 2010
@mark: I guess i should clarify myself a bit to say that I meant browser sniffing chosen over feature detection. There are indeed cases where there is no alternative, but to say “if webkit, do this” is a mistake when you can say “if feature supported, do this”. There being my instance of ‘silly sniffing’. I can see where I came out wrong.
As far as bad spec, I thought the real issue to that was that the spec was not finished… Would you not also include border-radius along with -webkit-border-radius so that if the former gets implemented, it takes over?
I do see your point, but I mean that I prefer this approach of ‘lets get it right’ instead of ‘NOOO the bugs must stay so the web wont break!’ Which heads back down the road of ‘if you are hard sniffing without feature testing, you are causing the breakage, not the browser that wants to update to the correct way’.
Posted at 01:28 PM on August 13, 2010
Ah, to that then I agree fully. That’s some sound reasoning Greg.
Posted at 01:29 PM on August 13, 2010
Post a Comment