Jim Ley wrote:
On 2/3/06, Michel Fortin <[EMAIL PROTECTED]> 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/
