The Good, the Bad and the Ugly 8

The Good

Attribute handling in the DOM is finally working. MS said that this was one of the hardest things to fix and yet they did it.

hashchange events simplify history management. I wish they implemented more of the HTML5 proposals when it comes to history state management but getting an event when the hash changes is so much better than what we have today.

Acid2

querySelector and querySelectorAll… nuf said

JScript is faster. There is a lot of room for improvements but this is a big step in the right direction.

postMessage. Now that all new browsers support it we can finally get rid of all those ugly, complicated and slow cross domain hacks that tons of sites rely on today.

Standard mode as good as possible by default. No need to opt in to get the best possible renderer.

Changes to namespaces in XHTML allowing third party to, in theory, implement binary behaviors for SVG embedded in XHTML.

ARIA support. I remember the hoops we had to go through to get Bindows 508 compliant. If there was only ARIA support back then it would have saved several months worth of frustrating work.

The Bad

VML is not currently supportd in IE8 mode. This would not be so bad if canvas or SVG was supported but today sites have come to rely on being able to use vector graphics in web pages. MS says “Layout and rendering behaviors, proprietary features upon which VML is built, are not yet implemented in IE8 standards mode. Look for this feature in a future beta release.”

No opacity, rgba() nor any rounded corners in sight.

Yet another browser check needed. We used to only need to check the user agent, then we also had to check the document.compatMode and now we have to also check document.documentMode. Would it not have made more sense to just return MSIE7 in the user agent if IE8 is operating in IE7 mode?

No bug fixes to JScript. MS has an excellent paper covering their deviations from ES3 but yet they managed to improve on that situation. MS is waiting in ES3.1 but I think it would have been safe to fix some of these issues already. ES3.1 is on the fast track but I doubt there is room for any differences to what is already available in WebKit, Firefox and Opera today (which have tons of ES3.1 features and bug fixes today).

Still no way to get the computed style.

The Ugly

HTML5, and the W3C Web App group has a proposed standard for doing cross site XHR that is implemented in WebKit, Firefox (and Opera?). Yet, Microsoft introduces XDomainRequest which is very crippled.

MS built their DOM storage implementation on top of their old persistence behavior which uses XML files to store the data and since it does disk writes MS decided that their implementation would not be good enough to follow the proposed spec they made the whole API asynchronous. DOM storage is implemented in WebKit, Firefox and Opera.

Where is the DOM? MS kept asking what people wanted and every list I’ve seen has included DOM Level 2 events and DOM level 2 in general.

Acid3. 16/100 is not acceptable

8 thoughts on “The Good, the Bad and the Ugly

  1. Diego Mar 6, 2008 13:23

    My IE8 makes 17/100 in Acid3… but, ugly too.

  2. Jeff Schiller Mar 6, 2008 17:17

    Can you provide a link to where MS mentions future Beta and VML?

    Thanks,
    Jeff

  3. Ralf Stoltze Mar 8, 2008 17:20

    Erik,

    You state that Opera implements DOM storage. Could you point me to a resource which supports this? Same with Webkit. I know they have DB storage, but DOM storage?
    http://bugs.webkit.org/show_bug.cgi?id=11245

    Side note: Quite funny to see that MS picked up the name “DOM storage” from the Mozilla guys. Seems like HTML 5′s “Client-side session and persistent storage of name/value pairs” isn’t that catchy. :)

    Thanks!

  4. Erik Arvidsson Mar 8, 2008 17:52

    Ralf: You are correct. Neither Opera 9.5 or nightly webkits supports HTML5 storage… I’ll update my post

  5. Pingback: entropia » Blog Archive » IE8 issues

  6. Robert Nyman Mar 10, 2008 01:26

    querySelector and querySelectorAll… nuf said

    Well, not really. I was impressed at first, but from what I’ve seen, their support only covers up to CSS 2.1 and some CSS 3 features. Since WebKit, and any other web browser implementing this soon, will naturally support CSS 3 completely as well, this means yet another check and workaround, which in many cases will render querySelectorAll useless.

  7. Erik Arvidsson Mar 10, 2008 20:54

    Robert: I don’t agree with you. CSS2.1 might miss some useful selectors but most of the CSS3 one are pretty useless, especially in the context of scripting. Which ones do you think are crucial? If these stops you from using querySelector then we need to make sure that MS understands this.

    Also, see John Resig’s post about CSS3 selectors that people actually use, http://ejohn.org/blog/selectors-that-people-actually-use/ If you remove the ones that people don’t really use then there are not that many left for MS to add and they seemed to be willing to add parts of CSS3 as needed (they added box-sizing).

  8. Robert Nyman Apr 2, 2008 11:44

    Sorry for a late reply:

    I think that in CSS 3, the new attribute selectors, nth-child variants and pseudo-classes such as :checked etc definitely can be useful, while not all the time.

    With all respect to John, his post is interesting and definitely good information since I believe that those selectors are amongst the most common ones, but there a lot more web sites out there who use other selectors as well.

    I think, just as it has been for other web browsers, if they get the general support into their CSS base then it will be a fairly easy feat to get it into querySelectorAll as well.

Comments are closed.