Simple question, and probably reflects my inexperience with CSS, but...
When creating a style sheet I like to explicitly specify the '*' wild card, so:
*.TitleText {
instead of just
.TitleText {
I find it reminds me that TitleText is applied to "any" tag, and can be overridden by a subsequent h1.TitleText. Maybe I just like this because for the longest time I didn't get that whole CSS selector concept properly and when I realized that the second (above) was just shorthand for the first, a lot of things "clicked".
Is what I do bad practice, good practice, or neither here nor there?
I don't know whether it's good or bad, but I've been doing CSS work as part of web app development for several years and I've never seen anyone use the * character.
While both are equivalent in terms of the style outcome, there are a couple other factors to keep in mind.
Using * increases the file size
If you do not use a CSS minifier (gets rid of unneeded data such as extra whitespace) that removes unneeded asterisks, using * every time a tag is not specified leads to quite a bit of extra characters in the file which will cause longer loading times (and more bandwidth usage). While I wouldn't go through a large file and remove asterisks already in place (unless you really have time to do so and love tedious tasks that could cause a bug you won't discover for years), I would suggest not including unneeded asterisks when writing new styles and removing unneeded asterisks when editing old styles.
Using * can lead to confusion
Using * when it's unneeded can lead to confusion, especially when someone new is working on the project and has not dealt with * being present when it's not needed (which is quite common).
Example
/**
* This matches an element with the class `alert` within
* any element within an `article` element
*/
article * .alert { /* ... */ }
vs
/**
* This matches an element with the class `alert` within
* an `article` element
*/
article *.alert { /* ... */ }
If there is 100% consistency in a project (and the style is known by all individuals working on the project), then the first example would never happen (it would be article * *.alert instead). However, this is an ideal situation and will more than likely fall apart after a few generations of developers (people love to use their own style instead). So, even if you have a consistent style, a new hire may come in and write in their own style for a short time, or read the current style incorrectly and produce code that doesn't match the selectors (or vice-versa). Therefore, I'd suggest sticking to the standard that I have seen the most (read: exclusively) in projects and websites:
Do not use the asterisk if it's not required.
A quick look at the source of some well known websites (e.g., Facebook, Google, Yahoo, etc) will show that they don't use asterisks unless they have to (even in their non-minified styles). You can also take a look at some open source projects on GitHub.
Conclusion
The asterisk should only be used if it is absolutely required (e.g., body * p to match paragraphs that have a parent other than body). Not only is this the unwritten standard (and less likely to cause confusion), but it also decreases the file size of style sheets, which increases the loading speed of the website.
Personally, I tend to only use the * when applying a rule to all tags. It is redundant in the case of *.class{}, but useful in the case of .class *{}.
I have read in a few places, but not verified, that the * selector can impact performance. It's not something I use unless I need to, as I generally prefer to be a bit more explicit, but that's just a personal preference.
It's neither good or bad, but it is (entirely) redundant.
EDIT: Actually, methinks it bad, 'cos it's potentially confusing (as in to humans, not parsers).
According to the CSS specification:
5.3 Universal selector
The universal selector, written "*",
matches the name of any element type.
It matches any single element in the
document tree.
If the universal selector is not the
only component of a simple selector,
the "*" may be omitted. For example:
*[lang=fr] and [lang=fr] are equivalent.
*.warning and .warning are equivalent.
*#myid and #myid are equivalent.
Therefore, .TitleText and *.TitleText are equivalent. It is highly unlikely that any implementation would have a performance consideration for *.xxx which is not there for .xxx.
This then boils down to a question of style. And since the considerations of style raised by the other answers seem to be to be largely moot, I believe I will go ahead and continue explicitly specifying the *.
I don't think it matters, but none of the examples I ever saw when I was learning used that wild card format, so I learned to do without the asterisk.
Also, none of the tools that generate CSS do it that way, so by using the asterisk, you risk an automated tool wiping out your format if you ever choose to put your CSS into such a tool.
Just for consistency with most other web developers, I'd probably recommend doing away with the asterisk so you don't have to deal with another developer asking why you've put an asterisk there.
I think the * is implicit, so they do the same thing.
I am not sure, but it might cause some problems if you do it like this:
span.style { color: red; }
*.style { color: blue; }
The * style will probably override the span style. I could be wrong though since span.style is a more specific selector.
I think it is pretty funny you do that, even though I totally get why! You're using DOS prompt/shell syntax with your CSS. In the end you might have been confusing yourself further thinking about it that way, since in a Shell you're looking at the file extension but in CSS it is actually mapping to a class.
So what I mean is, it works for class selectors, but kind of falls over for ID selectors. For example:
span#id { ... }
*#id { ... }
...and it no longer looks like Shell syntax. :) Personally I wouldn't do it the way you're doing it, because it might be confusing, but I don't think you're breaking anything.
That would be redundant, assuming * means 'every possible thing in the world' not having a * would also mean the same. I normally use *{margin:0; padding:0} in undo.css to reset the margins and paddings , but never as a pseudo selector.
I have never seen anyone use the wildcard like that, and I suspect it will be picked up in preference to just specifying the class. Other people modifying the styles maybe forced to keep using that syntax. That is if they figure why their classes are not working.
*.class will overwrite span.class even if span.class is more important.
I see no practical use for *.class, overwrites should be done with !important statement and only sparsely.
The only reason i use * is to remove all padding and margins, i actually always do this its the first css statement i write down always :).
There are also quite a few css hacks based on "* html" not working in IE6 and lower.
I'd flag it as bad practice.
In terms of the CSS specs, your two examples have identical meaning. However, there are potential issues with it in practice. The biggest, that I can see, is that some browsers may mistreat * in terms of rule weighting and so potentially throw off precedence (though I do not know of any, off the top of my head, that do this — it just wouldn't surprise me). It is also widely held, though I can't quote chapter-and-verse at you, that class selectors should always include a specific tag name for performance reasons. It is apparently faster to apply a class selector with a tag name (span.foo) than without and faster to apply an ID selector without a tag name (#bar) than with.
EDIT: This is pointing out that there could well be a performance issue. Some people seemed to think I was some sort on way out there rant...
While I don't know for certain, I'd like to give a word of warning! Consider the following identifier:
div#foo a.bar {}
I hear that jQuery for example, which utilizes css, would in the above example traverse the DOM looking for divs first, then check to see if they have an id of #foo, then for an A tag before finally seeing if it's classed .bar.
My concern with the * is that the browser may traverse the DOM looking for ALL tags and then look for .bar, rather than inherently just looking for the attribute of 'bar' - that's two sweeps of the DOM rather than just the one. Might be an extremely minimal difference, but if your syntax hits the airwaves, that's a few more solar panels we need to install.
Related
I hate them, it defies the cascading nature of CSS, and if you don't use them with care you end up in a loop of adding more !important.
But I want to know are they bad for performance?
EDIT
From the (fast) replies I can conclude it won't have a (significant) impact on performance.
But it's nice to know, even if it's just as an extra argument for discouraging others ;).
EDIT 2
BoltClock pointed out that if there are 2 !important declarations the specs says it will pick the most specific one.
It shouldn't have any discernible effects on performance. Seeing Firefox's CSS parser at /source/layout/style/nsCSSDataBlock.cpp#572 and I think that is the relevant routine, handling overwriting of CSS rules.
It just seems to be a simple check for "important".
if (aIsImportant) {
if (!HasImportantBit(aPropID))
changed = PR_TRUE;
SetImportantBit(aPropID);
} else {
// ...
}
Also, comments at source/layout/style/nsCSSDataBlock.h#219
/**
* Transfer the state for |aPropID| (which may be a shorthand)
* from |aFromBlock| to this block. The property being transferred
* is !important if |aIsImportant| is true, and should replace an
* existing !important property regardless of its own importance
* if |aOverrideImportant| is true.
*
* ...
*/
Firefox uses a top down parser written manually. In both cases each
CSS file is parsed into a StyleSheet object, each object contains CSS
rules.
Firefox then creates style context trees which contain the end values
(after applying all rules in the right order)
From: http://taligarsiel.com/Projects/howbrowserswork1.htm#CSS_parsing
Now, you can easily see, in such as case with the Object Model described above, the parser can mark the rules affected by the !important easily, without much of a subsequent cost. Performance degradation is not a good argument against !important.
However, maintainability does take a hit (as other answers mentioned), which might be your only argument against them.
I don't think that !important is inherently bad in terms of how quickly the browser matches rules (it does not form part of the selector, only part of the declaration)
However, as has already been stated, it will reduce the maintainability of your code, and thus likely cause it to grow unnecessarily in size due to future changes. The usage of !important would also likely reduce developer performance.
If you were being really picky, you could also say that !important adds 11 extra bytes to your CSS file, this isn't really much, but I guess if you have a fair few !importants in your stylesheet it could add up.
Just my thoughts, unfortunately I couldn't find any benchmarks on how !important could affect performance.
!important has its place. Trust me on that one. It's saved me many times and is often more useful as a short-term solution, before a longer and more elegant method to your problem can be found.
However, like most things, it's been abused, but there's no need to worry about 'performance'. I'll bet one small 1x1 GIF has more of a performance hit on a web page than !important would.
If you want to optimize your pages, there are many more !important routes to take ;) ;)
What's going on here behind the scenes is that as your CSS is being processed, the browser reads it, encounters an !important attribute, and the browser goes back to apply the styles defined by !important. This extra process might seem like a small additional step, but if you are serving up many requests then you will take a hit in performance. (Source)
Using !important in your CSS usually means developer narcissistic & selfish or lazy. Respect the devs to come...
The thinking of a developer when using !important:
My rocking CSS is not working... grrrr.
What should I do now??
And then !important yeah.... now it's working fine.
However its not a good approach to use !important just because we did not manage the CSS well. It creates lots of design issues -- which are worse than performance issues -- but it also forces us to use many extra lines of code since we are overriding other properties with !important and our CSS becomes cluttered with useless code. What we should do instead is first manage the CSS very well, and not let properties override one another.
We can use !important. But use it sparingly and only when there is no other way out.
I agree with you on not using it because it's bad practice, regardless of performance. On those grounds alone, I'd avoid using !important wherever possible.
But on the question of performance: No, it shouldn't be noticeable. It might have some effect, but it should be so tiny you should never notice it, nor should you worry about it.
If it is significant enough to be noticable then you've likely got bigger problems in your code than just !important. Simple use of a normal syntax element of the core languages you're using is never going to be a performance issue.
Let me answer your question with a retorical question in return; an angle that you probably didn't consider: Which browser do you mean?
Each browser obviously has its own rendering engine, with its own optimisations. So the question now becomes: what are the performance implications in each browser? Perhaps !important performs badly in one browser but really well in another? And perhaps in the next versions, it'll be the other way round?
I guess my point here is that we as web developers shouldn't think about (or need to think about) the performance implications of individual syntax constructs of the languages we're using. We should use those syntax constructs because they're the right way to achieve what we want to do not because of how they perform.
Performance questions should be asked in conjunction with the use of profilers to analyse where the pinch-points are in your system. Fix the things that are truly slowing you down first. There are almost certain to be far far bigger issues for you to fix before you get down to the level of individual CSS constructs.
It does not noticeably affect performance. It does however reduce the maintainability of your code, and therefore is likely to degrade performance in the long run.
Having had to use !important several times before, I have personally noticed no demonstrable performance hit when using it.
As a note see the answer to this stack question for a reason you might want to use !important.
Also I'll mention something that everyone else has failed to mention. !important is the only way to override inline css short of writing a javascript function (which will effect your performance if even only a little bit). So it could actually save you some performance time if you need to override inline css.
hmm... !important or !!important?
Let's go through this step by step:
The Parser has to check for !important for each property, regardless of whether you use it or not - so performance difference here is 0
When overwriting a property, the parser has to check whether the property being overwritten is !important or not - so performance difference here is 0 again
If the property being overwritten is !!important, it has to overwrite the property - performance hit of -1 for not using !important
If the property being overwritten is !important, it skips overwriting the property - performance boost of +1 for using !important
If the new property is !important, the parse has to overwrite it regardless of the property being overwritten is !important or !!important - performance difference 0 again
So I guess !important actually has better performance as it can help parser skip many properties that it won't skip otherwise.
and as #ryan mentions below, the only way to override inline css and avoid using javascript... so another way to avoid an unnecessary performance hit
hmm... turns out out that !important is important
and also,
using !important saves a lot of time for a developer
sometimes saves you from redesigning the whole css
sometimes html or the parent css file is not in your control, so it saves your life there
obviously prevents !important elements from being accidentally overwritten by other !!important elements
and sometimes browsers just don't pick the right properties, without being too specific in selectors, so using !important really becomes important and saves you from writing tonnes of specific css selectors in your css. so i guess even if you use more bytes for writing !important, it could save you bytes in other places. and we all know, css selectors can get messy.
So I guess using !important can make developers happy, and I think that's very important :D
I can't foresee !important impeding performance, not inherently anyway. If, however, your CSS is riddled with !important, that indicates that you've been over qualifying selectors and being too specific and you've run out of parents, or qualifiers to add specificity. Consequently, your CSS will have become bloated (which will impede performance) and difficult to maintain.
If you want to write efficient CSS then you want to be only as specific as you need to be and write modular CSS. It's advisable to refrain from using IDs (with hashes), chaining selectors, or qualifying selectors.
IDs prefixed with # in CSS are viciously specific, to the point where 255 classes won't override an id (fiddle by: #Faust). ID's have a deeper routed problem too though, they have to be unique, this means you can't re-use them for duplicate styles, so you end up writing linear css with repeating styles. The repercussion of doing this will vary project to project, depending on scale, but maintainability will suffer immensely and in edge cases, performance too.
How can you add specificity without !important, chaining, qualifying, or IDs (namely #)
HTML
<div class="eg1-foo">
<p class="eg1-bar">foobar</p>
</div>
<div id="eg2-foo">
<p id="eg2-bar">foobar</p>
</div>
<div class="eg3-foo">
<p class="eg3-foo">foobar</p>
</div>
CSS
.eg1-foo {
color: blue;
}
.eg1-bar {
color: red;
}
[id='eg2-foo'] {
color: blue;
}
[id='eg2-bar'] {
color: red;
}
.eg3-foo {
color: blue;
}
.eg3-foo.eg3-foo {
color: red;
}
JSFiddle
Okay, so how does that work?
The first and second examples work the same, the first is literally a class, and the second is the attribute selector. Classes and Attribute selectors have identical specificity. .eg1/2-bar doesn't inherit its color from .eg1/2-foo because it has its own rule.
The third example looks like qualifying or chaining selectors, but it's neither. Chaining is when you prefix selectors with parents, ancestors, and so on; this adds specificity. Qualifying is similar, but you define the element the selector's applying to. qualifying: ul.class and chaining: ul .class
I'm not sure what you'd call this technique, but the behavior is intentional and is documented by W3C
Repeated occurrances of the same simple selector are allowed and
do increase specificity.
What happens when the specificity between two rules is identical?
As #BoltClock pointed out, If there's multiple !important declarations then
spec dictates that the most specific one should take precedence.
In the example below, both .foo and .bar have identical specificity, so the behavior fallsback to the cascading nature of CSS, whereby the last rule declared in CSS claims precedence i.e. .foo.
HTML
<div>
<p class="foo bar">foobar</p>
</div>
CSS
.bar {
color: blue !important;
}
.foo {
color: red !important;
}
JSFiddle
I hate them, it defies the cascading nature of CSS, and if you don't use them with care you end up in a loop of adding more !important.
But I want to know are they bad for performance?
EDIT
From the (fast) replies I can conclude it won't have a (significant) impact on performance.
But it's nice to know, even if it's just as an extra argument for discouraging others ;).
EDIT 2
BoltClock pointed out that if there are 2 !important declarations the specs says it will pick the most specific one.
It shouldn't have any discernible effects on performance. Seeing Firefox's CSS parser at /source/layout/style/nsCSSDataBlock.cpp#572 and I think that is the relevant routine, handling overwriting of CSS rules.
It just seems to be a simple check for "important".
if (aIsImportant) {
if (!HasImportantBit(aPropID))
changed = PR_TRUE;
SetImportantBit(aPropID);
} else {
// ...
}
Also, comments at source/layout/style/nsCSSDataBlock.h#219
/**
* Transfer the state for |aPropID| (which may be a shorthand)
* from |aFromBlock| to this block. The property being transferred
* is !important if |aIsImportant| is true, and should replace an
* existing !important property regardless of its own importance
* if |aOverrideImportant| is true.
*
* ...
*/
Firefox uses a top down parser written manually. In both cases each
CSS file is parsed into a StyleSheet object, each object contains CSS
rules.
Firefox then creates style context trees which contain the end values
(after applying all rules in the right order)
From: http://taligarsiel.com/Projects/howbrowserswork1.htm#CSS_parsing
Now, you can easily see, in such as case with the Object Model described above, the parser can mark the rules affected by the !important easily, without much of a subsequent cost. Performance degradation is not a good argument against !important.
However, maintainability does take a hit (as other answers mentioned), which might be your only argument against them.
I don't think that !important is inherently bad in terms of how quickly the browser matches rules (it does not form part of the selector, only part of the declaration)
However, as has already been stated, it will reduce the maintainability of your code, and thus likely cause it to grow unnecessarily in size due to future changes. The usage of !important would also likely reduce developer performance.
If you were being really picky, you could also say that !important adds 11 extra bytes to your CSS file, this isn't really much, but I guess if you have a fair few !importants in your stylesheet it could add up.
Just my thoughts, unfortunately I couldn't find any benchmarks on how !important could affect performance.
!important has its place. Trust me on that one. It's saved me many times and is often more useful as a short-term solution, before a longer and more elegant method to your problem can be found.
However, like most things, it's been abused, but there's no need to worry about 'performance'. I'll bet one small 1x1 GIF has more of a performance hit on a web page than !important would.
If you want to optimize your pages, there are many more !important routes to take ;) ;)
What's going on here behind the scenes is that as your CSS is being processed, the browser reads it, encounters an !important attribute, and the browser goes back to apply the styles defined by !important. This extra process might seem like a small additional step, but if you are serving up many requests then you will take a hit in performance. (Source)
Using !important in your CSS usually means developer narcissistic & selfish or lazy. Respect the devs to come...
The thinking of a developer when using !important:
My rocking CSS is not working... grrrr.
What should I do now??
And then !important yeah.... now it's working fine.
However its not a good approach to use !important just because we did not manage the CSS well. It creates lots of design issues -- which are worse than performance issues -- but it also forces us to use many extra lines of code since we are overriding other properties with !important and our CSS becomes cluttered with useless code. What we should do instead is first manage the CSS very well, and not let properties override one another.
We can use !important. But use it sparingly and only when there is no other way out.
I agree with you on not using it because it's bad practice, regardless of performance. On those grounds alone, I'd avoid using !important wherever possible.
But on the question of performance: No, it shouldn't be noticeable. It might have some effect, but it should be so tiny you should never notice it, nor should you worry about it.
If it is significant enough to be noticable then you've likely got bigger problems in your code than just !important. Simple use of a normal syntax element of the core languages you're using is never going to be a performance issue.
Let me answer your question with a retorical question in return; an angle that you probably didn't consider: Which browser do you mean?
Each browser obviously has its own rendering engine, with its own optimisations. So the question now becomes: what are the performance implications in each browser? Perhaps !important performs badly in one browser but really well in another? And perhaps in the next versions, it'll be the other way round?
I guess my point here is that we as web developers shouldn't think about (or need to think about) the performance implications of individual syntax constructs of the languages we're using. We should use those syntax constructs because they're the right way to achieve what we want to do not because of how they perform.
Performance questions should be asked in conjunction with the use of profilers to analyse where the pinch-points are in your system. Fix the things that are truly slowing you down first. There are almost certain to be far far bigger issues for you to fix before you get down to the level of individual CSS constructs.
It does not noticeably affect performance. It does however reduce the maintainability of your code, and therefore is likely to degrade performance in the long run.
Having had to use !important several times before, I have personally noticed no demonstrable performance hit when using it.
As a note see the answer to this stack question for a reason you might want to use !important.
Also I'll mention something that everyone else has failed to mention. !important is the only way to override inline css short of writing a javascript function (which will effect your performance if even only a little bit). So it could actually save you some performance time if you need to override inline css.
hmm... !important or !!important?
Let's go through this step by step:
The Parser has to check for !important for each property, regardless of whether you use it or not - so performance difference here is 0
When overwriting a property, the parser has to check whether the property being overwritten is !important or not - so performance difference here is 0 again
If the property being overwritten is !!important, it has to overwrite the property - performance hit of -1 for not using !important
If the property being overwritten is !important, it skips overwriting the property - performance boost of +1 for using !important
If the new property is !important, the parse has to overwrite it regardless of the property being overwritten is !important or !!important - performance difference 0 again
So I guess !important actually has better performance as it can help parser skip many properties that it won't skip otherwise.
and as #ryan mentions below, the only way to override inline css and avoid using javascript... so another way to avoid an unnecessary performance hit
hmm... turns out out that !important is important
and also,
using !important saves a lot of time for a developer
sometimes saves you from redesigning the whole css
sometimes html or the parent css file is not in your control, so it saves your life there
obviously prevents !important elements from being accidentally overwritten by other !!important elements
and sometimes browsers just don't pick the right properties, without being too specific in selectors, so using !important really becomes important and saves you from writing tonnes of specific css selectors in your css. so i guess even if you use more bytes for writing !important, it could save you bytes in other places. and we all know, css selectors can get messy.
So I guess using !important can make developers happy, and I think that's very important :D
I can't foresee !important impeding performance, not inherently anyway. If, however, your CSS is riddled with !important, that indicates that you've been over qualifying selectors and being too specific and you've run out of parents, or qualifiers to add specificity. Consequently, your CSS will have become bloated (which will impede performance) and difficult to maintain.
If you want to write efficient CSS then you want to be only as specific as you need to be and write modular CSS. It's advisable to refrain from using IDs (with hashes), chaining selectors, or qualifying selectors.
IDs prefixed with # in CSS are viciously specific, to the point where 255 classes won't override an id (fiddle by: #Faust). ID's have a deeper routed problem too though, they have to be unique, this means you can't re-use them for duplicate styles, so you end up writing linear css with repeating styles. The repercussion of doing this will vary project to project, depending on scale, but maintainability will suffer immensely and in edge cases, performance too.
How can you add specificity without !important, chaining, qualifying, or IDs (namely #)
HTML
<div class="eg1-foo">
<p class="eg1-bar">foobar</p>
</div>
<div id="eg2-foo">
<p id="eg2-bar">foobar</p>
</div>
<div class="eg3-foo">
<p class="eg3-foo">foobar</p>
</div>
CSS
.eg1-foo {
color: blue;
}
.eg1-bar {
color: red;
}
[id='eg2-foo'] {
color: blue;
}
[id='eg2-bar'] {
color: red;
}
.eg3-foo {
color: blue;
}
.eg3-foo.eg3-foo {
color: red;
}
JSFiddle
Okay, so how does that work?
The first and second examples work the same, the first is literally a class, and the second is the attribute selector. Classes and Attribute selectors have identical specificity. .eg1/2-bar doesn't inherit its color from .eg1/2-foo because it has its own rule.
The third example looks like qualifying or chaining selectors, but it's neither. Chaining is when you prefix selectors with parents, ancestors, and so on; this adds specificity. Qualifying is similar, but you define the element the selector's applying to. qualifying: ul.class and chaining: ul .class
I'm not sure what you'd call this technique, but the behavior is intentional and is documented by W3C
Repeated occurrances of the same simple selector are allowed and
do increase specificity.
What happens when the specificity between two rules is identical?
As #BoltClock pointed out, If there's multiple !important declarations then
spec dictates that the most specific one should take precedence.
In the example below, both .foo and .bar have identical specificity, so the behavior fallsback to the cascading nature of CSS, whereby the last rule declared in CSS claims precedence i.e. .foo.
HTML
<div>
<p class="foo bar">foobar</p>
</div>
CSS
.bar {
color: blue !important;
}
.foo {
color: red !important;
}
JSFiddle
As I was working on a small website, I decided to use the PageSpeed extension to check if their was some improvement I could do to make the site load faster. However I was quite surprise when it told me that my use of CSS selector was "inefficient". I was always told that you should keep the usage of the class attribute in the HTML to a minimum, but if I understand correctly what PageSpeed tell me, it's much more efficient for the browser to match directly against a class name. It make sense to me, but it also mean that I need to put more CSS classes in my HTML. It make my .css file harder to read.
I usually tend to mark my CSS like this :
#mainContent p.productDescription em.priceTag { ... }
Which make it easy to read : I know this will affect the main content and that it affect something in a paragraph tag (so I wont start to put all sort of layout code in it) that describe a product and its something that need emphasis. However it seem I should rewrite it as
.priceTag { ... }
Which remove all context information about the style. And if I want to use differently formatted price tag (for example, one in a list on the sidebar and one in a paragraph), I need to use something like that
.paragraphPriceTag { ... }
.listPriceTag { ... }
Which really annoy me since I seem to duplicate the semantic of the HTML in my classes. And that mean I can't put common style in an unqualified
.priceTag { ... }
and thus I need to replicate the style in both CSS rule, making it harder to make change. (Altough for that I could use multiple class selector, but IE6 dont support them)
I believe making code harder to read for the sake of speed has never been really considered a very good practice . Except where it is critical, of course. This is why people use PHP/Ruby/C# etc. instead of C/assembly to code their site. It's easier to write and debug. So I was wondering if I should stick with few CSS classes and complex selector or if I should go the optimisation route and remove my fancy CSS selectors for the sake of speed?
Does PageSpeed make over the top recommandation? On most modern computer, will it even make a difference?
should I make my CSS easier to read or optimise the speed?
You should do both.
You should write your CSS so it is readable and if you want to collapse it, use a tool that automates that to generate the "production CSS".
So you should be working with nice readable blocks and the published file should be tiny.
In terms of the specific selectors
#mainContent p.productDescription em.priceTag { ... }
Only adds value if you have
p.productDescription em.priceTag { ... }
Or
em.priceTag { ... }
In other places that you don't want to affect - for example if you had a "#secondaryContent p.productDescription em.priceTag" that you didn't want to apply the style to.
So if you want to use
em.priceTag
And have the rule applied to all, you'll actually see no performance issue (the difference would be about the same as the file-size difference you save anyhow by having less chars in the rule).
HOWEVER... don't pollute your HTML with tons of class="" attributes just because you don't want to write a proper rule.
I personally have found that the complex selectors are more confusing long term, just be sure to give the classes appropriate names.
Long selectors are going to have a performance impact as it requires walking of the DOM each and every time to analyze the process. The way I see it there are times and places for it, but it is an exception, not the standard rule.
Define you priorities.
Readability
Efficiency
Speed
Nowadays, except on a real specific projet and complex page, you don't need to obfuscate your code to speed it up.
First think to maintainability.
By the way, using #id is a good practice both for readability and speed, since it doesn't need to walk through all the DOM to find it. Same apply for you.
After some code review I removed unnecessary properties which resulted in empty rules.
So I have know something like this:
table.foo
{
}
table.foo td.bar
{
padding: 5px;
}
Now, what would be the best course of actions about this empty table rule? Remove it or leave it? Is there a requirement to have declaration of parent elements to be able to define child elements on them? It actually works without it just fine, but maybe there are some validation considerations? Any input is appreciated.
No, you do not need the empty rule.
Each rule stands on its own (that is, the selector for the rule provides the context), so you do not need an empty rule for table.foo in order to have a rule for table.foo td.bar.
Lava Flow is bad! Lava Flow is a programming anti-pattern which essentially means that people tend to leave code they aren't sure about needing just because they don't want to break things. However, your code works without it, so get rid of it!
I take it that your somewhat new to CSS, but you're clearly not new to programming, so I thought I would point out some useful frameworks for samples, consistent style, and a quick jump over the gotchas.
YUI's CSS Resources
http://developer.yahoo.com/yui/grids/
and Blueprint CSS
http://www.blueprintcss.org/
Also, YUI theater has some a couple good intro videos.
Hope that helps.
It's 100% unnecessary from a functional point of view. And the way you have things arranged it's also completely unnecessary from a style point of view.
Alternate CSS organizational schemes (indenting hierarchically, for instance) can make it worth it. If I have an element with children I'll often leave an empty selector lying around, at least until I'm done with the project and I'm optimizing, because it helps keep things organized and there's a very good chance I'm going to at least apply style to that element at a later time.
No, you really don't need to leave this. It will only let your project's CSS bigger. Unless if you are sick for organizing, you ought to let things like that.
Check out the Dust-Me Selectors Firefox extension - it finds all unused CSS selectors in a page, or even an entire site.
Just in case someone comes to this question with the same kind of misadventure that I ran into when I did, here is one case when an empty rule will actually make sure that the following rule is not ignored. I had an extra closing brace in the rule preceding the empty rule, and the empty rule helped resynchronize the parser.
Of course, the proper fix is to fix the syntax; and remove the empty rule.
I didn't see anything on here about it with a quick search, if there is let me know.
Here is an example of a CSS selector I'd write.
div#container div#h h1 { /* styles */ }
div#container div#h ul#navi { /* styles */ }
div#container div#h ul#navi li.selected { /* styles */ }
I write all my CSS like. This allows me to stop from having styles floating around and I can technically re-use the same class name easily. For instance, I might use .selected on multiple elements across the site.
I also specify the element type (div, ul, etc) before the class/id unless the style is used for multiple elements. I also specify the element before id's even though there will only ever be one id because it allows me to know the element easily when reading my CSS. For instance I'll know right off the bat that em#example will most likely have a font-style of italic.
This isn't a question about CSS formating, it's about writing selectors.
I'd love to hear opinions on this approach, as I've used it for years and I'm reevaluating my stying.
Although it's somewhat off topic I also write my selectors like this for selector libraries (like jQuery for instance). Although I haven't looked into jQuery's internals to see if there is performance issue with specifying the element with an ID.
I think it really depends on what the selector is for.
Almost every site has one or a few style sheets that "skin" the site - fonts, text colour, link colour/hover, line spacing, and so on, and you don't want these selectors to be very specific. Similarly, if you have a component or element that's reused in many pages and always needs to look the same - like let's say the tags right here on SO - then it's going to be a pain to maintain if you use selectors based on the ID.
I would always use the ID in the selector if it refers to a specific element on a specific page. Nothing's more frustrating than trying to figure out why your rules don't seem to be working because of a conflict with some other rule, which can happen a lot if everything is classes. On the other hand, I think that nesting the IDs as you are (#container #h) is redundant, because the purpose of an ID is to be unique. If you have more than one element with the same ID on the same page then you can end up with all sorts of problems.
It does make the CSS slightly easier to understand when your selectors provide some idea of the "structure" that's being represented, but, to be honest, I think that goes against the idea of separation of concerns. The #navi might be moved outside the #h for perfectly legitimate reasons, and now somebody has to update the style sheet for #navi, even though nothing about it has changed.
A bit subjective as Darrell pointed out but that's my two cents.
While the question is a little subjective I have to say I agree with your thinking. I think defining the element before the selector is clearer when reading the code and it is less error prone.