Overclock.net › Forums › Software, Programming and Coding › Coding and Programming › Web Coding › CSS Rules of Cascading
New Posts  All Forums:Forum Nav:

CSS Rules of Cascading

post #1 of 11
Thread Starter 
I've posted this elsewhere around the web and have yet to receive an actual response, but I'd like an actual answer as it's been puzzling me these last few days.

As I continue to become more and more familiar with CSS, I find myself reading a lot about the Rules of Cascading and Specificity and order the Precedence.

Once and for all, I'd like to get a straight answer on various examples I've seen regarding duplicate selectors.

I'll type up an example below:
Code:
i {
color: green;}
i {
color: red;}

p b {
color: blue !important;}
p b {
color: violet;}

Okay, so I understand that based on how the rules of cascading work: A) The first duplicate pair of selectors, the latter of the two rules will take precedence; B) In the second pair, the first selector will applied due to the !important being added after the value of the color property (which I'm told is not something you really want to use if you don't have to).

So, my question, and where I'm trying to get a better understanding is, why would we even allow more than one of the same selector if one ends up being overridden by the other?

Is there a chance that the !important rule will be overridden by the latter rule in some cases? Or is there a chance that the former i { } rule will be applied before the latter instead? It is my assumption that if you wanted to apply something to say a

element, but not others, you'd assign it a very specific ID instead of overwriting the

element as seen in the example above.

I understand specificity will take precedence in the example below:

Code:
* {
font-family: Arial, Verdana, sans-serif;}

h1 {
font-family: "Courier New", monospace;}

So in the above example, h1 is more specific than the global selector *, so level 1 Headings will obviously be in Courier as opposed to Arial like the rest of the elements on the page (unless otherwise noted, say in a paragraph element).

However, when it comes to having duplicates of the same selectors that are overridden when following the rules of precedence in CSS seems like it's just cluttering up the code.

I've yet to find a clear answer (to me anyway), that explains it.

Thanks!
post #2 of 11
The first option. Debugging/testing. You can use the duplicate selector to overwrite the original, to test an idea, or simply try and figure out why something isn't working.

As far as I know though, there is no other good reason to use duplicate selectors just to overwrite each other (unless you are just to lazy to find the original selector, and want to make a quick change). Duplicate selectors are typically used to target a group of elements, and then individual elements, like so:
Code:
p, h1 {
    font-size: 1em;
}
p {
    color: #000;
}
h1 {
    color: #fff;
}
Using duplicate selectors to overwrite each other is typically the sign of a lazy coder, or of someone who is modifying someone elses code, and doesn't want to take the time to find where the original selector is (Again, laziness, because the Find feature makes it so simple).

There are probably other use cases that I'm not thinking of, and I may not have answered your question, but there you go.
The Monster
(9 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5 3570k Intel DZ77BH-55k Sapphire Radeon HD 7770 GHz Edition OC Corsair Vengeance 
Hard DriveCoolingOSCase
Kingston Hyper X 3k Cooler Master Hyper 212 Plus Windows 8 Pro x64 Azza Genesis 9000b 
Mouse
RAT 5 
  hide details  
Reply
The Monster
(9 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5 3570k Intel DZ77BH-55k Sapphire Radeon HD 7770 GHz Edition OC Corsair Vengeance 
Hard DriveCoolingOSCase
Kingston Hyper X 3k Cooler Master Hyper 212 Plus Windows 8 Pro x64 Azza Genesis 9000b 
Mouse
RAT 5 
  hide details  
Reply
post #3 of 11
Thread Starter 
+Rep.

That's what I was looking for; I had suspicions that it may have been a matter of overwriting temporarily to test out something else or debug something that isn't quite working. That said, I've examined other CSS files and found that the end-result still contained these duplicates! That leads me to believe your point about laziness (something I also considered) is likely 100%.

What I can surmise from your response, as well as my own experience when I've worked with my CSS from scratch, there is NO reason for there to be duplicate selectors of the same style; it's lazy, it clutters, and it may manifest issues down the road.

Now, with regarding the example you provided using multiple selectors to apply the font-size attribute, I understand that this is perfectly okay when targeting a group of elements, and not really considered a duplicate to be overwritten (unless you happen to once more specify a font-size attribute within your follow-on p { } rule). That actually raises another question if you were to do what I just mentioned in my parenthetical -- which rule would be the one applied? Is the h1, p { } rule considered more specific? Or would the lonesome p { } rule be the rule that's applied due to the fact that it appears later and is considered no more/less specific than the h1, p { } rule?

Hopefully that came out right, I just want to make sure I clearly get this.

Now, back to the example you've provided of using multiple selectors. I've seen people do this:
Code:
p {
    color: #000;
    font-size: em1;
}
h1 {
    color: #fff;
    font-size: em1;
}

Which I understand is perfectly acceptable, but often translates to potentially longer load times due to an increased number of rules to be applied. I assume some people find it easier to use this style to keep each element on its own, minimizing styling issues being applied to other elements through using multiple selectors.

But your example appears much cleaner, and still allows for those grouped elements to be modified within their own "personal" rules (that's how I see them, anyway) provided nothing clashes with the grouped selectors rule UNLESS it's meant to be overridden. But in that case, I probably wouldn't group those elements together if something they all share needed to be overridden on of them (say font-type, or color/size).
post #4 of 11
Quote:
What I can surmise from your response, as well as my own experience when I've worked with my CSS from scratch, there is NO reason for there to be duplicate selectors of the same style; it's lazy, it clutters, and it may manifest issues down the road.
Pretty much. In my opinion, duplicates like this should never be put into production code. Still, it does happen though.
Quote:
Now, with regarding the example you provided using multiple selectors to apply the font-size attribute, I understand that this is perfectly okay when targeting a group of elements, and not really considered a duplicate to be overwritten (unless you happen to once more specify a font-size attribute within your follow-on p { } rule). That actually raises another question if you were to do what I just mentioned in my parenthetical -- which rule would be the one applied? Is the h1, p { } rule considered more specific? Or would the lonesome p { } rule be the rule that's applied due to the fact that it appears later and is considered no more/less specific than the h1, p { } rule?
From my understanding, in this case, neither rule is more specific, so the one that appears last in the stylesheet is the one that takes precedence. However, again, you really shouldn't have properties set that overwrite each other. You should use the multiple selector (h1, p {}) to set general styles that both elements should share, and then get more specific with the individual selectors.
Quote:
Now, back to the example you've provided of using multiple selectors. I've seen people do this:
Code:
p {
color: #000;
font-size: em1;
}
h1 {
color: #fff;
font-size: em1;
}


Which I understand is perfectly acceptable, but often translates to potentially longer load times due to an increased number of rules to be applied. I assume some people find it easier to use this style to keep each element on its own, minimizing styling issues being applied to other elements through using multiple selectors.

But your example appears much cleaner, and still allows for those grouped elements to be modified within their own "personal" rules (that's how I see them, anyway) provided nothing clashes with the grouped selectors rule UNLESS it's meant to be overridden. But in that case, I probably wouldn't group those elements together if something they all share needed to be overridden on of them (say font-type, or color/size).
Now, for the last part. Your example accomplishes the same thing as mine, and in some cases it really has no disadvantages versus mine (in my experience). However, in your example, if you wanted to make a change, you would need to make the change for both selectors (two places). In mine, you would only need to change it in one place. For this specific scenario, its not that big of a deal, but say you had 5 selectors, that shared 4-5 styles. Then you start to see why you would want to have them all in one place.
Hopefully, this clarifies things a bit.
The Monster
(9 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5 3570k Intel DZ77BH-55k Sapphire Radeon HD 7770 GHz Edition OC Corsair Vengeance 
Hard DriveCoolingOSCase
Kingston Hyper X 3k Cooler Master Hyper 212 Plus Windows 8 Pro x64 Azza Genesis 9000b 
Mouse
RAT 5 
  hide details  
Reply
The Monster
(9 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5 3570k Intel DZ77BH-55k Sapphire Radeon HD 7770 GHz Edition OC Corsair Vengeance 
Hard DriveCoolingOSCase
Kingston Hyper X 3k Cooler Master Hyper 212 Plus Windows 8 Pro x64 Azza Genesis 9000b 
Mouse
RAT 5 
  hide details  
Reply
post #5 of 11
Thread Starter 
Excellent! So I can rest easy about that now.

In the case of the second quote about neither being more specific than the other, it's use of the latter rule would then be the "cascading" if you will of the rules and how they are applied. Makes perfect sense now! It also make sense to user multiple selectors to set general style which you KNOW will not be challenged by a later or more specific rule.

As for the last part, you are absolutely correct; if I wanted to apply a style to both of those elements, I'd now have TWO places to make those changes instead of the combined rule containing multiple selectors. Clearly using multiple selectors for general styles shared between elements is the way to go.

Thank you! thumb.gif

Armed with this knowledge, I can produce cleaner, more effective CSS.
post #6 of 11
Quote:
Originally Posted by NerdNasty View Post

(Again, laziness, because the Find feature makes it so simple)

If you are looking for an exact match to a simple selector, yes, but how often do you find stylesheets containing element name selectors only? You're more likely to find a mess of multi-selector hierarchies written by people unfamiliar with specificity rules who just keep adding selectors until the colour changes. In practice, you need to open the page in a browser that has decent debugging tools and examine the selectors that are matching the element that you want to change.
    
CPUMotherboardGraphicsRAM
i7 920 D0 MSI X58 Pro-E GTX 560 Ti 448 3x2GB G.Skill DDR3-1333 9-9-9-24 
Hard DriveHard DriveOptical DriveOS
840 Pro Caviar Black LG BD-ROM Windows 8.1 Pro x64 
MonitorMonitorKeyboardPower
Dell U2713HM Dell U2311H Turbo-Trak (Google it :D) Corsair HX-520 
CaseMouseMouse PadAudio
CM690 Mionix Avior 7000 Everglide Titan AKG K 242 HD 
  hide details  
Reply
    
CPUMotherboardGraphicsRAM
i7 920 D0 MSI X58 Pro-E GTX 560 Ti 448 3x2GB G.Skill DDR3-1333 9-9-9-24 
Hard DriveHard DriveOptical DriveOS
840 Pro Caviar Black LG BD-ROM Windows 8.1 Pro x64 
MonitorMonitorKeyboardPower
Dell U2713HM Dell U2311H Turbo-Trak (Google it :D) Corsair HX-520 
CaseMouseMouse PadAudio
CM690 Mionix Avior 7000 Everglide Titan AKG K 242 HD 
  hide details  
Reply
post #7 of 11
Thread Starter 
Quote:
Originally Posted by randomizer View Post

If you are looking for an exact match to a simple selector, yes, but how often do you find stylesheets containing element name selectors only? You're more likely to find a mess of multi-selector hierarchies written by people unfamiliar with specificity rules who just keep adding selectors until the colour changes. In practice, you need to open the page in a browser that has decent debugging tools and examine the selectors that are matching the element that you want to change.

Fortunately, I don't see myself debugging anyone else's CSS anytime soon; I plan to follow the rules the best I can for my CSS when I make it all from scratch.

I'm glad I was able to pretty much get the answer I was looking for; this puts my concerns to rest and will ensure I have clean, concise, and proper CSS.
post #8 of 11
Thread Starter 
Alright, I've got a question now concerning styling my footer navigation links.

Here's my code:
Code:
body{
        font-family: "Tahoma";
        }

a.footernav:link {
        text-decoration:none;
        font-weight:bold;
        font-size:11px;
        color:black;
        }
a.footernav:visited {
        text-decoration:none;
        color:red;
        }
a.footernav:hover {
        text-decoration:none;
        color:blue;
        }

Do I have to restate the text-decoration, size, etc., every time for each state? Or are the decoration, style, size, and weight styles inherited from the initial a.footernav:link { } rule? I understand I can modify those values in the following states, but the only thing I actually want to change is the color appropriate to each state of selection.

In the past, I've done this:
Code:
a.footernav:link
{
    font-family: "Tahoma";
    font-size: 11px;
    color: #ffffff;
    font-weight: bold;
}
a.footernav:visited {
    font-family: "Tahoma";
    font-size: 11px;
    color: #ffffff;
    font-weight: bold;
}
a.footernav:Hover 
{
        font-family: "Tahoma";
        font-size: 11px;
        color: #00F;
        font-weight: bold;
}

But that seems redundant.

Also, are the quotes when specifying font-family required? I've only seen it in use for "Courier New", but never anything else. But it's a habit I've had and I don't know it's something I should continue doing or stop.
Edited by VaiFanatic - 1/27/15 at 10:43am
post #9 of 11
Thread Starter 
So, I've determined that if I want nothing else but the colors to change or remain the same, I do NOT have to declare anything else beyond what was already declared in the initial a.footernav:link { }

I tested this in my header code:
Code:
/* Header CSS */

a.headernav:link {
        text-decoration:none;
        font-weight:bold;
        color:white;
}
a.headernav:visited {
        color:white;
}
a.headernav:hover {
        color:#495E00;
}
post #10 of 11
Yes, you only need to declare a new style if you want it to change. You don't need to re-iterate it. Also, as far as putting quotes when specifying font-family, if I'm not mistaken, it is only required when the font you are using has a space in the name..
The Monster
(9 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5 3570k Intel DZ77BH-55k Sapphire Radeon HD 7770 GHz Edition OC Corsair Vengeance 
Hard DriveCoolingOSCase
Kingston Hyper X 3k Cooler Master Hyper 212 Plus Windows 8 Pro x64 Azza Genesis 9000b 
Mouse
RAT 5 
  hide details  
Reply
The Monster
(9 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5 3570k Intel DZ77BH-55k Sapphire Radeon HD 7770 GHz Edition OC Corsair Vengeance 
Hard DriveCoolingOSCase
Kingston Hyper X 3k Cooler Master Hyper 212 Plus Windows 8 Pro x64 Azza Genesis 9000b 
Mouse
RAT 5 
  hide details  
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Web Coding
Overclock.net › Forums › Software, Programming and Coding › Coding and Programming › Web Coding › CSS Rules of Cascading