Re: Opera reparses as HTML when XML parse fails

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