Claws, fangs, fur...

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.

Result: poorly.

http://www.omegajunior.net/code/tests/test_img_checkbox.html

Selecting a checkbox does select the checkbox... but it doesn't cause ANY tested browser to update the checkbox styling. To change the styling, authors must resort to scripting, like changing the class attribute using javascript.

This behaviour follows the HTML4 and CSS2 recommendations... which I consider quite disappointing. I'd love to see browsers react to attribute value changes by applying the CSS specified for the varying values. That way, less javascript is needed.

I can understand why browsers don't, and why their behaviour is recommended in HTML4 and CSS2: reacting to changes in several attributes for the same element may cause confusion and headaches for the author, let alone the browser programmers.

As if that ever stopped either of those groups from implementing something...

Added to the Code section of the OmegaJunior.Net: our own method of solving Sudoku puzzles, as a way of simulating the human thought process in computer programming.

We didn't set out to solve any and all Sudoku challenges out there... just that we created a program that mimics one single solving strategy, which can and indeed does fail with some specially crafted challenges. That strategy is called the "3DRLI": the "3 Degrees Reduction and Lock-In Strategy". The article describes the strategy and sports a javascript implementation of a solver using that strategy.

You may wish to use an HTML 5 / CSS 3-compatible browser to appreciate the full experience of this article and the YASS. Opera 9.6 / 10 and Google Chrome 1 come to mind. Recent nightly builds of Firefox 3 look promising and sport the fastest javascript engine for this application, but fail to support the innerText-property and some HTML5 elements.

Some minor flaws in Opera appear when using Opera 9.6 or newer. For instance: we've employed WebForms 2.0 Number Inputs. (That's an HTMLInputElement with its type set to "number".) Those inputs sport a max and a min property. Guess which browser does allow setting that property and validating for it... but fails to limit the user's input?

Some minor display flaws in many a browser appear. We've employed HTML5's Figure element, sporting a Legend element. Non-HTML5 browsers (there are many, currently), see the Legend element, and conclude that it must necessarily be part of a Fieldset element, which obviously is missing. So their rendering engine automatically puts one in... which then fouls up the display. Especially Firefox 2 and 3 are troubled by this flaw. Other browsers show a tiny spec of border where they assume the Fieldset should start, as Fieldsets generally are delineated using borders. Firefox 2 and 3 however, insist on enclosing the entire rest of the article in a border.

Looks promising for HTML5 rendering, doesn't it?