31–40 of 55 posts
Meaning, the Mixpanel abuse of styles is an old problem.
What CSS has over most all DTP and word processing apps is that CSS is declarative and explicit and discoverable. With CSS, styling is source code, and can be managed as such.
Or not, like Mixpanel apparently has done.
What this is is basically "Object Oriented CSS" that became popular years ago and was later refuted by many in the community for it's numerous downsides, namely in maintenance cost, code-clutter and slow performance on old browsers and mobile.
With a preprocessor like SASS you can have OO and have semantic class names. Take that margin example. You could define class names that add varying types of margins. But you don't use them in HTML. You create a semantic class for specific use cases that @extend's the margin class you need.
Now you have the best of both worlds. Less, semantic class names, with the flexibility and consistency of the OO style.
Endorsed! I am also a SMACSS fan. And I say "Keep the specificity minimum" as a mechanic to write more maintainable and scalable CSS. I also have another mechanic - "Don't nest CSS", and here's my explanation for why: http://sriharisriraman.in/blog/2013/09/08/dont-nest-css/
I don't completely agree with author's opinion. I think the Facebook Way (tm) has its pros, but using page-level specificity is a great way to avoid specificity hell. To be more specific, for a site with vastly different pages, it's best to have page or section level class that limits the scope of each css definition, so the person making change to one section of the site will not accidentally break other pages. Also…
1. LESS - http://lesscss.org/
2. LESS Elements - http://lesselements.com/
3. Pure CSS - http://purecss.io/ [cool stuff, but not LESS.]When you get to the level of abstraction demonstrated in the Facebook Margins example, you have so many classes for each element that you may as well go back to inline styles. This also enables inconsistent UI in the front-end: some of my page-headers can have .mbl "Large bottom margins" and some could have .mbs "Small bottom margins".
I don't completely agree with author's opinion. I think the Facebook Way (tm) has its pros, but using page-level specificity is a great way to avoid specificity hell. To be more specific, for a site with vastly different pages, it's best to have page or section level class that limits the scope of each css definition, so the person making change to one section of the site will not accidentally break other pages. Also…
I agree this is a better way to do things, but if we want to be page-specific, why not use separate style sheets? I know we are supposed minimize the number of http requests but is having 2 external style sheets (1 for global styles and 1 for page-specific styles) really too many? It will prevent parsing every style for the entire site on every page load whether the page needs it nor not, plus decrease collisions and…
When you code CSS the "facebook way" :(, you don't have to worry about bleeding effects.
Want your h1 to have a margin of 35px or whatever? You give it the class large-margin or something. You don't have to worry about affecting other h1's, because they have the classes specific to the way they should be styled.
When you style in the way the root comment is suggesting, you do have to worry about bleeding styles, because selecting h1 tags in one section may also style an additional h1 tag you didn't mean to style.
The whole point is: don't select specific elements to style, rather, create classes of types of styles, and, when creating an element, select the classes of styles you want the elements to have. This way you don't worry about bleeding styles, each element has the classes representing how they are supposed to be styled, and you will never accidently over-select elements.
Earlier quoted context omitted.
I agree this is a better way to do things, but if we want to be page-specific, why not use separate style sheets? I know we are supposed minimize the number of http requests but is having 2 external style sheets (1 for global styles and 1 for page-specific styles) really too many? It will prevent parsing every style for the entire site on every page load whether the page needs it nor not, plus decrease collisions and…
I think you both have missed the point. When you code CSS the "facebook way" :(, you don't have to worry about bleeding effects. Want your h1 to have a margin of 35px or whatever? You give it the class large-margin or something. You don't have to worry about affecting other h1's, because they have the classes specific to the way they should be styled. When you style in the way the root comment is suggesting, you do h…
There's a trade-off of consistency across your site. I personally think it's not a good design choice to encourage different pages to have different style sheets.
Anyways if you want more specific styles, don't create specific selectors, instead create more specifically named classes so you don't lose the positive properties of the facebook way (Can we please get a better name?).
I know that there's recently been a backlash against the entire idea of the "separation of concerns" - but having your markup define your style margins is a bit insane. If suddenly you wanted 10px margins instead of 5 you have to grep your entire codebase for .m∗s (limiting the length of the string to 3 characters) and updating all those to .m∗m (or just defining both .m∗s and .m∗m to be 10px, which is just as dumb).
But, yes, most of the points in this article are somewhat accurate if not a bit outdated. Try not to use element selectors (and instead apply a class), avoid code duplication, write efficient selectors, etc.
(Note: asterisk changed to low asterisk and I hate markdown or whatever other text styling syntax HN is using).