Closed Bug 194205 Opened 22 years ago Closed 22 years ago

Please implement CSS3 behavior extensions module

Categories

(Core :: CSS Parsing and Computation, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: ernestcline, Assigned: dbaron)

References

()

Details

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:
Depends on: 194201, 194203, 194204
Summary: Please implement CSS3 behavior extenstions module → Please implement CSS3 behavior extensions module
not that i count, but i'm hoping becss dies on the vine.
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.
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.
> 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.
ernestcline, why not use XBL? /be
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.
> 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....)
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?)
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.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
*** Bug 246156 has been marked as a duplicate of this bug. ***
*** Bug 340388 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.