(I don't quite understand why you're using `innerHTML` in your example
while your library seems to be manipulating stylesheets by rules. I
assume you're talking about the latter.)
The idea is not new, I definitely saw it before. I think there are
three main reasons why this wouldn't be a good idea.
The first is argument is that you may speed up adding styles (in
modern browsers) but getting back those styles will be slower. It is
because you always have to use computed style as none of your css
information will be available on an element.
The other argument is that it may be much faster on modern browsers
(especially if you're using the `rule.style.prop` form instead of
`rule.style.cssText += ...`), but it is very slow (5x) on IE 6-7. And
they still have a "nice" ~18% market share.
The third argument is API consistency. If your library is said to be
working with a static collection of nodes, than it's an undesired
behavior to mess with stylesheets. Similarly, being live is not always
a good thing, again because `$("ul li").css({background: "#000"})` is
considered to be working on a static list of nodes. Perhaps it could
be implemented separately `$(selector).cssRule(...)` or
`$(selector).cssLive(...)`.
More tests at: http://jsperf.com/stylesheet-vs-el-style
- Balázs
_______________________________________________
JSMentors mailing list
JSMentors@jsmentors.com
http://jsmentors.com/mailman/listinfo/jsmentors_jsmentors.com
List Archive:
http://jsmentors.com/pipermail/jsmentors_jsmentors.com/
