Which JavaScript-framework can search CSS stylesheet rules and edit their properties?

Question

The Question

Which JavaScript framework (prototype, script.aculo.us, Mootools, MochiKit...) has decent CSS rule editing support?

This is about changing a style rule. I want to have dynamic CSS classes which change. Example:

<style>
#answer, .reveal { display: none; color: blue; }
#answer { /* additional stuff */ }
</style>

Now, via JavaScript, I want to change the rule that has the “display: none” in it. – I’m convinced that sometimes this is the right way to go; I’m not looking for alternatives, when it is not the right way to do.

Which framework out there makes the following easy:

1. select a rule from all rules (e.g. “#answer, .reveal”)
2. what value does the selected rule(s) have for “display”?
3. delete the “display” property from the rule(s)

(2. and 3. are easy with DOM alone, as long as I get a handle to the CSS rule back from the framework)

The Frameworks which are not good enough:

YUI’s StyleSheet for example can only search for rules in one sheet at a time (limited, but enough for me), but it can’t show, edit or retrieve multi-selector rules like my first example (too limited for my taste).

YUI has also no way to get individual properties (the underlying DOM can, but you can’t get that structure through YUI). You could delete the “display” property alone, though, if you get hold of the rule by YUI means.

Dojo has some badly documented and incomplete stuff under dojox.html.styles

Ext JS has Ext.util.CSS. I checked the code and found a bug in getRule()... It is otherwise pretty sloppy with selector-matching (bad IE influence), which makes it bad for multi-selector rules. It also can’t delete properties through the API, but can give you the CSSRule so you can do it yourself. – The CSS tree walking is as primitive as it could be: no descending on media rules or imports.

PD:

$('.reveal').css(...whatever...) is not the answer, because it does not touch the CSS rules at all (it touches the CSS attributes of some element(s) instead)!

Answer 1

None, but please prove me wrong...

A decent implementation would have to discuss/document the following first:

• how it walks the CSS tree (including @imports and @media)
• how the walk can be configured (which @media and which sheets are considered)
• how cross domain access restrictions are handled/circumvented
• as CSS has no IDs for the rules itself: only the selector can act as a decent rule identifiers
  • as IE8 and below split up multi-selectors, how smart is the framework to handle this?
  • IE9 is worse (see quirksmode.org)
• as multiple rules could be selected by one selector, how are they ordered?
• how can the rule in charge be found from a rule-set knowing the property we want to edit?

Until the frameworks catch up, consider:

• get the style/link node where the rule you look for is in
• use the node.sheet to go to the CSSStyleSheet directly
• check quirksmode.org for quirks and f... IE
• loop over the rules to find your rule(s) via known selector
• DOM CSSStyleRule gives you all the power you need over any style rule

Answer 2

As you noted, YUI has the StyleSheet utility http://developer.yahoo.com/yui/3/stylesheet/

Example:

var sheet = new Y.StyleSheet(styleNode);
sheet.set('.hover, .foo:hover', {
    background: 'red',
    color: '#fff'
});

It also supports creating stylesheets from scratch by passing the constructor a string of css rules.

Note that the same origin policy prevents accessing the rules of remotely sourced link nodes.

It doesn't yet support accessing the rules as an object tree or accessing specific properties of rules. It does support removing rules or properties of rules, though. Today, the best you can do for working with the rules as objects would be something like

var style = sheet.getCssText('.foo'),
    tmp = document.createElement('div');

tmp.style.cssText = sheet.getCssText('.foo');
if (tmp.style.display) { // does the rule include a setting for display
    ...
}

Since messing with stylesheets at runtime is pretty rarely the right solution, the utility hasn't had a lot of developer focus for adding features. Feature requests are welcome, of course.