Thursday, November 17, 2011

Clicking and Wrapping

Your browser does not support the canvas element, so this example will not function.

Another day, another JavaScript/canvas experiment.  This time around it's all about clicking squares with your mouse. Go ahead, click the squares. In general, this tiny example of hit detection using mouse events would not be worth even posting, much less talking about, but it illustrates some of my issues with the development world moving in the direction of HTML5/CSS3/JavaScript interfaces for everything.

I will leave the debate over the worthiness of JavaScript to people more knowledgeable than myself. Instead, I will gripe about using DOM events. In my little example here, if I want to let the canvas element handle mouse clicks, I just attach a mouse click event handler to it and I'm off to the races, right? Naturally, it isn't that simple. First, there is no standard way for the event's information to be passed into the event handling function.  Mozilla does it one way, Webkit another. Once you work your way past that with some boilerplate code that has to be repeated every time, you get to the bit that really made me tired. The event data for the mouse click, though attached to a particular element of the page, does not actually have any relationship to the element. Click a mouse on the canvas, and you have your choice of receiving coordinates for that event in  relation to the browser window or the browser client area, neither of which is actually useful for figuring out where in the canvas the mouse click happened. The example I got working walks from the canvas element up the DOM tree until it finds the body element, adding up the coordinate offsets as it goes, then adds the browser window padding to get the location of the canvas in window coordinates, which in turn are used to calculate the click position relative to the canvas's coordinates. Sigh.

Presumably, this lack of local coordinates has something to do with the event bubbling mechanism in the DOM. Or perhaps it is just laziness in the implementation that forces the programmer to manually calculate an element-relative mouse position rather than having the library do it. My ignorance about why this behavior would be desirable is an ever-present third possibility. In any case, the DOM and CSS are filled with these little oddities and incompatibilities.

People's answer for such irritants remains the same everywhere I've seen it: create utility functions/libraries/frameworks that overlay the standard interfaces. To be clear, I don't mean extensions that add functionality, or even things that simplify for specific purposes, but rather things that seek to provide exactly the same functionality in an "easier" or "better" way. Generally, I take a proliferation of such "utility" wrappers to mean that folks are hiding problems that might be better off fixed in the standards themselves.

Most of the time, programmers or even groups of programmers do not have the capacity to update the standards. We can't all be part of the W3C, for instance, and nothing would get done if we were. That said, judging by the number of available wrappers I'm seeing in my brush with web development, I suspect the debate over the future path (or death) of JavaScript may be even more important than people realize.

2 comments:

Lee said...

I don't know about anyone else, but I've been reading these bits about web development with much interest. I've been thinking of looking into it myself.

Got two questions - maybe you could address here or a future post:

What prompted you to learn HTML5/CSS/JS?

What resources are you using to learn that you have found useful?

Do you think these tools/standards developed in relative isolation from each other? Or at least lacked active cross-talk among those developing them?

Brian said...

As to what prompted me to learn, I'm trying to make at least token efforts to keep a handle on industry trends. Naturally, it isn't really that simple, but that's a big part of it.

I already knew a good deal of HTML and enough CSS to scrape by if I needed to (for instance, tweak a Blogger template). I did not ever learn any JavaScript(JS). It has become obvious that this web idea isn't going anywhere, and in fact, the web as UI is an expanding idea (Win 8 will have a JS/HTML UI, for instance). I had started reading and doing a little bit with JS on weekends before becoming unemployed, but I tend to spend my concentration budget on work tasks, leaving just sporadic weekends, which isn't really enough to get a good grasp on stuff.

Now that I'm unemployed, I am attempting to at least partially maintain my work schedule. Though the job search generates more work than I expected, I can get in much more time programming on these little projects, which for me are a great way to focus in on different aspects of the language.

The next step down the road is to look at some stylistic things that the JS community recommends, which should dovetail nicely into your other questions. So, stay tuned and if I can answer any questions you have, let me know.