W3C home > Mailing lists > Public > www-style@w3.org > February 2001

Behaviours: some questions and some thoughts

From: Nic Ferrier <nferrier@tapsellferrier.co.uk>
Date: Tue, 06 Feb 2001 05:32:07 +0000
Message-Id: <sa7f8dc3.062@tapsellferrier.co.uk>
To: www-style@w3c.org
I don't want to start a flame war (like in August) but I'd like to ask
some questions about the current acitivities for adding behavioural
specification to styling.

I apologise in advance for asking such basic questions.


As far as I understand it there are 2 main proposals:

- CAS
- CSS behaviours (CSS3) commonly: BECSS

Is this right? or has CAS not been accepted for review?


The difference between the 2 proposals seems to be that BECSS puts
more emphasis on using COMPONENT definitions for events and methods
whereas CAS has a fixed number of events.

Is that roughly a correct appraisal?


Some people here argue that BECSS is bad because it associates
arbritary behaviour with CSS which is traditionaly expected to define
markup and nothing else.

In what way does CAS improve on that? Except for the fact that CAS is
a completely external spec I can't see that there is much difference
between the two proposals; they both associate behaviour. Am I missing
something obvious?


Is there any current work on integration of behaviours with the
XForms work?


Now some thoughts of my own: the reason I'm asking these questions is
because I'm about to start work on a web browser and I hope to support
behaviours using the selector syntax in one form or another (I'm not
religious about which proposal I use, they both look like they could
do the job adequately).

From an implementation point of view I see behaviours as being about
a fixed number of events.  The events should relate directly to the
DOM; so there should be an event to notify an element of some change
in the DOM (according to some subscription to a notifier for the
particular element perhaps) and behavioural events about DOM
elements.

I don't see the need for HTC's particularly. It seems that it's an
extra layer of abstraction that behaviours don't need. It can't really
add extra events to the DOM layer (because the UA has to provide the
functionality for such events) without providing some means of loading
executable code: and that really would open the way for viruses.

It seems to me that a flexible definition of actions that can occur
on certain DOM elements will be provided by XForms. Till that is more
concrete I'm happy to implement a restricted number of behaviours that
apply to all elements. For example: onClick is not really relevant to
a normal block element but there might be some usefull scripts that
one can apply.

And as far as the virus issue is concerned my feeling is that the
script ought not to be able to do anything but express changes to the
DOM. Of course, that includes talking to executable content such as
ActiveX controls but the security environment for them is outside of
the scope of the scripting tool (ie: executable content should always
be run in a sandbox and if it isn't caveat emptor).



Nic Ferrier

Quickly about me:
Director of small free software firm
Principle author of GNU-Paperclips servlet engine
Member of servlet API standards team
Received on Tuesday, 6 February 2001 00:26:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:08 GMT