Why does jQuery UI use nested CSS classes?
Why jQuery UI writes CSS like this:
.ui-dialog .ui-dialog-titlebar-close {}
.ui-dialog .ui-dialog-content {}
Since their class names are so descriptive, I would have thought it was faster and unlikely to have any collisions if they did:
.ui-dialog-titlebar-close {}
.ui-dialog-content {}
It seems to me that they are not customizing the classes and forcing the browser to do more work, but I'm wondering if there is a compelling reason for this that I am not aware of. Does anyone know why they are putting the classes the same as they are?
source to share
They make it specific.
An element with a class .ui-dialog-content
also has several other classes such as .ui-widget-content
.
<div id="dialog" class="ui-dialog-content ui-widget-content">
To make the rules .ui-dialog-content
outperform those of the other classes, they add .ui-dialog
infront.
This can be seen when checking the item. The original and boundary rules .ui-widget-content
will be overridden.
.ui-dialog .ui-dialog-content {
background: none repeat scroll 0 0 transparent;
border: 0 none;
overflow: auto;
padding: 0.5em 1em;
position: relative;
}
.ui-widget-content {
background: url("images/ui-bg_highlight-hard_100_f2f5f7_1x100.png") repeat-x scroll 50% top #F2F5F7; /* Overridden */
border: 1px solid #DDDDDD; /*Overridden*/
color: #362B36;
}
source to share
You are correct that shallow, preferred single-level selectors are preferred - at least from a performance standpoint, at least in theory. In most cases, however, rendering engine optimizations will offset the minor performance overhead.
In this case, ease of maintenance, readability and size of the stylesheet. Reduced specificity allows to process "partial" classes - if you look at the renderingovaya markup , .ui-dialog
if they have a whole bunch of other classes to be applied to it:
ui-dialog ui-widget ui-widget-content ui-corner-all ui-front ui-draggable ui-resizable
Would it be preferable to use all the properties applied in one rule? Definitely not from a developer's point of view, this approach would turn it into a maintenance nightmare. Imagine changing one presentation property and then having to override it for all "specific" rules, like in your example!
The reasons for choosing an ansector selector (for example .ui-dialog .ui-dialog-content
) are much more trivial, if not immediately obvious, to increase the specificity of those selectors. For example, the class .ui-helper-reset
will basically override any previously set style as the rule is declared at the bottom of the css file:
.ui-helper-reset {
border: 0 none;
font-size: 100%;
line-height: 1.3;
list-style: none outside none;
margin: 0;
outline: 0 none;
padding: 0;
text-decoration: none;
}
To override any of these properties, you must use a selector with a higher specificity.
Personally, I don't like this pattern - and I hope that the consistency of the code is more conducive to the rationale behind this class structure.
source to share