miscoded

There is a new and very Spolskyesque article on browsers, web standards and IE8 just out from the one and only Joel Spolsky.

Some selected quotes.. On the IE8 team being stuck between a rock and a hard place:

"The IE team has to walk a fine line..." This is incorrect. It’s not a fine line. It’s a line of negative width. There is no place to walk. They are damned if they do and damned if they don’t.

On why "standards" generally aren't:

despite general agreement on what constitutes kosher food, .. you will not find a rabbi from one ultra-orthodox community who is willing to eat at the home of a rabbi from a different ultra-orthodox community. And the web designers are discovering what the Jews of Mea Shearim have known for decades: just because you all agree to follow one book doesn’t ensure compatibility, because the laws are so complex and complicated and convoluted that it’s almost impossible to understand them all

standards are sometimes misinterpreted, sometimes confusing and even ambiguous (...) it’s a platonic ideal and a set of misinterpretations

It's all so true. The web is badly under-specified (and quite likely anything as large and complex as the web and its underlying technologies would be, wouldn't it?).

However, while Joel has been busy selling MP3 players on Mars and watching Microsoft there are a couple of developments he's missed: maybe, maybe Microsoft has moved from what he calls a "pragmatist" position to an "idealist" position - but at the same time, the good old consortium has sort of moved in the opposite direction, from the merry idealism of un-implementable X-es to the grassroots pragmatism of HTML5.

Today the standard ITSELF is in beta, and planning to be in beta for a while among other things in order to figure out if it is compatible with the Web content. Standards Trotskyists are not cool anymore.

Joel asserts that we're dealing with "some mythical, platonic 'standard' that is not actually implemented anywhere". Actually, any modern standard has a reference implementation, it's called a test suite. (Note that I'm using circular logic here: if a standard doesn't I won't call it "modern" ) HTML5 will even have reference parsers. It's not quite the mind-reading validator which checks that your CSS rules are according to the spec and do what you had in mind. A site's compliance to the standard can't be tested beyond basic structural validation - but the user agent's compliance can! And the IE team understands this situation very well, as evident from the fact that one of the spin-offs from their CSS 2.1 implementation is a public test suite!

For all those websites Joel found that were broken in IE8, some of them may be broken due to bugs in the new implementation, some because the IE team fixed their CSS parser before implementing the specific issue a parser-based hack worked around, some because of the site violating standards generally and the rest - the whole lot of them - because of user agent sniffing. Every site and every detail needs analysis. We don't know yet to what extent the improved standards support causes these failures. Microsoft will have to figure that out over time and see on each count what there is to do about it. Even if it's down to the nasty quirks of client-side browser detection it may be possible to add workarounds. For example, if it turns out that most CSS served within IE conditional comments is now harmful, IE8 could stop parsing STYLE and LINK rel=stylesheet tags inside conditional comments unless the comment explicitly targets IE8.

Finally, Joel describes a world where the players don't cooperate. Today browsers are from Venus, we've spent more than 10 years exploring each others' quirks and collaborate on making compromises. Compromises that can be disappointing but useful. Joel is excused for not noticing, since we already know he's from Mars.

Since I spend most of my day investigating problems with Opera, I'm sometimes too quick to take for granted that a problem is Opera's problem. So when I was exploring the JIRA site with an internal build of Opera, clicked a link saying JIRA video overview and saw nothing but an empty page and a very weird JS console error, I immediately started reducing the page to a small test case to file a bug report.

The error was completely incomprehensible, except that it seemed like Opera tried to execute some HTML markup as JavaScript:

Inline script compilation
Syntax error while loading: line 6 of inline script at http://www.atlassian.com/software/jira/videos/jira_video/jira_video.jsp :
Expected expression
<script language="JavaScript"></script><noscript></noscript><!--/DO NOT REMOVE/-->
--------------------------------------^

This sometimes happens if a file has a SCRIPT element with a SRC that links to a HTML file. But the page had only two external .js files, and neither was broken.

After a bit of trial and error I had a minimal file. The error occurs because a starting HTML comment inside a SCRIPT tag does not have a matching closing comment inside that SCRIPT tag. So Opera looks ahead for another closing comment, and it seems this confusion means some of the markup is seen as being "inside" the script.

Now I was in for a great surprise: both IE7 and Firefox 2 did exactly what Opera did when displaying my attempted test case! Have a look:
jira.htm
My first thought was that while minimising I had removed something that made the site work in IE and Firefox. Then I tried watching the video in either browser.. No joy. JIRA's video page is broken (by an Omniture SiteCatalyst script that carelessly omits a //--> from a script element) and - wow - they have broken it in a cross-browser compatible way!

Well, I just added that missing closing comment and re-loaded the page from cache in Opera - but I must be the only person who has seen JIRA's demo video recently

A colleague just noticed that the otherwise excellent jQuery JS library has an "isFunction" method that relies on decompiling functions to figure out if they really, really are functions. This is not a good idea because decompiling functions is an optional feature of the ES-262 spec. It is slow and requires too many resources for certain low-end platforms, so it is not supported by any of the Opera Mobile versions.

Here's the code, complete with a frustrated comment from John Resig himself:

// This may seem like some crazy code, but trust me when I say that this
// is the only cross-browser way to do this. --John
isFunction: function( fn ) {
return !!fn && typeof fn != "string" && !fn.nodeName && 
fn.constructor != Array && /function/i.test( fn + "" );
}

John, I feel your pain and that code clearly took quite some effort and testing across various browsers passing in various types of objects - IE collections allowing ()-reference, anyone? It wouldn't surprise me if Opera is one of the culprits that caused you problems here since we try to support some of IE's weirdness and hence "typeof" sometimes returns 'function' when you'd expect it not to.

So I'm sorry to break it to you, but /function/i.test( fn + "" ) won't do what you think on Opera's mobile versions, causing really-hard-to-track-down bugs.

May I suggest adding the below workaround somewhere?

if( (function(){}).toString().match(/\^[ecmascript/i) ) Function.prototype.toString = function(){return 'function'};

Should be all you need..

Short status update: They've been busy at Yahoo moving accounts from Yahoo Mail Beta to Yahoo Mail 1.0 - all but one of my usual test accounts have suddenly lost the "Beta" text from the icons. Today's weekly build isn't bad either, after a couple of weeks where Y!Mail seemed to hit every crash bug in the internal builds, it's finally stabilised and runs pretty smoothly.

On Monday (or possibly even earlier) a new browser.js will go public for 9.5, and it should resolve most of the issues that currently prevent Y!Mail from loading in the new weekly build. Sorry to keep you waiting but I was working later than my server admin colleague tonight..

This time, to get Y!Mail working I had to remove several patches. Since our shiny, improved getters and setters support enables the Y!Mail compatibility layers to do their job, patching should hardly be required anymore...

Actually, the current version of browser.js messes it all up and gets in the way - several of the errors you see if you try to load Y!Mail right now is from browser.js code where the old patches are incompatible with the new getters and setters stuff!

This is great news. Removing patches is good. And I've never seen Y!Mail work better with Opera than Y!Mail 1.0 and 9.5 9594 with the new browser.js - even chat works nicely! You Yahoo mail users should have something to look forward to