Claws, fangs, fur...

All web browsers that are built with ease of use in mind, sport accessibility options. Microsoft Internet Explorer has fared well in this respect, for as long as I can remember. Then Opera and Firefox started offering more. Microsoft wised up and added a stylesheet selector to its interface starting at MSIE8.

But, if you happen to be using Safari or Chrome, you're S.O.L. Apparently, the vendors don't care about user accessibility. No. They must hate you.

Why?

Because they don't offer a stylesheet switcher.

What's a stylesheet switcher?

If a web author is nice enough to think about the different machines on which their web page could be shown, the smart author offers the same well-formed web page in varying layouts. These layouts are called stylesheets. By setting the media attribute, a web author can determine whether a stylesheet should be loaded by a printer, a desktop web browser, a small-screen web browser, a big-screen projector, or something else.

Some authors offer different layouts for the same machine. Sometimes just to spice things up, and sometimes to make their web page easier to use under certain circumstances. Those stylesheets are called 'alternate stylesheets'. User-friendly web browsers recognise these, and offer a switch in their menu, to let the user switch between one layout and the other.

(The web authors know that this switch also comes in handy when testing their stylesheets for other media.)

A user-hating web browser fails to incorporate such a switch. Knowingly, they prevent the user from using something the web author has created to make their lives easier, resulting in the browser making the user's life harder.

Not good.

The web author then starts looking for ways to enable it anyway. I consider this evil: building into a web page, what the browser should've offered. We see other examples of such necessary evil: font size changers, rss feed icons, bookmarking facilities... all created to overcome browser deficiencies. Necessary evil.

Apparently, for stylesheets, the user-hating browsers seem Safari and Chrome. The way for the web author to get those browsers to offer a stylesheet switch to their users anyway, is by building it into their web page. This can be done using javascript.

All it seems to take, is look for the [rel=alternate stylesheet] and turn it into [rel=stylesheet]. (Edited to correct that: it also takes setting [disabled=false|true].) And the other way around, of course. And allow for some stylesheets to remain active while others are switched around.

I wonder what such switchers do to interface of the user-friendly browsers, that provide such a switch themselves...

So, we've got Ecmascript defining the language commonly known as Javascript. We've got W3C defining the DOM, the document object model, which represents an (x)html document loaded in a web browser, as well as the javascript interface to manipulate that document. And we've got the window model, which was developed before the more abstract DOM, but is still implemented and improved to this day.

So why can't browser vendors reach an understanding on how to do things? What possible advantage does it serve to make it harder on the web authors, to get stuff accomplished? I'm sure there's some benefit, beit monetary (doubtful, since in this case, the deviant is both open-sourced and free) or pride (also doubtful, since in this case, the deviant was rebuilt from the ground up), or something else (please enlighten me?).

What on earth am I talking about?

Events. Javascript events. More specifically: the click event, which happens when users click on a screen element, usually using a point-and-click device like a mouse, a pen, or their fingers.

What about it?

Coordinates. It seems very hard for browsers to let the web author know, what the coordinates are where the click was registered. And if we need that information to, for instance, drag an element around the screen, or collect the exact pixel information, we are faced with browsers that insist on doing things differently.

The other day, I added a colour picker to the Canvas Composition Studio.


Image: CCS Colour Picker

Based on the new colour picker in My Opera's style designer (which from the looks of it is part of the Yahoo User Interface library), it presents a swatch of colours and greys, from which the user can choose by simply clicking the desired colour.

In Opera, Safari, and Chrome, the click event holds the attributes offsetX and offsetY. This tells the web author exactly where the element was clicked. That coordinate can then be used for the Canvas method getImageData(x,y,width,height), which returns an rgba representation of the colour.

Firefox also returns supports the getImageData() method, also returning the rgba representation of the colour chosen. However, its click event does not hold the attributes offsetX and offsetY. Instead, it holds layerX and layerY. Yay, Netscape legacy. In itself, that isn't bad. A quick test for support of an attribute fixes the problem.

Not.

See, in the specific situation of the colour picker in the Canvas Composition Studio, layerX and layerY don't tell the web author where the element was clicked. As a matter of fact, layerY returns a value that puts it way outside of the clicked element...

Why? I don't know. All I know is that the coordinates provided by these attributes are useless. And the event also fails to provide any information as to how the coordinates are offset. So we're left to calculate the coordinate by ourselves.

To do so, we must match the event.clientX to the eventTarget.offsetLeft... which anyone would agree is (start sarcasm) totally obvious (end sarcasm) from cracking open the event and eventTarget objects...

Thank you, Firefox building team, for making this web author's job harder.

I haven't even tried catching this coordinate in Microsoft's excuse for a web browser, yet. Maybe that'll be easier, for a change.

For my Canvas Composition Studio over at Pantheon Online Games, the very first of its kind on the internet, I decided to implement multi-select. I wanted to allow a user to select more than one composition items and treat them at the same time.

Boy was I in for a surprise.

Read more...