Imagine you have 1000 divs on a page, and only 1 of them has a child of .my-class. Using a selector such as

div > .my-class { ...styles }

with left-to-right reading would result in the parser first finding those 1000 divs, and then checking each and every one of those divs to see if they have an immediate child of .my-class.

Right-to-left is far more efficient as the parser simply needs to find that 1 instance of .my-class, and then check whether its immediate parent is a div.

What I’ve started doing for special case margin removal is creating reusable classes like so:

.marginb-none { margin-bottom: 0;}

If you need different values of margin (which hopefully you won’t), just append a different name:

marginb-alpha { margin-bottom: 2em;}

It seems odd that it might be for efficiency when it’s the very thing that causes our CSS to render inefficiently as sites get complex and we potentially need added complexity. But then I know literally *zero* about the underlying technologies behind the rendering engines.

The reason I bring this up is because I often find myself wanting to write selectors like this:

.sidebar > *:first-child { margin-top: 0; }

In a sidebar I want the first element — whichever type it happens to be — to give up its top margin so that it sits flush inside the sidebar’s element/border/background.

But I can’t do that with a good conscience knowing that the universal selector is slow and that pseudo classes are too. Thus, I ended up with CSS like this:

.sidebar h3, .sidebar p, .sidebar ul, .sidebar ol [...] { margin-top: 0; }

It may be more efficient to render but it sucks to read and write.

So, then I start wondering if I really need those elements to have top margins in the general sense. And that just strikes me as silly — all I want is for elements in this one spot not to have a top margin and now I’m considering removing top margins from them across the entire site!

Surely there has to be a better way… Yes, I’m aware that CSS3 has or will have a selector that would help me here, but I’m more wondering why we have to put up with right-to-left selector matching when it might be nicer to use left-to-right.

Any insights? Thanks!

“I would argue specifying containers helps not only understand how the styles work, but how the application implements these styles.”

But they should work without those containers; needing the containers in your CSS is a bad thing and should be avoided.

I am afraid I really don’t think I follow your points.

Best, and apologies,
H

One thing I’d like to make a point is on the concept of deep level selector definitions in stylesheets. You made the example of using root level rule in replace of a specific four level deep selector. (`.nav{}` vs `html body .header .nav{}`)

The concern here is you cannot be modular. Take the simple example of a header and footer navigation In my opinion the class label for /both/ the header and footer container should be `nav`. If you’re trying to reuse styles, wouldn’t it be more rules and an increased level of obscurity if selectors are all of a sudden agents of ID selectors?

Another concern with your statement is code readability, I would argue specifying containers helps not only understand how the styles work, but how the application implements these styles. The lower the learning curve, the easier the handoff is (unless you’re a one man show)

I understand your point about browser efficiency (which makes a great point on mobile devices) and it makes a lot of sense to be aware of your application’s footprint but that doesn’t warrant a code style change (not saying we have to anyways!). Having augmented namespaces, improved stylesheet readability, and lightweight rule reusability can be achieved without changing the style of coding.

If your site is large enough where /this/ becomes an issue or if this is a large app on a mobile device, more likely a preprocessor that compresses and updates your styles and markup would be a very viable solution (look at Gmail as an example). `html body .header .nav{}` would become `.aA{}` and the output markup would changed. In addition to a build process for enterprise level applications, you can configure it to combine on all styles to `aA` without touching any of your code base.

Performance can be improved without compromising conceptual coding guidelines and best practices. Especially in the CSS realm. All in all, I would say `html body .header .nav{}` is less obscured than `.nav{}`, which is the primary point.

What are your thoughts?

-Matt

Like you said though, it’s all about what works for you, and if you’ve found a way of working that works for you (at least for now), go for it! :-)

t

I respect Less and Sass, but they look a bit artificial to me. At the end, they just generate plain CSS code and, for me, writting all the CSS sheets it’s not a big pain.

Maybe it’s just about preferences. I think the aproach to OOCSS explained above and CSS processors, are both elegant and professional solutions. Unlogic wild CSS is not.

See you.