- From: Karl Dubost <karld@opera.com>
- Date: Wed, 14 Dec 2011 00:32:29 -0500
- To: Noah Mendelsohn <nrm@arcanedomain.com>
- Cc: "www-tag@w3.org" <www-tag@w3.org>, Sam Ruby <rubys@intertwingly.net>, Norm Walsh <ndw@nwalsh.com>
Le 13 déc. 2011 à 22:55, Noah Mendelsohn a écrit : > Of possible interest to those wrestling with HTML/XML interop: > > From Andreas Bovens [1] by way of Sam Ruby's blog [2] (the latter has an interesting comment thread). Opera is, at least in some cases, punting back to a forgiving HTML parse when strict XML rules result in an error. I'm partly behind that decision for having wrestled with site owners for one year. Let me explain a bit more the sequence of things. 1. A user goes to a Web site and get the XML parsing error message. a. the user thinks the Web site is broken b. the user thinks the Web browser is broken Consequence: In the two cases the user has a bad experience. Technical: The Web site sends HTML (valid or invalid) sent with application/xhtml+xml 2. If the user is tech savy, he/she is switching browsers and tries again. The Web site is now working in Firefox, Chrome, Safari and IE. Consequence: The user thinks Opera is broken. Technical: These browsers receive HTML sent with text/html. 3. Here you have Open The Web people at Opera who go "wtf?". I have nailed down the issue after a few weeks and because of finally someone answering my calls. [1] An engineer from Starbucks listened and replied. Together we found out the faulty library and he fixed it for the Starbucks Web site after ***two years*** being broken into Opera. Technical: The library decides to send application/xhtml+xml by default AND to do user agent sniffing for other browsers (but Opera) and send text/html. [1]: http://my.opera.com/karlcow/blog/2011/03/03/wrong-to-be-right-with-xhtml [2]: http://my.opera.com/ODIN/blog/2011/03/30/improving-interoperability-the-story-of-a-bug 4. This library is not maintained anymore but deployed on many sites specifically with IIS. We had a special package in our bug reporting system of around more than ~40 sites exhibiting the issue with some big brand included. Most of my contact attempts failed, the reasons are simple and fall into these categories * The site is already in production, the budgets are closed. * There is no contact information to reach out who is in charge * The person answers but just don't give a damn about Opera which is not in the web site stats. (Note the irony, we can't be in the stats) 5. We spent a lot of time and energy to try to solve this issue by contacting people, by trying to change things. No luck. So we decided maybe we should just give a better experience to users because Web site owners seem to not care enough. So we will recover automatically and throw an error message in the console. Note that it was not an easy decision and a painful one (specifically for me) Note that it is an issue which is happening in other configurations with HTTP headers, Javascript user agent sniffing, CSS vendor extensions, etc. There is a nasty consequence which relates to the combination of market shares and experimental features. When a platform has a big enough market share, an experimental feature is not anymore experimental, whatever the chosen extension mechanism. The feature is being deployed and used on Web sites heavily and breaks happily after in other browsers. It has the bad effect of forcing other browsers to implement the broken behavior of the first implementation with enough market shares. It is really kind of silly, but it's part of the reality. I have more nightmare stories to tell around the bonfire if you need :) -- Karl Dubost - http://dev.opera.com/ Developer Relations & Tools, Opera Software
Received on Wednesday, 14 December 2011 05:35:46 UTC