In JavaScript we can create element dynamically and append to
section in order to apply CSS rule for huge number of elem
There's a library called less.js which lets you manipulate css with variables in in your.css file.It's a very good library and you might want to take a look into that. http://www.lesscss.org/
Dynamically generating CSS is bad. Don't do it.
A solution that works by generating dynamic CSS can converted to a solution that doesn't require dynamic CSS.
If you need an example, see my answer here: jQuery to update actual CSS
To respond directly about the case you linked:
This seems like a very strange use-case to me. A page that has a table with 1000 rows is already a bad starting position. You can't reasonably fit 1000 rows on your screen and expect any kind of useful interaction. CSS is not the problem here. If the table were smaller the performance concerns disappear.
There are possibly other approaches than the on OP suggests. You don't need to (dynamically) add a class to each cell, you can put the class there on generation time, like:
<table class="no-filter">
...
<td class="filter1 filter2"></td>
...
</table>
Then have something like:
table.filter1 td.filter2 { display: none; }
table.filter2 td.filter1 { display: none; }
You only change the class on the table to say which filter applies.
CSS is more than just a hammer, it's a whole tool-set of very refined and very powerful tools. Make sure you use the right ones.
The advantages of having static CSS should be self-apparent:
There are also some performance concerns. I can see browser vendors optimizing AGAINST dynamic CSS. By this I mean if there is an optimization for static CSS that reduces performance of dynamic CSS you just might make this tradeoff.
Apart from some scoping issues (there might be more tables on the page...) there is nothing inherently wrong with this approach - the style
elements are there in the DOM to be edited as you see fit, the browsers are following standards by respecting it. In your test case, there's not really a valid other approach since indeed colgroup
has extremely messy support - there are 78 duplicate bugs on the subject in Bugzilla, and Mozilla has been refusing to implement it properly since the first related bug report in 1998.
The reason it's faster is simply one of overhead - once the complete DOM is assembled a relatively minor stylesheet can be applied in native C++ much faster than a Javascript interpreter can ever loop over all rows and cells. This is because historically CSS rules are applied in reverse, and the browser keeps a dictionary inside quickly allowing it to find all td
elements. Native C++ will always beat more complex interpreter-based code.
In the future, the scoping issue can also be resolved with scoped styles (currently only in FF, rather typical), you'd be coding like this:
<table>
<style id="myTableStyle" scoped>
td:nth-child(1) { display:none }
</style>
<tbody>
...
</tbody>
</table>
The scoped
attribute makes the contained styles only valid for its containing element, the table
in this case, and of course all its contained elements. And since you can access it by ID the contents are easily replaced/reconstructed.
While this would be preferable to your approach, as long as there's no universal browser support for this creating style
elements in the head
is the best workaround.