Skip navigation.

miscoded

the web is a hack

My O statuses

Some of my past status messages on My Opera - just because I don't like old messages disappearing when replaced, and thought some of them were good enough to keep somewhere.. This blog post is "somewhere". Reverse chronological order.

  • Rich text is just plain text with more money
  • Those who do not invent wheels are stuck re-inventing them
  • work·ing group [wur-king groop] -noun. 1. The intersection of web technology and religion
  • Never attribute to stupidity that which can be adequately explained by deadlines.
  • It can be much harder to figure out why something works than why something is broken.

Feel free to improve on or re-use them :smile:

How to cook tag soup with XSLT

,

Working for Opera Software's QA department gives you in-depth perspectives on the web's wild and varied coding practises. I still wasn't prepared for the curious solutions that power the menu on the new Israeli rail website.

The XSLT markup/programming language is widely used to transform one sort of DOM into another - for example turning the DOM of a generic XML file into valid XHTML. Much of the benefit is that you're working on DOM trees - making it hard or impossible to create syntactically invalid pages.

Diving into the source code shows that the JavaScript coders working on the Rail site were asleep during their education's "what's the point of XSLT" lesson. The coding is unbelievable. It's more like an XML parser/serializer stress test than a production site. Now, I don't really know XSLT and trying to debug this confirms my impression that it must be one of the worse programming languages mankind has invented - but the point of this script is to generate HTML with XSLT *string concatenation*?!?? Look at this:

<xsl:value-of select="$attribute-name"/>="<xsl:call-template name="inner-attribute-text-value"><xsl:with-param name="attribute-value" select="$attribute-value"/></xsl:call-template>"

or

<xsl:template name="inner-text-tag-open"><xsl:text disable-output-escaping="yes"><</xsl:text></xsl:template>
<xsl:template name="inner-text-element-close">
<xsl:param name="element-name"/><xsl:call-template name="inner-text-tag-open"/>/<xsl:value-of select="$element-name"/><xsl:call-template name="inner-text-tag-close"/></xsl:template>
<xsl:template name="inner-text-tag-close"><xsl:text disable-output-escaping="yes">></xsl:text></xsl:template>


Yes, all that to create a text node containing e.g.
</div>
in a DOM they will serialize only to parse it again by setting innerHTML on some poor element..

When they in their wisdom chose to generate markup inside text nodes with their XSLT they run into the familiar problem: when is < going to start a tag and when is it going to live in a text node? Hence, < is sometimes escaped as an 'lt' entity to create proper text nodes with HTML source-as-text in them (see for example the instance of
&lt;
in the code above). Now, of course when they set innerHTML they do not want this entity to appear as a literal < so they do some pre-processing: all entities they want to change into proper < and > before setting innerHTML have a comment node next to them:

<!--nwlt-->&lt;TR class="nw-2r"&gt;<!--nwgt--><!--nwlt-->&lt;TD class="nw-2c"&gt;<!--nwgt-->


and their pre-processing is a simple string replace:

sHtml = sHtml.replace(/\<!--nwlt--\>&lt;/g,"<").replace(/&gt;\<!--nwgt--\>/g,">").replace(/\<[\/]?tbody\>/gi,"");


(Why they hate the poor TBODY so much they must strip it from the markup even though the browser will re-generate them in the DOM as soon as innerHTML is parsed I can't even begin to imagine.)

If you thought XML-based toolchains and processes were going to make the Web a saner place, think again. We have now seen that in the right hands, XSLT is just another recipe for tag soup.

Rabobank trusts only Rabokeys

, , ,

The Rabobank site in the Netherlands has a peculiar problem caused by an even weirder script. The forum discussion explains what the problem is: the site's search box doesn't allow you to type the letter T!

This is caused by a keypress handling JavaScript - it's all on one line so I made a re-formatted copy. If you thought the bug was weird, wait till you try figuring out what the point of the script is..

The basic logic that causes the problem is: "any browser that supports addEventListener() will support charCode but not keyCode in the keypress event". As it happens, Opera does support addEventListener() but not charCode. The site blocks keypress events with keyCode 116 which is the correct keyCode for a "t" keypress. (If we didn't support addEventListener they would listen for keyDown events with keyCode 116 instead - which is what they basically intended to do.)

With the problem analysis out of the way: I simply don't get what this site is trying to do. They set one handler for keypress events to cancel them if it's the F5 key, and another handler for keyup events to call location.reload() if it's the F5 key!? See here:

function F5DownEventHandler(evt){
this.target=evt.target||evt.srcElement;
this.keyCode=evt.keyCode||evt.which;
this.altKey=evt.altKey;
this.ctrlKey=evt.ctrlKey;
var targtype=this.target.type;
if(this.keyCode==116&&(evt.charCode==null||evt.charCode==0)){
return cancelKey(evt,this.keyCode,this.target)
}
if(this.keyCode==13&&(this.target.id=='z01'||this.target.id=='z02'||this.target.name=='z5'||this.target.id=='ra_searchfield2'||this.target.name=='z81')){
return cancelKey(evt,this.keyCode,this.target)
}
}
function F5UpEventHandler(evt){
this.target=evt.target||evt.srcElement;
this.keyCode=evt.keyCode||evt.which;
this.altKey=evt.altKey;
this.ctrlKey=evt.ctrlKey;
var targtype=this.target.type;
if(this.keyCode==116&&(evt.charCode==null||evt.charCode==0)){
window.location.reload(this.ctrlKey)
}
if(this.keyCode==13&&(this.target.id=='z01'||this.target.id=='z02'||this.target.name=='z5'||this.target.id=='ra_searchfield2'||this.target.name=='z81')){
this.target.parentNode.parentNode.submit()
}
}


So: "we don't mind that [F5] reloads the page and [enter] submits forms as long as we re-implement the browser's functionality in JavaScript".

Or: Rabobank trusts only Rabo-programmed keys?

I guess the browser's OWN implementation of [F5] and [enter] just wasn't buggy enough. :wink:

The holy wars of the humble alt

, , ,

Should the HTML5 specification require ALT attributes for all IMG tags? The raging debates on the public-html list seem endless. But let's see if we can get an overview..

  • Requiring ALT attributes hurts accessibility when tools or people insert empty or silly ALT attributes for significant images to pass validation.
  • Requiring ALT attributes helps accessibility when people educate themselves due to validation warnings and add useful ALT-contents, and when companies have to use ALT correctly due to legal threats.

Which effect is stronger and more valuable? This - in a nutshell - is what the ALT warriors should be discussing and researching. For example, there is some research here that indicates even low quality ALT text can be more helpful than none.

There is an incredible amount of time being spent on largely irrelevant arguments - from both sides. For example

  • Mass uploading images (e.g. Flickr) means people don't have time to write ALT texts, so Flickr can't require users to do so.

    This is just a matter of how conscientious the user is. Flickr should have an optional "description for blind people" box, users who did not fill in details would cause Flickr to output invalid HTML without ALT. So non-conscientious users create invalid HTML - to me, that sounds like a fact of life, not a spec bug.

  • Future software may be able to analyse images automatically and provide alternative text if ALT is omitted.

    Yeah, I'll believe in this intelligent software when I see it - and in particular I find it hard to believe that such hyper-intelligent software can't be configured to generate ALT-text for ALL images regardless of supplied ALT.

  • Requiring ALT means blind users can not upload images they don't know the contents of.

    Um, and uploading images you don't know the contents of is a major use case? I sort of can't see the motivation of the user for doing that.


Then there is a lot of hot air and big egos or at least claims that other people have big egos, claims that whoever disagrees with you is arrogant and doesn't listen etc.. I admit that the quality of discussion on the public-html W3C list disappoints me.

The current spec text seems pretty good. I think that in the interest of getting rid of invisible meta data and user-targeted text in hidden attributes it might also say that ALT can be omitted if aria-describedby points to some element in the page.

Now please move on to the next topic..

MS' Virtualearth claims Opera has no SVG support

, , , ...

As seen in this discussion, the BBC site uses a map from maps.live.com - and all we Opera users get is an error message:

We're sorry but your browser does not support BBC Sport's Olympic map.



Looking into it, first there is some Opera-sniffing from the BBC itself that detects Opera and displays the warning instead of the map.

With that sniffing neutralised, the map loads - but shows the United States, not Beijing. Come one Live Maps, admit you're wrong by several thousand kilometers.. Or?

Not in the mood to admit any fault, the script instead spits out an error laying the blame on us:

JavaScript - http://news.bbc.co.uk/sport2/hi/olympics/7493757.stm
Timeout thread: delay 10 ms
Error:
name: Msn.Drawing.Exception
message: Your Web browser does not support SVG or VML. Some graphics features may not function properly.
stacktrace:   Line 1 of linked script http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.1


So, my web browser does not support SVG, eh? Let's have a closer look at how you figured that out..

if(document.all)
         return new Msn.Drawing.VMLGraphic(e,b);
else{if(navigator.userAgent.indexOf("KHTML")!==-1)
         return new Msn.Drawing.SVGGraphic(e,b);
var c=0,f=0,g=new RegExp("Firefox/(.*)"),d=g.exec(navigator.userAgent);
if(d&&d.length>=2){
         var a=d[1].split(".");
         if(a){c=a[0];
         f=a[1];
         if(parseInt(c)>0&&parseInt(f)>=5||parseInt(c)>=2)
                  return new Msn.Drawing.SVGGraphic(e,b)

         }
}
throw new Msn.Drawing.Exception(L_GraphicsInitError_Text)


Yes, nothing but browser sniffing.. Not a single attempt at intelligent feature detection. Basically, by claiming Opera doesn't support SVG and can't load the map Microsoft is lying to the BBC and to our users.

Hotmail has class

, ,

Hotmail's choice of class attribute for its HTML element if you use Opera to access it just strikes me as very funny.. The output of a
javascript:alert(document.documentElement.className)
command is:



That's right. In other words
<html class="Firefox FF_Win FF_M1 FF_D5 Opera">
Is that what you would call exquisite confusion? :confused:

Aside, I hope to have the basic Hotmail working again in Opera 9.2x before the end of the day. After all, what's an insulting class declaration to a browser from the proudly egalitarian Scandinavian peninsula? We're above class, for sure p:

User JS contest time!

,

Have any good ideas for User JavaScripts? Or is there some broken site that you would like to fix but never got around to? It's time to fire up the editors and get coding - the User JavaScript contest is open for entries!

(Hey, look at the gorgeous prize - wish I could take part myself, too bad I'm an insider :-p..).

Keep those user scripts coming and have fun :-D

Release blues

,

I'm getting used to this. I've even learnt to expect it and prepare myself mentally. It's still true: releasing something is the most depressing job for somebody doing quality assurance.

So we finally have a new flagship desktop version. The long-awaited Opera 9.5 launched with - I hope - all the hype and thunder we could drum up. Literally thousands of bug fixes since the 9.2x versions, a fancy new skin, new features like getters and setters and Dragonfly that will make much of my work much easier - and yet I can think of few other things than the REMAINING bugs that we should have fixed. It's QA release blues time. Happened every time since Opera 6 final or so.

And with a new release comes new problems. The worst current compatibility issue is a problem with the TinyMCE editor, where legacy versions of TinyMCE will re-arrange your sentences in somewhat unpredictable ways when you press enter. (This is caused by TinyMCE detecting Opera to work around a bug in earlier Opera versions - we've now fixed the bug and unfortunately their workaround still runs and messes things up). To put this problem into the right perspective, TinyMCE is the default editor for Wordpress, and all admin screens in the millions of Wordpress installations out there are now suddenly broken in Opera. Ouch, Sir. What a gotcha!

This is fortunately precisely the sort of things we have browser.js for. There is a fix in already, needs some more tweaking to run in Wordpress' admin screen but I'll get that done. So thank God and Lars Erik for browser.js - when I can throw some fixes in after the final launch, release blues isn't quite as bad as it used to be :smile:.

I'm crossing my fingers that the patch will eventually be robust enough to work with most legacy TinyMCE installations out there. Wish me luck - or even better, tell me where it fails ;-o