Skip navigation.

exploreopera

| Help

Sign up | Help

Posts tagged with "open the web"

being compatible with the dark matter of the web

, , , ...

A forum thread asks the oft rehearsed question "why can't Opera be more compatible with websites". Allow me to respond with a blog post since that discussion is somewhat noisy already..

Simply: Opera 9 already supports the W3C and ECMA standards that are widely used, it also supports lots of non-standard and pre-standard features to the extent that these are documented by others or by our own testing. Compatibility today is in the details. A big, generic question like "what technologies should Opera support to be more compatible" won't get you far. If a problem isn't caused by sniffing or similar broken code, the likely culprit is a minor detail being different across browsers, not having to support another "technology". Hence, discussing compatibility needs to dive into the technical details and avoid sweeping generalisations - and I hope to provide some examples that are specific enough to perhaps bring the discussion forward:

event.button

Careful and correct implementation of standards goes a long way, unless standards differ from reality. Values of event.button is a damned-if-you-do, damned-if-you-dont scenario: IE and the DOM standard numbers mouse buttons differently, and there is lots of content depending on either of these. Depending on how the site detects "IE" custom scroll bars, mouse-drags and other fancy mouse usage stops working. Options?
  • Break this half of the web
  • Break the other half of the web
  • Cry and tear your hair out

Bohoo.

XMLDocument object
This is an interesting Firefox thingy. It's not in any standard, Firefox just happens to make it available to scripts because internal Firefox architecture has an "XMLDocument" class. While this probably makes sense for Firefox's architecture it doesn't make sense for Opera's. We didn't really notice the XMLDocument object until we investigated why Sarissa doesn't work 100% in Opera. Yahoo Mail Beta uses it too. Options?
  • Complain to Mozilla because cross-browser compatibility suffers from their exposed internals?
  • Spend time tracking how it works and implement it as yet-another-nonstandard-we-must-support?
  • Bug Mozilla to have it standardised so that we can implement it?
  • Nag websites about not using it, or detecting it correctly?


XUL
Some stuff mentioned in the forum thread uses XUL. Yes, this is a reasonably open, non-standard technology invented by Mozilla which Opera has chosen not to support. The main reason we don't is very pragmatic: there hasn't been that much demand for it. Lack of this technology is very unlikely to be the reason why your Opera-newbie friends complain about sites not working in Opera. Options?
  • Support
  • Not support
  • Wait for standardisation, then support.
  • Wait for actual usage growing on the web, then support


Windows MediaPlayer scripting
Now this is truly a skeleton in the compatibility closet. WMP's latest scripting support only works with the ActiveX control. Since Opera doesn't support ActiveX we're stuck with an outdated version of WMP's scripting engine, and quite a lot of fancy video player user interfaces on the web are not written to fall back to use the older version if ActiveX isn't available. Did you say "standard"? Bah, there is no such thing in the world of plugin vendors - vendor lock-in is the name of the game here. WMP, Real, QuickTime, Flash - the scripting interfaces are all different, and once a developer has learnt one and a company has invested in building a website on one the cost of switching is naturally high. Options?
  • Support ActiveX?
  • Fake ActiveX?
  • Add some other kind of compatibility layer?
  • Continue the endless quest of web openers?


Dark matter

They say most of the universe consists of dark matter. Many, many compatibility problems are caused by the dark matter known as convention. All the stuff that we have to do simply because other browsers do. If a site forgets to add a closing SPAN tag, the parser constructing the DOM is going to have to try to compensate. When it turns out that IE's innerHTML in such a case apparently is inconsistent with the DOM it has built, kaboom - pictures.aol.com is broken in Opera. Hit by the dark matter..

Some things can't and won't be standardised (who would have thought that simply taking less than one second opening a popup window breaks a page??) but one of the greatest frontiers of web compatibility work is to expand the standards to cover much more of the "dark matter". WHATWG rises to the challenge and W3C seems to be getting the message that the dark matter of convention is one of the most serious threats to cross-browser compatibility.

Q&A with David

, ,

Great interview with Web Opener David Storey - don't miss it.

Web 2.0: same sniff, new wrapping?

, , , ...

Eskobo uses the Microsoft Atlas framework. Atlas is pretty nifty actually, I especially appreciate it for being readable and un-obfuscated so it's simple for me to debug, unlike several other . unreadable . nightmares out there..

The problem at Eskobo is that you can not "minimize" the boxes with the little triangle on the left. Here's a screenshot demonstrating how I removed a single anti-Opera statement to enable that feature. Works like a charm once you disable their pointless "do not do this in Opera" crap. In this supposedly enlighted age of Web 2.0 and unobtrusive JavaScripts and AJAX enhancements.. Why do I still have to waste my time on ridiculous stuff like this? :mad:



Get a clue, guys.

To try this at home: load Eskobo, view source, search for and remove
if(cart_browser_opera){return false;};

Save and/or re-load from cache (as in using the menu entry Tools > Advanced > Re-load from cache in 8.5 or the "Reload from cache" button in 9's editor).

Site patching works

, , , ...

Back then when we added the browser.js feature I heard some sceptical voices saying that fixing broken sites automatically was a bad idea because then the site had no incentive for fixing it themselves. The risk was that the web might become even more fragmented, with even worse examples of incompatible code because Opera would automagically fix things and cloak the faults of the webmasters.

Now call me an optimist, but we have about half a year's experience with browser.js and I'm seeing evidence of the opposite. Three good examples are allmusic.com, shockwave.com and atomfilms.com - they all had long-standing issues with Opera, they were patched successfully with browser.js and a few months after the patch, each site was fixed by the webmaster!

So perhaps, perhaps site patching does exactly what we hoped: increases Opera's ranking in site statistics by making previously unusable sites available to Opera users, thereby making webmasters more concerned about Opera compatibility (because such decisions are often based on browser stats) and eventually creating a more compatible web.

Of course it also helps that we always contact the website before or while we patch it.

It is no accident that browser.js is a simple text file written in readable and reasonably well commented JavaScript and that it always outputs some text in the JavaScript console when it does something. We could have done things differently, we considered pre-compiling the script somehow for performance - but in the end, it was most important to keep the whole feature as open for inspection as possible. And that pays off: we hear from web developers who sit down and read through the section of browser.js that is used on their website, for to-the-point, updated information about where in their site there are problems and scope for improvements. Thus browser.js itself becomes a way of communicating directly to the web developers we need to reach!

Hey, some of the fixes in browser.js can even be cut and pasted into the site to solve the problem :smile:

Yes, I think site patching works - and every patch I can remove from browser.js is a vote for that conclusion.

From the web evangelism surrealism department

,

Phone call to AOL support person:

- A page on your site does not work in my browser, it constantly re-loads

(AOL person types in dictated URL. Argh, why is there no E-mail support...)

- It works fine here

- Well, that's presumably because you use IE. This error in the page does not happen in IE. The script detects that you are not using IE and sends you to this page, in other words causes a reload if you ARE on this page already..

- The MyMobile site will only work with IE.

- But this page is MEANT FOR non-IE users. It contains information that is inaccessible to the people you actually want to see it, because of an error in your script.

- Well, we have decided to target Internet Explorer so if you use another browser..

Rest of discussion snipped..

He finally promised to "file a ticket". The error still there months later...

Imagine staying up late to catch U.S. working hours, queueing in an expensive overseas phone call, spending ten minutes of your life trying to persuade someone that something is a problem - to try to make them fix a ridiculous page saying "please use a different browser".... Take my word for it, web evangelism can be pure surrealism.

And I still don't have useful contacts at AOL :frown: The definition of "useful" being someone I could call to argue that Opera shouldn't be sent to that page in the first place.