- From: Nic Ferrier <nferrier@tapsellferrier.co.uk>
- Date: Tue, 06 Feb 2001 05:32:07 +0000
- 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 UTC