YASB – Yet Another Symfony Blog

October 3, 2007

IE fixed, Opera is next

Filed under: Opera — Krof Drakula @ 1:13 pm

I’ve never liked Opera that much – have been trying to use it since version 7, but never got around to actually keep myself using it. I actually prefer IE7 over Opera 9 any given day of the week. Now, it seems, there’s yet another reason why I dislike Opera even more, but will have to keep an eye on it after all, even more so, after I discovered a nasty “feature.”

It all boils down to semantics, really. Opera prides itself on being the fastest browser on the planet. Well, from a user’s standpoint, I’d agree, pages do load smoothly in Opera, rendering is a shitload faster than Firefox (especially when it comes down to sliders, for example) and IE. Yes, I admit, it seems to work faster than other browsers. But there’s a price to pay – it doesn’t block scripts when they try accessing CSS properties when listening for the DOMContentLoaded event.

Why should that matter? Case in point: when you want to enable a user interface which uses unobtrusive scripting, the event fires BEFORE any external stylesheets get loaded. As a consequence, all hell breaks loose when you try styling elements. Say, for example, you want to position some div element to the left of some other, like so:

// lang php
<div>This is a box</div>
<div>This is its right neighbour</div>

// lang js
jQuery(document).ready(function() {
  jQuery("div:last").css({
    position: "absolute",
    top: jQuery("div:first").css("top"),
    left: jQuery("div:first").css("width")
  });
});

In this case, IE, Firefox and Konqueror (and, by induction, Safari) will load CSS first, then apply the CSS properties. Opera does not and fires the DOMContentLoaded event on a bare DOM. It helps when you use inline styling (jQuery then gets the correct styles), but what’s the point of using CSS if you declare everything inline anyways?

Opera sucks. From a developer’s point of view. And no, it’s not jQuery’s fault. It’s Opera’s implementation and interpretation of the aforementioned event.

Oh, and if you’re looking for a solution, there’s no way around using the onLoad. I know, you’re thinking “but the content flashes if you use onLoad!” You are correct. But Opera already flashes unstyled content before loading the external CSS (at least in my tests with an empty cache), so this shouldn’t bother you. It will bother the crowd (all 2% of them), but hey, at least the GUI works!

UPDATE: It seems the only consistent implementation of DOMContentLoaded within other browser is waiting for all elements (including scripts and CSS) to load before actually firing the event (up to Gecko 1.9+, Trident-based browsers don’t implement this event and must be simulated). The rationale behind this is that scripts loaded in the head might use styled elements after the CSS is applied, so that, for example, boxes are aligned or moved according to other elements’ positions and/or sizes. Even copying calculated styles from one element to the other.

Opera goes the other way around – it defined the event as the moment is stops parsing the bare HTML, leaving it up to the programmer to figure out cases when any of the files loads in a different order or if at all. It does improve responsiveness, showing the content before the actual styles are applied, but the downside is flashing unstyled content and gripes about checking applied styles first before trying to actually do anything with dynamically modifying interfaces.

6 Comments

  1. Hi there, Chris Mills from Opera here.

    Thanks for the post – I think you are being a litte harsh here, but then again, I’m biased ;-)

    This issue has had quite a lot of coverage – http://my.opera.com/nicomen/blog/2007/07/08/domcontentloaded-gotcha-with-external-stylesheets is a pretty useful post on the subject. We are thinking about what to do in this situation. While a lot of people think it would make sense to change how we do it, some prefer our current behavior. It may seem slightly annoying to some, but it’s not insurmountable.

    If you’d like to discuss the subject more, or talk to me about anything else, then feel free to drop me a mail – we always like to hear feedback from people about our browsers, positive or negative, as it all helps us to produce a better browsing experience for our users.

    best regards,

    Chris Mills Opera Software ASA

    Comment by Chris Mills — October 5, 2007 @ 3:45 pm

  2. Could be, must be all of the time spent on debugging for browsers that gives me an edgy feel. :)

    And yes, I am VERY open to discussion on handling and/or fixing this issue (though, I admit, is only one implementation of the grey area in the specification), so I am taking you up on that opera.

    See you on dev.opera.com!

    Comment by Krof Drakula — October 6, 2007 @ 7:38 pm

  3. I’m currently in the process of developing an PHP/MySQL application and have run into this issue with Opera. In an effort to not get too messy with my JavaScript and risk alienating support for my application in even more browsers, I have elected to declare the CSS styles inline. All this really means to me at the end of the day is that my application will feature some unnecessary bulk, and will be significantly less simple to customize for those downloading and using it.

    All I’ll say is that it’s disappointing and that Opera has definitely earned some demerit points from me, and it’s definitely shifted a bit more into the non-developer friendly column. What a shame.

    Comment by Brandon — February 21, 2008 @ 6:15 am

  4. Well jQuery 1.2.3 now includes the new ready() method that sniffs for Opera and firest the DOMReady method only after the CSS styles are applied, so this is a non-issue as of that version.

    On the one hand – you can’t blame them for interpreting the “rules” differently than the other browser. Technically, the DOM is ready after loading the bare-bones HTML and parsing it, the convenience other implementations offer is that they assume you’re trying to do whatever you want to do after the CSS has been applied, Opera just shifts that responsibility to the developer.

    While that may seem counter-intuitive, it actually gives the developer more freedom to choose whether or not to act before or after CSS has been applied instead of firing it after the document has been styled (like Firefox). True, it adds to the code when trying to emulate Firefox’s behaviour, but with high-traffic sites with slow loading times – adding behaviour (not dynamic JS styling) to elements before applying CSS could actually be an advantage.

    I just wish there was some sort of scheduling mechanism for JS-set CSS properties to be applied, kind of like the “defer” attribute, where the element’s CSS would be modified but applied only after other CSS files have had a crack at it.

    Comment by Krof Drakula — February 21, 2008 @ 9:13 am

  5. Thanks for the post

    Comment by firefox — July 23, 2008 @ 3:44 pm

  6. very nice info thank you

    Comment by baran — August 11, 2008 @ 7:20 pm

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress