41–50 of 55 posts
While I will not argue that the mixpanel css is pretty bad (specifically the duplication making it harder to maintain and increasing the code size), but that margin example from FB is just as awful. 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…
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".
would become:
with the SASS being: .MyImportantItem { @extend .u-paddingLarge; @extend .t-important; }
You can avoid writing inline styles, keep things DRY, and still have compose-able styles.
I find that following a prefix method works quite well for organizing a lot CSS. For example (using sass): .home-header-h1{ font-size: 20pt; padding: 0px; margin: 0px; line-height: 1.3; } .home-header-h1-blue{ @extend .home-header-h1; color: blue; } .home-header-h1-green{ @extend .home-header-h1; color: green; } This helps keep classes out of your HTML and avoids large amounts of nested CSS. Here's the compiled sourc…
.home-header-h1{
font-size: 20pt;
padding: 0px;
margin: 0px;
line-height: 1.3;
}
h1.home-blue{
@extend .home-header-h1;
color: blue;
}
h1.home-green{
@extend .home-header-h1;
color: green;
}
h1.home {
font-size: 20pt;
padding: 0px;
margin: 0px;
line-height: 1.3;
&.blue {
color: blue;
}
&.green {
color: green;
}
}Deeply nested CSS selectors in the source (like the ones in your MixPanel examples) are often a sign of CSS preprocessors in use. Using a tool like LESS or Stylus, MixPanel is probably including mixins in their styles that allow them the same modular flexibility you describe without cluttering the HTML with confusing, non-semantic classes like "mrm". Edit: your site's visual design is awesome, btw
This * 1000. Just because the output isn't 100% optimal doesn't mean the input isn't sane, maintainable, or clean.
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".
If you want to update all the large margins across the app, you can do that in one place. That wouldn't be possible using inline styles.
You can also enforce style guide standards. Only three margin sizes are allowed: small, medium, large. Inline styles obviously allow for much more variability.
Now you add customization classes to these special cases instead of shoving them every-fucking-where.
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".
You're right that this example is no more semantic than inline styles, but that's the extent of the similarities. If you want to update all the large margins across the app, you can do that in one place. That wouldn't be possible using inline styles. You can also enforce style guide standards. Only three margin sizes are allowed: small, medium, large. Inline styles obviously allow for much more variability.
Sure can, your pages are generated, generate the styles from config or constants. There, I fixed it.
Earlier quoted context omitted.
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…
I see I slightly missed the root commenter's point myself. 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…
Earlier quoted context omitted.
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…
I see I slightly missed the root commenter's point myself. 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…
All I'm trying to say, is that in some cases (i.e. when you only need a particular set of styles for a single page/section), limiting the scope of those style definition can help dealing with specificity hell / bleeding styles, and make the application more maintainable.
Obviously, this is a trade-off, a big one if you want your site to be consistent across pages. But there will be occasions where one or more page of a site/app is vastly different from other pages.
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…
If performance (minimizing http requests) is not a big deal, then that'll be end of story. But if it unfortunately is a problem, current tools generally support combine/minimize them into a single file, but not dynamically choosing based on page requested.