OOCSS + Sass = The best way to CSS
ianstormtaylor.com
ianstormtaylor.com
* your css can still get large in large sites. Even though you're not duplicating rules, you're still filling your rules up with lots of comma'd selectors.
* IE8 and lower have selector limits of 4095, we hit this because we used @extend on a fairly large site and had to split our css up more
* It creates more dissonance for developers that are comfortable applying ready made classes. Now they have to make up (sometimes it really is just making it up, there's no real semantic name) a class name for something, go to the sass file and add it. This is more steps than they need.
* Many of these things can be cleaned up by good usage of partials or their equivalent on the DOM side. You should be DRYing that up too, so I can't say I relate to the author's concerns about changing DOM.
The post also suggests that certain class names are "unsemantic", when they obviously aren't. They just have different meaning to the sorts of class names the author is advocating.
Yes there are still changes to make (there always will be), but with the OOSass approach you're doing it in a single place. Want all of your statuses to be `.media` modules? One place. Not n places. Moving the work from the n-side to the 1-side is the mark of a good abstraction.
I know LESS mixins "is kind of the same thing", but the way i understand the %placholder is that it doesn't paste code into the class where you call it. It actually builds a dynamic class containing the code and then add the selectors/classes/ids (thats using the placeholder) to that class. Right? Right.
Both are elegant ways of handling the same task, but I don't think one is much more DRY than the other.
I'd argue that it's more correct to describe a class once and apply it to many elements (OOCSS) than it is to describe it many times over and apply it to each element individually (Sass @extend).
edit After more reading, they are most definitely not degenerate forms of mixins. Placeholders FTW!
.hello { color: red; }
.world { @extends .hello; background: blue }
...it would compile to something like this:
.hello, .world { color: red; }
.world { background: blue; }
na'mean?
What makes you say that the Sass approach is describing it "many times over"? It's described in one place: the %placeholder declaration. There are three steps in the process:
+ Describe the pattern. + Apply the pattern to components. + Apply the components to elements.
In OOCSS, you:
+ Describe the pattern once. + Apply the pattern n times per component. + Apply the component n times per element.
In OOSass, you:
+ Describe the pattern once. + Apply the pattern once per component. + Apply the component n times per element.
The OOSass is much DRYer because if you've decided already that all .dropdown-menu-item's are going to be `.media` patterns, you do that once. You don't have to keep repeating that decision every time you write a new dropdown.
I don't see how SASS is doing something unique here that other preprocessors can't do as well.
It's not unique, but it has been an awfully long time coming. See: https://github.com/nex3/sass/pull/236
.media() { // won't compile directly width: 100%; // other cool styling }
img { .media; }
which would output just
img { width: 100%; }
Gives me similar results I think or am I missing something?
And the point is even @extend can get bloaty when nested, but placeholder tags avoid that problem, and remove the extra pattern classes from the output.
So the article is actually advocating that you stop using mixins. Mixins aren't OOCSS, they're just copy and paste made easier.
This didn't come through entirely until I read the comment. I think an example of what mixins would produce would be helpful.
At the end of the day we have two goals: 1) keeping things easy to develop and 2) keeping the CSS filesize as small as possible.
Mixins accomplished 1 but not 2.
One potentially relevant example is bootstrap's core "btn" class, which has over 50 lines: https://github.com/twitter/bootstrap/blob/master/less/button...
When you want a button in HTML you have to add the btn class, as well as an additional class for that button's styling. IE: btn-large, btn-primary, btn-info
Bootstrap could have made this happen with just one class by implementing mixins, but that would result in each btn-primary, btn-info, etc repeating those 50 lines from the btn class.
If Bootstrap used @extend instead, that large btn class could be replaced with a multiple selector, IE: .btn-large, .btn-small, .btn-primary, etc. Then the independent styles could be defined below, as they already are, and we would just need one class to add the appropriate button style.
I guess they could do that today by just using the long selector instead of .btn, but that makes the file harder to maintain.
Let me know if I'm thinking about this wrong.
I'm actually working on a css post-processor script that optimizes css output. Grouping styles in the most efficient way possible is quite tricky.
The example also combines hr {/* style /} .separator {/ style /} into one selector hr, .separator {/ style */}
but maybe that is something a CSS minifier should be able to do?
But it also used to annoy me how much it was overlooked. Not for Sass so much, but LESS is horrible compared to either Sass or Stylus.
That being said, Stylus doesn't have the ability to extend selectors that don't appear in markup, the way @extend'ing %placeholders works in Sass. (Not that I blame TJ, the guy's awesome repo ratio is the best on github!)
The thing that gets me frustrated with both Stylus and Jade is that they go a bit too far in the minimal syntax direction at the cost of other syntax improvements (since going minimal means its harder to differentiate pieces). The Sass syntax is more than simple enough, and the option to drop semi-colons is a cool thought experiment, but not so useful in real scenarios.
And then there's momentum too. I mostly just wish that we could all get behind one pre-processor, and Sass is the one with the best momentum. (I say best, because LESS has some momentum, but it's syntax is way less thought through, and it has less active committers.) I don't blame TJ at all for this, but he definitely has less time to devote to Stylus than the multiple Sass contributors do. Mostly it's just a question of putting your chips with the player with the most momentum because that will bring you the fastest updates.
In many ways, it seems like placeholders would almost always be preferred to mixins. Though, I'm sure there are exceptions.
But that way all of the purely presentational classes are kept completely in the CSS where they belong.
I actually thought about doing it this way by just importing the bootstrap CSS and extending from the various parts, but I realised elements inside the element I'm going to extend from container won't have the container parent class and thus won't get the correct CSS applied.
Does anyone know of something that solves this?
I haven't released it to the public yet, and it's currently getting a rewrite and bump to v2, but if you'd like to check it out i can send it over.
It seems like it does exactly what you want, collect patterns in a very simple way of reusing it. The only bad thing is that they are created as mixins, but it shouldnt be that hard to just create a placeholder class including each mixin that you need.
I completely agree with what you're saying and I've wrote similar things on http://www.betterfrontend.com - perhaps you can help contribute this content there?
Semantics for the win baby.
It's a complete no-brainer, and I was a little surprised to see SASS didn't have it last year when I was looking into it. Better late than never though!