Get Specific with Your CSS Styles

[Php_penguin]

Notice: This is a discussion thread for comments about the SitePoint article, Get Specific with Your CSS Styles.
__________

I really wish that things just happened in the order they appeared in the stylesheet, ignoring specificity..

I think you've got a comma in the wrong place. "If one declaration is from a style attribute, rather than a rule with a selector (an inline style)," should be "If one declaration is from a style attribute, rather than a rule with a selector, (an inline style)".

The way you've written it makes it look as though a rule with a selector is called an inline style, not the other way round...

Great article Paul, feel like I fully understand this concept now.

For anyone wanting some more info on CSS specificty you should also read although it misses the important part of inline styles

http://www.stuffandnonsense.co.uk/archives/css_specificity_wars.html

@Php_penguin Why do you wish that? If you have to include multiple CSS files it would be horrible having to worry about if your styles were being overwritten.

1. Why have you taken tabular data and saved it as an inaccessible image file, instead of a properly marked up table?

2. When styles of equal specificity are defined in different places (eg multiple stylesheets and css called via @import), is it still the last rule in the last referenced stylesheet that takes precedence?

[Paul O'B]

2. When styles of equal specificity are defined in different places (eg multiple stylesheets and css called via @import), is it still the last rule in the last referenced stylesheet that takes precedence?

Yes

It makes no difference where styles come from as they are inserted into the cascade order at the point they were called from (remembering that the @import rules in a style sheet must precede all rule sets anyway.).

As all styles are called into the page (by link or import) then they occupy the position in the order that they were called from.

1. Why have you taken tabular data and saved it as an inaccessible image file, instead of a properly marked up table?

You'll have to ask the editor

[timwright]

Keep in mind that @import rules require extra HTTP requests to the server. So if you're having web site performance issues, that can be a source.

That was kind of off-topic.

Good article, I'm a big fan of putting an ID and class on the body element. It keeps HTML really clean, and you can also style the html and body elements for page width, rather than using a "container" or "wrap" div... big fan.

[Stevie D]

Originally Posted by Paul O'B

It makes no difference where styles come from as they are inserted into the cascade order at the point they were called from (remembering that the @import rules in a style sheet must precede all rule sets anyway.).

As all styles are called into the page (by link or import) then they occupy the position in the order that they were called from.

What I was thinking is that you could have the situation where you had two linked stylesheets, and each of them had @import rules at the top.
So the order of preference would be that any declarations in the second sheet would be the most important, followed by any in the sheet @imported by the second stylesheet, followed by declarations in the first stylesheet, and finally anything in the sheet @imported by the first stylesheet.

[ParkinT]

Great article! I did not realize the rules had changed (slightly) with CSS2.
One point that (still) causes me confusion [when constructing markup] is the 'default' values.
In other words, remembering what is 'margin-left' and must I override it for the desired effect.

[Paul O'B]

Originally Posted by Stevie

What I was thinking is that you could have the situation where you had two linked stylesheets, and each of them had @import rules at the top.
So the order of preference would be that any declarations in the second sheet would be the most important, followed by any in the sheet @imported by the second stylesheet, followed by declarations in the first stylesheet, and finally anything in the sheet @imported by the first stylesheet.

If I'm not misunderstanding what you just said then that sounds correct

The styles get imported into the page at the position they occupy in the stylesheet so the @imported files must be at the top of the stylesheet anyway and therefore the rest of the rules (if any) will follow after.

It might be clearer for argument sake to imagine that if you see a link/import to a stylesheet then just imagine those styles linked to are already present in the document at that exact position where the link is. The styles are then resolved by the normal cascade rules just as if they had always been in that stylesheet.

Therefore the fact that the styles are are brought in from elsewhere is mainly irrelevant (unless we are talking user stylesheets with !important of course).

If you had a construct like this:

<link href="test1.css" rel="stylesheet" type="text/css" />
<style type="text/css">
@import url("test2.css");
@import url("test3.css");
p{color:red}
</style>

If each of the above styles contained only one rule to define the the p element then you can just imagine that the result is as follows had you simply embedded all the styles in the page:

<style type="text/css">
p{color:blue}/* from test1.css*/
p{color:green}/* from test2.css*/
p{color:yellow}/* from test3.css*/
p{color:red}/* last in sequence */
</style>

Hope that was what you meant

[mattymcg]

Originally Posted by Stevie D

1. Why have you taken tabular data and saved it as an inaccessible image file, instead of a properly marked up table?

Believe me, there are many things about our custom article CMS that annoy me, but the one thing that irritates me the most is its inability to handle tables. I feel dirty every time I do it. I know, I know. It is on the cards to completely revamp it, with proper unicode entity support and all sorts of other magical goodness. But until that's in place, we're stuck with it.

[Tyssen]

Originally Posted by mattymcg

It is on the cards to completely revamp it, with proper unicode entity support and all sorts of other magical goodness.

Something else that would be good would be reworking comments on articles so that they display the same as they do in the forum threads, ie, all comments showing, in correct order and with quoted passages in place.

[bohimt]

Who cares about this. Why don't people just make sure their styles don't conflict, and then the problem wouldn't exist?

[mattymcg]

Originally Posted by bohimt

Who cares about this. Why don't people just make sure their styles don't conflict, and then the problem wouldn't exist?

bohimt you've obviously never worked on a site that's very complex. Or perhaps you just asign an ID to everything and have a style sheet that's a mile long and full of redundant rules, just so that nothing conflicts, ever. Doesn't sound very workable to me.

Originally Posted by Tyssen

Something else that would be good would be reworking comments on articles so that they display the same as they do in the forum threads, ie, all comments showing, in correct order and with quoted passages in place.

Couldn't agree more Tyssen. We're very aware of it, it's just one thing on a long list.

[Stevie D]

Originally Posted by bohimt

Who cares about this. Why don't people just make sure their styles don't conflict, and then the problem wouldn't exist?

Because that either gives you a very limited repartee, or means that you have to define absolutely everything individually, which is a ridiculous amount of work.

A good example is highlighting an item in the navigation bar. If your styles are:
ul#nav li {general styles} and li#current {specific styles}, the general styles have greater specificity, so will always override the li#current. But if you have ul.nav li {general styles} and li#current {specific styles}, li#current will win out.

By understanding the specificity of different combinators and rules, you can generate far more complicated and powerful stylesheets using far less code - which saves time, saves bandwidth, and makes them a lot easier to read, edit and debug.

[NetNerd85]

At first glance I thought this would be another pointless article but no it really taught me something new. You are completely right in saying it is poorly documented, look at the W3C standards. Good article mate!

Thank you for the article,
I thought I understood specificity to a fine level but this showed me I had a few cracks in my knowledge, it's a simple yet complex area of css and I'm glad I took the time in reading it.

Thank you for this great article to think about to get a structure for css.

@stefan: Yes, this article is complex to read in two doors ;)

Ralph