[whatwg] getElementsByClassName()

[Lachlan Hunt]

Jim Ley wrote:
> On 2/3/06, Michel Fortin <michel.fortin at michelf.com> wrote:
>> Le 2006-02-03 à 09:30, Jim Ley a écrit :
>> So to generalize the use case, when I want to attach an event to a
>> child element or an element linked by any other mean to the element
>> having that class, I can't use addEventListenerToClass.
> 
> So this shows that addEventListenerToCSSSelector is really what you
> want so you can attach it to A's that are children of the class
> doesn't it?

I don't agree with that, there are many valid use cases for a 
getElementsByClassName and while it is true that many of them are event 
related, that doesn't mean they all are.  For example, if an author 
marked up dates in their document like this (due to the lack of a date 
element)

<span class="date">2006-02-03T01:30Z</date>

A script could get all the elements with the class name of "date", parse 
it and modify it to the user's preferred time zone and format.  So, for 
example, the script could change it to this for a typical Australian user:

<span class="date">03 Feb 2006 12:30 (local time)</span>

Whereas, an American user may get this instead:

<span class="date">Feb 02, 2006 20:30 (local time)</span>


Regarding the idea for addEventListenerToSelector, while I don't think 
it should be implemented as a function like that, the idea of attaching 
events based on a selector is quite reasonable.  What if there was a way 
to declaratively attach events to elements in the same way that the 
on[event] attributes in HTML do, but with same level of abstraction 
provided by CSS using selectors.  It could even be used for some the 
event-related use cases for getElementsByClassName, simply by using a 
class selector.

Of course, there is XML Events, which also seems to be declarative, but 
from what I know about it (not very much), it seems to be limited to 
specifying IDs of the target/observer elements and putting IDs on every 
target element is not always convenient; or otherwise embedding the 
event attributes (like ev:handler, ev:event, etc) throughout the markup, 
just like with the HTML on[event] attributes.

There's also IE's behaviours using HTCs and the proprietary 'behavior' 
property in CSS, but it seems rather complex and HTCs look quite messy 
(they seem to be a weird mixture of proprietary HTML with some XML 
syntax), although perhaps they were on the right track with the concept 
of making them declarative.

For example, using this CSS-like syntax (but it's not CSS).

selector {
   event-name: function();
}

For example, using a real (rather nifty) javascript example, called Lightbox
http://www.huddletogether.com/projects/lightbox/

The basic way in which this works is to look for A elements with a rel 
attribute containing a "lightbox" value.  For everyone it finds, it 
attaches a click event handler, which then handles all the funky 
animation and loading of the image within the same page.

Using the above css-like syntax, that could be achieved by doing this:

a[rel=lightbox] {
   click: showLightbox(attr(href), attr(title));
}

I know it's not an extremely well thought out idea, it's just a bit of 
brainstorming, but it could always be improved.  It also seems to be a 
little out of scope for the WhatWG.

-- 
Lachlan Hunt
http://lachy.id.au/