Live data from Hacker News

How We Could Write Better CSS

colmtuite.com

51–55 of 55 posts

Re: How We Could Write Better CSS

#51
In my opinion CSS is very object oriented and the cascading nature of it is very much like inheritance. The problem is that a lot of CSS folk don't come from a programming background, let alone an object oriented programming background so "thinking in objects" isn't something they've learned.

A good place to start doing well structured CSS is to separate the layout from the style. Doing this will give you a much better grip of your CSS and makes for easier future changes and adjustments.

Re: How We Could Write Better CSS

#52

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…

Isn't what you're describing the easy way to change a site?

Normally, sites will have more views than they have CSS objects. So if you're doing OOCSS it would be easier to just update all the objects (css files) instead of updating all the views.

Re: How We Could Write Better CSS

#53

Earlier quoted context omitted.

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…

My examples must be misleading, I'm not against creating classes. 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 a…

Selecting element types rather than creating new classes is what causes bleeding styles.

Re: How We Could Write Better CSS

#54

Earlier quoted context omitted.

My examples must be misleading, I'm not against creating classes. 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 a…

Selecting element types rather than creating new classes is what causes bleeding styles.

Until you get class-name collisions or your classes are applied to elements by other developers without you knowing. So you create more unique classes and every element ends up having 12 classes applied to it. Classes are no solution to bleeding styles.

Re: How We Could Write Better CSS

#55
The problem with the abstractions of Facebook is that you then need to always remember the "rules" of the website you're working on. If you're a Facebook software engineer adding a section to some docs somewhere, you have to thing "do we use .mbm or .mbl for our page headers? Damn, I'll check some other source".

The ideal CSS, in my opinion, is just the opposite. The developer writes Plain Old HTML and includes a stylesheet, and the new page looks instantly consistent with the rest of the website. That's how you enable anyone to work on the project. If a new UI is needed, the designers will change the css and instantly all pages will look good.

Post reply on HN