开发者

css: changing the ruleset vs using selectors to switch classes/apply styles

Lately I wondered about editing elements styles not by swit开发者_开发百科ching their classes on dom, but by changing the actual ruleset for the css class or selector. So instead of something like

$('.some').hide()

or

$('.some').addClass('hidden')

Why not alter a rule directly with document.styleSheets and stuff? Wouldn't this approach be generally more performant, at least with many elements, as we'd let the browser handle the ruleset changes natively?

You could for example add an style to .some, like display: none; and all .some elements would be immedeatly be hidden. There is no need to iterate over all those elements in js and hide them manually(like the example above).

Changing rulesets directly would more likely encourage classes that are context aware(or however you would call this..), as you'd hide all #persons > .item or something.

I still don't know best practices regarding classes that are named with context in mind, like for example control names like .calendar .ticket .item, versus single functionality classes like .hidden .left .green, as I usually need both types of conventions.

I am just asking what you think about this and what are benefits and drawbacks of the modifiying stylesheet approach versus how libraries like jquery handle changing styles?

Also, what do you think is good practice, what do you regard more as a hack?

cough javascript and hacking cough


Manipulating document.styleSheets is tricky due to differing implementations and the lack of a rule selector API. Currently if you want to manipulate a rule in a stylesheet you have to go through this process:

iterate over document.styleSheets
    iterate over rules within current styleSheet object
        if rule matches our class, edit the rule styles

Then there's the cascading issue. How do you know that a particular style on the rule you've matched won't be overridden by a different rule somewhere in the pages stylesheets? If you just bail out after changing the first matching rule you find, you can't be sure that the styles you set will actually be applied to the element, unless you stick an !important on each one, which will leave you with a whole different set of problems.

Even when you've manipulated the style sheet rules, the browser still has the same job to do — it has to recalculate all the styles by applying the cascade.

So, manipulating styleSheets doesn't look too appealing now, does it? Stick to class switching, trust me. Using jQuery and modern APIs like querySelectorAll make it plenty fast and the browser still does all the hard work like recomputing the style values.


Such a tricky question :(

But if you take boilerplate for instance, it has a some standard classes to use like:

/* Hide from both screenreaders and browsers: h5bp.com/u */
.hidden { display: none !important; visibility: hidden; }

/* Hide only visually, but have it available for screenreaders: h5bp.com/v */
.visuallyhidden { border: 0; clip: rect(0 0 0 0); height: 1px; margin: -1px; overflow: hidden; padding: ; position: absolute; width: 1px; }

 /* Hide visually and from screenreaders, but maintain layout */
 .invisible { visibility: hidden; }

Where it gets tricky is, IF it is something you need to hide because of JS, then you should ONLY hide it with JS. Then it will function if JS is disabled. If it is something that is not JS dependent, then you hide it in the HTML.

So JS function = hide with JS (either by using JS or adding hide classes)

Basic HTML hide = hide with HTML class

Styleswitching vs JS switching

Basicly JS switching gives you the oppertunity to add effect etc, just using predefined classes limits that somewhat. But would love to see some ressource comparisons :)

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜