Grouping descendant classes

[csdude55]

I'm guessing that this isn't possible because I can't find it anywhere, but I just wanted to make sure.

Let's say that I have a bunch of classes that are descendants of:

header > #container > #widget > #notation

Is there a correct way to group them, ala:

header > #container > #widget > #notation {
 .class1 { color: white }
 .class2 { color: blue }
 ...
 .class20 { color: black }
}

Or do I have to do them all manually, like:

header > #container > #widget > #notation .class1 { color: white }
header > #container > #widget > #notation .class2 { color: blue }
...
header > #container > #widget > #notation .class20 { color: black }

[Fotiman]

You could use a pre processor liked Sass or Less. Then you could write exactly the example you gave and it would get processed to the CSS in your second example.

[not2easy]

The problem with grouping id selectors (#) is that they must be unique. The #container selector applies only to that one element and should not be reused for additional elements. Try to be very selective in using element IDs and use classes for elements that are not unique; classes are simpler to reuse. The ' > ' applies to child elements so the element you want to re-use properties of would need to be a child of the element and would only apply to that child.

I dislike the specificity and hierarchy of css because I may understand what I'm trying to say and still be confusing in expressing it. I apologize if that's all I've done.

[lucy24]

Let's say that I have a bunch of classes that are descendants of:

header > #container > #widget > #notation

But ... but ... but ... why? The #notation by itself is already unique. How many different potential page structures have you got? (That’s assuming this is intented for a universal css, since it would obviously be wild overkill on an individual page.) “Apply this style to id=notation but only if it is a child of something with id=widget which in turn must be a child of id=container and only if the latter is a child of the header”? And then what if one of those three separate ids ends up attached to an element type that doesn't use the particular attributes you’re setting?

[csdude55]

But ... but ... but ... why? The #notation by itself is already unique.

Correct me if I'm wrong here, but I thought that this:

header > #container > #widget > #notation .class1 { color: white }

would impact all elements using class1 that falls in line like:

<header>
 <div id="container">
  <div id="widget">
   <div id="notation">
    <div class="class1">Howdy!</div>

    <p>
     <span class="class1">How are you?<span>
    </p>
   </div>
  </div>
 </div>
</header>

It's my understanding that using this format would make the CSS run a little faster because it would not look for class1 outside of the hierarchy.

I was originally planning to do this for things that are only in my header and is shared across every page; eg, a class that applies to elements in a menu that runs along the top of the page, another class for the logo, another class for the main navigation, another class for the subnavigation, etc. These classes would definitely not be used outside of the header, so there's no need for CSS to scan long pages for them.

Then, while I was playing, I realized I have a lot of classes that are only used within the section or aside, so I might be able to speed them up, too. But I don't want to modify 200 classes from .class to section .class or whatever (making the .css file that much larger) if there's an easier way to group them all together.

From my experience, every fraction of a section that I can save in page loads results in more pageviews per session, so even saving 0.1s here and there adds up to a little more money at the end of the month :-)

You could use a pre processor liked Sass or Less. Then you could write exactly the example you gave and it would get processed to the CSS in your second example.

@Fotiman, thanks for the tip! I did some research here:

[lesscss.org...]

It looks like there are some major performance issues using it on a production site, so it recommends just using it for development and then using the compiled code on the live site. So I'm thinking that the end user would still end up with the larger CSS, it would just be marginally easier to code on my end. Which is cool, but I was hoping to make the CSS smaller, too.

[lucy24]

I think it would actually make the CSS run slower, because in addition to looking for class1, it then has to backtrack and see whether the element in question is located inside this complex hierarchy. At least that's my understanding of how CSS works, so one of us is mistaken ;)

But the original question still stands: how often do you expect to find an element #notation that contains an element of class1, but which is not located inside the nest of
header > #container > #widget
? It just seems like overkill. Even when dealing with class names rather than unique ids, you should be taking another look at the CSS any time you've got more than three* chained elements:
class1 class2 class3 class4
class1 > class2 > class3 > class4
with any permutation of child/descendant.


* I originally said “three or more” but then checked my own CSS and changed it rather than fall into “do as I say, not as I do” because I do have the occasional “div.class1 div.class2 p” and the like. Couldn't find anything with four, though. But my goodness, how OCR does love reading every conceivable bracket as a } brace!

[csdude55]

I think it would actually make the CSS run slower, because in addition to looking for class1, it then has to backtrack and see whether the element in question is located inside this complex hierarchy.

Weeeeeell, I thought the logic was that it was more or less finding a way to give a general class a unique identifier, so it would be faster! LOL

I did find this, though, on CSS performance:

[csswizardry.com...]

It's from 2011, though, so I don't know if it's still relevant. But if it is then the above WOULD be "overqualifying", and instead I should have just used #notation .class1 for the best performance.

It also says that using types are the slowest method, but I'm not sure if that still applies to HTML5 types? I would assume so.. which sucks, considering I've been rebuilding everything with a bit of a focus on HTML5! :-O

But anyway, let's just assume that I'm working within a section of the site where the parent has an ID of #notation, and there are several elements with classes within that ID.

Is there an easier way to write:

#notation .class1 { color: white }
#notation .class2 { color: blue }
...
#notation .class20 { color: black }

This WOULD have been more appropriately used on the HTML5 types of "header", "main", and "footer", but the 2011 article says that targeting types is actually the slowest! So a better choice might be to change <header> to <header id="header">, and so on...

Based on the discussion, I'm thinking that the answer is "no" unless I use a preprocessor, which I think would make the page slower, not faster (which defeats the purpose for me).

[lucy24]

the 2011 article says that targeting types is actually the slowest!

Huh. Yeah, this is where we need someone with up-to-the-minute information, because seven years is quite a while in html/css years. The linked article gives examples from FF 6. Brr. But I'm fully prepared to believe that a * at the end is still inefficient.

:: looking vaguely around for Knowledgeable Person ::

We're talking about nanoseconds, aren't we? I do note “browsers read selectors right-to-left” which kinda was what I was thinking. (Hazy mental association here with the behavior of mod_rewrite, which looks at Rules before it evaluates Conditions.) I do like the conclusion:

This is why I find performance so interesting; it’s a weird balance between web standards best practices and sheer speed.

Ain't that the truth.

[Fotiman]

It looks like there are some major performance issues using it on a production site, so it recommends just using it for development and then using the compiled code on the live site. So I'm thinking that the end user would still end up with the larger CSS, it would just be marginally easier to code on my end. Which is cool, but I was hoping to make the CSS smaller, too.

Correct, you would want to tie a CSS pre processor into your build process, not have it executing at runtime. And yes, the end result is still going to be that the CSS may be less optimized for size, but shouldn't be significant from a performance perspective (especially if your server uses gzip).

Long story short, there isn't a way to shorten the way your write that selector code in the CSS itself.

[csdude55]

I'll be honest, guys, this blows my mind. I mean, I thought the whole point of CSS was for it to be cascading, but it sounds like cascading is, by design, is slower!

If it's all right-to-left, and if the browser still scans the entire page then goes back and plugs in backwards, then what's the point of even being able to set up identifiers like that?

I can't find anything recent, but as of around 2011 it looks like classes were faster to process than anything else (slightly faster than IDs, and MUCH faster than types), so unless something has changed then I need to go through everything I've built and just change everything to classes >:-(

[lucy24]

then what's the point of even being able to set up identifiers like that?

It saves trouble for you. Every item in a specified list has a particular format. Every paragraph in a specified div has a particular format--in fact, much of the time that is the sole reason for the div's existence. Every cell in a specified table has a particular format. (Remember what tables looked like in raw HTML, before CSS existed?) It's not about shaving nanoseconds in idealized benchmarks; it's about making files smaller, tidier and easier to read.