194205 - Please implement CSS3 behavior extensions module

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, enhancement)

Description

[Ernest Cline]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130

This is intended to be a meta bug for the three seperate parts of the CSS3
Behavioral Extenstions module. (Bugs 194201, 194203, and 194204) The reporter
seperated this into three seperate bugs because he felt that they were of both
different difficulties and desirability to be added to Mozilla. Also the three
parts are orthoginal. (I.e. each of the three parts can essentially be added
independently of the other two.)

Reproducible: Always

Steps to Reproduce:

Comment 1

[timeless]

not that i count, but i'm hoping becss dies on the vine.

Comment 2

[Boris Zbarsky [:bzbarsky]]

BeCSS is not anywhere close to being a Recommendation yet, and implementing it
right now would be a waste of time (it is likely to change quite substantially
before it gets anywhere close to being finalized).

Also note that BeCSS may end up being replaced by a more XBL-like XML-based
language.

Comment 3

[Ernest Cline]

Well of these three bugs, 194201 is the only one I'm really interested in as it
seems useful, and I think it's fairly easy to implement. The only downside I can
see is that it might bloat things somewhat since it would add 13 to 49 new
properties (1 per supported event.) According to the docs there are 13
properties supported by every element and 49 properties supported in all by the
Gecko API. Not all of these necessarily warrant being added, but certainly the
18 HTML intrinsic events warrant consideration IMO.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> and I think it's fairly easy to implement

It's not easy to implement.

More importantly, I repeat that doing so would be a waste of time if the spec is
going to change.  Which it is, almost certainly.

Comment 5

[Brendan Eich [:brendan]]

ernestcline, why not use XBL?

/be

Comment 6

[Ernest Cline]

Well to begin with, I wasn't aware of XBL. I came at this because of my interest
in CSS. Given that XBL is both already in use in Mozilla and closer to being a
standard (and seems to be no more complicated than the not yet standardized
HTC's needed for the behavior propoerty) I'm going to recommend that Bug 194204
be set to WONTFIX. However XBL does involve having to learn yet another tool.
For anyone already familiar with CSS and a scripting language, the other two
parts of the BECSS proposal do not involve as steep a learning curve as XBL
would seem to call for. Also I don't believe that implementation would be
difficult or impose much of  a performance penalty so I'll still advocate adding
the other two parts of that proposal.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Also I don't believe that implementation would be difficult

You _did_ read comment #4, right?  This would take some work (not like "rewrite
the style system" level of work, but it won't be particularly trivial....)

Comment 8

[Ernest Cline]

OK, let me take a look at what would be required for each onevent property.
(Note: I haven't taken a look at the code currently in place so I may be making
assumptions about how the code works that are not valid and which causes me to
assume that implementing the two parts of the BeCSS that I'm advocating is
easier than it is.)

Using onclick as the poster child for the onevent properties, let me look at
what should be required.

First, add support for another CSS property. Since the data type of the onclick
property is a string in the working draft (unless you wish to add checking that
it's a valid script, but that is not part of the specification) and it is not an
inheritable property, that part should be easy. After all, there is no new data
type, and no processing that needs to be done by the Style System itself on the
data. All the Style System has to do is present the comuputed style to the next
step.

Second, at the point where the onclick attribute of an HTML or XHTML element is
checked to see if it its there and that it contains a script, add a check to see
if the CSS property is defined when the attribute isn't. If so, use that script
instead of the one that would be used if the attribute were defined. Again, this
part should be easy, altho it may be part of another component.

At this point, unless I'm missing something, the onclick property should work as
intended. Now if one were to add support for events that do not have an
associated attribute for them such as onpopupHidden, I can see where that could
require more code per event, but I'm not advocating anything quite that
extensive, at least not for a first iteration of this. Even then, I'd recommend
adding only the events that are part of the DOM 2 Event recommendation to those
that are not already part of the set of HTML 4 intrinsic events. I will conceed
that adding the number of properties needed to support this for all desired
events might cause Mozilla to take a performance hit, depending upon how the
Style System is implemented, but that's a seperate issue from whether it can be
implemented easily.

The @script block also seems fairly untroublesome to me. Once the script has
been extracted it can be treated as if a <script> element had occurred before
either the <style> or <link> element that had the CSS. Now if it were to be
implemented so that @script blocks could be part of CSS included via the style
attribute, I can see where that might get sticky but that could be dealt with by
simply banning such practice. (Are any CSS2 @-rules supported at all for style
in the style attribute?)

Comment 9

[Hixie (not reading bugmail)]

The working group is still seriously revamping the whole BECSS thing, and is
likely to go down either the HTC or XBL route rather than the ActionSheets route.

WONTFIX. Use XBL for now. It is a technically superior solution anyway.

Comment 10

[Richard Brodie]

*** Bug 246156 has been marked as a duplicate of this bug. ***

Comment 11

[Simon Bünzli]

*** Bug 340388 has been marked as a duplicate of this bug. ***