Live data from Hacker News

OOCSS + Sass = The best way to CSS

ianstormtaylor.com

41–50 of 57 posts

Re: OOCSS + Sass = The best way to CSS

#41
post #39
post #36

Earlier quoted context omitted.

If you are looking for more power, you can use mixins rather than extends. This way, you do get an additional and very signficant power boost - what previously were utility classes are now functions, which take parameters and have the ability to adapt and flex if you write them correctly.

Yup, I've been using mixins for a while now to reduce code bloat. It seems like placeholders are degenerate forms of mixins. edit After more reading, they are most definitely not degenerate forms of mixins. Placeholders FTW!

The one advantage that extends provides is less code bloat (if you use them right) in the compiled product - rather than inserting the same code, extends will add the select to the list with the previous selector. So if you were to write something like this:

.hello { color: red; }

.world { @extends .hello; background: blue }

...it would compile to something like this:

.hello, .world { color: red; }

.world { background: blue; }

na'mean?

Re: OOCSS + Sass = The best way to CSS

#42
Is this possible in LESS?

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.

Re: OOCSS + Sass = The best way to CSS

#43
post #19

Earlier quoted context omitted.

It's quite easy to create duplicate styles in the output with mixins - the compiler isn't that smart yet, do placeholders avoid all of that? I haven't seen a lot of comparisons or examples that really drive it home so far. 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.

@extend avoids duplication, but by itself it has some other bloat problems. @extend + %placeholders completely avoid duplication. Thing is @mixins aren't supposed to avoid duplication, they just inject, and should keep the declaration in the same position in the stylesheet.

Thanks for expanding on the differences

Re: OOCSS + Sass = The best way to CSS

#44
post #41
post #39

Earlier quoted context omitted.

Yup, I've been using mixins for a while now to reduce code bloat. It seems like placeholders are degenerate forms of mixins. edit After more reading, they are most definitely not degenerate forms of mixins. Placeholders FTW!

The one advantage that extends provides is less code bloat (if you use them right) in the compiled product - rather than inserting the same code, extends will add the select to the list with the previous selector. So if you were to write something like this: .hello { color: red; } .world { @extends .hello; background: blue } ...it would compile to something like this: .hello, .world { color: red; } .world { backgroun…

I'm picking up what you're putting down, but I was thinking more placeholders vs. mixins. Although I guess placeholders would avoid this code bloat too, and they can be used as selectors.

Re: OOCSS + Sass = The best way to CSS

#45
I used to be in this school. It has some downsides. I'm now back to the twitter-bootstrap-many-classes-are-fine camp.

* 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.

Re: OOCSS + Sass = The best way to CSS

#46
Have you seen Compass Recipes? http://compass-recipes.moox.fr/

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.

Re: OOCSS + Sass = The best way to CSS

#49
post #24

I haven't had the experience that HTML is harder to maintain if you use classes more liberally. What this approaches forces you to do is: write or edit CSS every time you want a new combination of existing traits...which isn't ideal either. 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…

Right, I addressed that in the post. They are "non-semantic" as far as people normally apply the word "semantic" to HTML. You might say that they are still semantic, fine. But you'd be hard pressed to argue that they are different than classes like `.dropdown` or `.menu`, and that difference makes them _much_ more susceptible to change. Which means if you're littering your markup with those classes, you will have to…

I've been working on my own framework for the last several months and I've been back and forth a bit on this issue. On the one hand I strongly believe that 1.) writing and editing markup is easier than writing CSS (browser inconstancies, context switching), and 2.) your coworkers are probably a lot more proficient with HTML than CSS. On the other, when you start getting class attributes like "col-12 secondary-panel rounded-top inner-shadow pam" you may have gone off the rails a bit. I guess it depends on where you want the mess to be. One argument that keeps me coming back to the multiple class names camp is that keeping your classes semantic and extending your patterns requires writing more Sass every time you add new content, where going nuts with class names doesn't. I love being able to add a new component to the app without having to open up a single stylesheet. We also have trouble running into the 4095 selector limit in IE8 when we package everything, so every extra class we can shave off helps (although in this specific case the problem is more with having a Sass codebase that has been rode over roughshod by five+ developers for the last year).
Post reply on HN