Tagged with 'javascript'
Safari vs. Safari: label
Prior to version 3 (now out of beta in Leopard), Safari was one of few mainstream browsers that didn’t do anything when the user clicked on a HTML input elements label text.
Most browsers treat a label-click as an element-click – that is, they “pretend” the user clicked directly on the element itself. For text fields, this is sort of a weird novelty, but for radio buttons and checkboxes, it’s a useful trick for expanding the “click area” of the element.
There are a variety of fixes out there. Unfortunately, the one I’m fond of is a bit too aggressive: it tries to solve this “problem” in all versions of Safari, including version 3, which already includes this behavior.
In other words, on a page with a “fix” for Safari 2’s bad label behavior, if you click on a label in Safari 3, it’s like clicking the element twice. Again, this is a novelty for text elements, but for checkboxes it’s effectively a non-click. (Users may even see the check flicker briefly.)
The solution I’ve been using triggers on a fairly primitive UserAgent string check. I might try to make the trigger more sophisticated (it looks like Safari 3 adds a “Version” string that previous versions didn’t have), but it’s frustratingly hard to test this kind of thing – I don’t think it’s possible to run version 2 & 3 side-by-side on my Mac, which leaves solutions like BrowserCam as the only option.
Things I Learned This Week
It’s been a busy week, working on a fancy/complicated Web project. Here’s a smattering of things I’ve learned:
IE7 breaks old assumptions…
Bug? Prototype, IE, getElementsByClassName, and "length"
I've been swearing like a foul-tempered pirate at IE a lot this week. This was one of the problems, something that seems to be a bug in the popular Prototype…