This seems like a very bad idea to me. defining css rules for classes and adding those classes to the html is a great way to make your css reusable. The way you're suggesting, with a complex selectors, sounds like a recipe for mangled stylesheets. Sure, your html is clean as a whistle, but now the css is a pain in the butt to maintain.
Consider:
.centre-box {
/* your rules */
}
Vs
body div > div:nth-of-type(3) > div {
/* your rules */
}
Then next week you you add a div above the box you want to be centred, and it's broken. To fix it, you have to find the tangly css rule that targeted your centre-box before, and change it to be something new. And all of this hassle so that your html looks cleaner?
More up front time, higher maintenance cost, no extenuating circumstance that makes it necessary. End of story.
Addendum
Why do complicated css selectors even exist?
Sometimes you want to style more than just one element. Consider this example from bootstrap, a very popular css framework. (Note: It's written in less, which compiles to css. It supports nesting, so all you need to know when reading the example is that foo { bar { /* rule */ } }
in less is foo bar { /* rule */ }
in css.)
Example: navbar source uses the >
selector (direct child selector) to style direct children of the .navbar-brand
element.
But in this case, you use a class with a meaningful name to relate the css rule to a part of the DOM, and you use the fancy selectors to style the child elements of that class.
What about doing it in JavaScript?
This seems like a non-solution for me too... to convert from using classes and ids and your old stylesheet to doing it with JavaScript, you'll keep your css the same, simplify your html, but add an entirely new JavaScript file which must either (1) use complex selectors with jQuery, so it's as much of a rat's nest as the crazy selector stylesheet option, or (2) use JavaScript without jQuery to traverse the DOM and attache elements as needed.
(1) is just as bad as putting it in css, and (2) is worse than (1) in my opinion because you'll basically have to duplicate your DOM structure in your JavaScript file (just in a different format, but same info), so you still have a DOM with ids and classes, it's just written in JavaScript. That's a lot more complexity.
So what is unobtrusive JavaScript?
I won't give a full treatment of it here because there's lots on Google if you're looking for details. But the key point as it relates to this is that unobtrusive JavaScript is that you don't want your JavaScript to intrude on your html. This relies on using ids and classes to identify which elements to attache JavaScript behaviour to. Unobtrusive JavaScript says: use ids and classes to attach events to elements instead of inlining the JavaScript events.
In a nutshell
Css classes with meaningful names are the current best way to associate a set of css rules with a portion of the html that you want to modify. This is the current convention, and the alternatives that you're suggesting add complexity and reduce maintainability.