Re: Yet Another Suggestion For CSS3 (YASF-CSS3): Events

On Fri, Feb 19, 1999 at 08:08:25AM +1000, ptorr@vantsys.com.au wrote:

> > It would be nice if I could
> > specify a mouse click handler for the entire class, so I don't waste time
> > (and probably sometimes forget) specifying the handler each time.
> 
> This kind of functionality is provided by DHTML "behaviours", which are
> something Microsoft has put into Internet Explorer 5, and have submitted to
> the W3C for consideration. It uses a new CSS attribute 'behavior' (ugh,
> should be a "u" in there!) to specify a behaviour for a given CSS class.
> That behaviour can add new properties to those elements, as well as provide
> standard event handlers (eg, onclick()) for every element of the class.
> 
> http://www.microsoft.com/workshop/author/behaviors/overview.asp

Hmm. Personally, I have a few problems with their actual implementation,
which I hope the W3C will sort out if they take anything like this on board.

1.	URL (surely URI? :-) given with no content type and/or language

... so if someone writes it in VBScript, all browsers that don't implement
VBScript still have to download it. (Okay, the page author could be nice,
and allow content negotiation on this ...)

This is really the same problem, although more potent, as generally being
unable to optionally specify content type on the CSS url() value ... yes, in
theory a browser could just HEAD the document, and keep the connection open
- but that's unjustified.

2.	Seems cumbersome to use from Java.

As I see it, from Java you'd have to attach my handlers through the DOM
somehow. This is very inflexible; it would be nicer to be able to do
something like:

url_with_method(#objID.method())

Obviously that's not a sensible syntax, but you see what I'm getting at; I
might want to write an applet (or a reusable binary component using any
language - similarly with a script, in fact) that provides a given action
that I might want when the mouse drifts over one button, but clicks on
another (for instance, I might have two different control interfaces, on
different layers, and only have one visible at a time).

Without this, we're not really using the full benefits of the more
traditional way of doing it - and we'd be better off using a pre-parser to
put in all the DOM event handlers explicitly.

3.	No parameters.

Meaning that either a 'general purpose' script has to have the parameters
itself, plus some intelligence to figure out which element we're talking
about (although admittedly finding it out isn't tricky) or have lots of
little scriplets.

Food for thought, though - cheers for pointing it out. The ability to add
properties to arbitrary objects in the DOM could prove interesting, although
there's no need to do it this way ...

James

-- 
/--------------------------------------------------------------------------\
  James Aylett, dj@insigma.com                    Insigma Technologies Ltd
  Tel: +44 (0)1285 643100                         Norcote Barn     Norcote
  Fax: +44 (0)1285 643600                         Cirencester      GL7 5RH

Received on Friday, 19 February 1999 05:01:05 UTC