Cargo Cult CSS(kapowaz.net)
kapowaz.net
Cargo Cult CSS
http://www.kapowaz.net/articles/cargo-cult-css
10 comments
I'm starting to see a pattern here about "presentational CSS class names": considering the superficial presentation layer and not the underlying meaning that links consistent design elements. There's a language to design, and it's a hell of a lot more than "this button should be green".
"They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds."
There's a whole series of unasked questions going on there:
* Why is the button blue - what led to that conclusion?
* Why is green the right colour?
* What about the other buttons, are they all the right colour? If so, why. If not, why?
* Why does the style guide for the site not specify this properly? (You have a style guide, right? Your CTO and designer did present you with an up-to-date, style guide, right?)
Asking these questions leads you to the semantic understanding of why buttons are supposed to exhibit specific characteristics. It's the WHY that's important, not the WHAT.
CSS excels when there's a requirement for consistency in design, and there's a style guide. When your requirements are a superficial "this button must be green" and you don't stop to ask why, then you've already sacrificed the semantic aspects of the documents you are supposed to be vocal about.
Also, how difficult is it to find what stylerule is causing the button to be blue. Right click on the button, click "Inspect this element in Firebug", in the CSS Inspector find the CSS rule that specifies the colour as blue. Look at the CSS selector itself - does it describe the semantic reason why the presentation is coloured blue? With that understanding of the semantic basis of the button being blue, you have an answer WHY the button is blue.
So now you need to understand why the button is supposed to be green. Get that explained to you, and now you have a good idea of the semantics you need to express, or reuse, a CSS rule that will cause the button to be rendered in Green.
This is where semantic class names win hands down, it tells you the WHY of styles. Without the WHY you don't have a basis for explaining why the button is blue, and no clear inkling of why now it should be green. And absolutely no idea which other buttons on the site are the wrong colour.
And that's about as far away as you can be from a consistent style guide, and presentational accuracy. If everything is ad-hoc, then nothing is consistent.
"They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds."
There's a whole series of unasked questions going on there:
* Why is the button blue - what led to that conclusion?
* Why is green the right colour?
* What about the other buttons, are they all the right colour? If so, why. If not, why?
* Why does the style guide for the site not specify this properly? (You have a style guide, right? Your CTO and designer did present you with an up-to-date, style guide, right?)
Asking these questions leads you to the semantic understanding of why buttons are supposed to exhibit specific characteristics. It's the WHY that's important, not the WHAT.
CSS excels when there's a requirement for consistency in design, and there's a style guide. When your requirements are a superficial "this button must be green" and you don't stop to ask why, then you've already sacrificed the semantic aspects of the documents you are supposed to be vocal about.
Also, how difficult is it to find what stylerule is causing the button to be blue. Right click on the button, click "Inspect this element in Firebug", in the CSS Inspector find the CSS rule that specifies the colour as blue. Look at the CSS selector itself - does it describe the semantic reason why the presentation is coloured blue? With that understanding of the semantic basis of the button being blue, you have an answer WHY the button is blue.
So now you need to understand why the button is supposed to be green. Get that explained to you, and now you have a good idea of the semantics you need to express, or reuse, a CSS rule that will cause the button to be rendered in Green.
This is where semantic class names win hands down, it tells you the WHY of styles. Without the WHY you don't have a basis for explaining why the button is blue, and no clear inkling of why now it should be green. And absolutely no idea which other buttons on the site are the wrong colour.
And that's about as far away as you can be from a consistent style guide, and presentational accuracy. If everything is ad-hoc, then nothing is consistent.
> I would have preferred you used the 90% of your words to give better examples of how to do things better than overstating how OOCSS and BEM are wrong
This is definitely something I'd like to do as well, but I wanted to focus on the areas I found problematic first and foremost. I may post a follow-up based on the feedback I've received.
> Why not have the presentation be the specification, and we can just build the html to conform to the that specification instead
As I said, I don't believe this is an appropriate approach for a medium which has no absolute, definitive interpretation. A website isn't how it looks, because how it looks will differ depending on how you access it. The only absolute truth when talking about websites is the semantic purpose of the markup underlying it, because purpose is universal: a navigation element is a navigation element regardless of whether it's being displayed on a TV, a desktop browser, a smartphone, or being read out by a screen reader.
> I imagine that's just because you'd rather see better looking html than you would see better looking css.
I'm actually interested in both :)
> You have the semantic issues well thought out, however you are flat out declaring data semantics are more important than presentation semantics.
What are ‘presentation semantics’? I think this is a corruption of the concept of semantics. Semantics are what a thing is, or means, or does; not how it is presented
> My CTO and designer (2 people I have a lot of respect for) were the people who eventually changed my mind on this. They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds.
Changing how you structure the CSS in your application based on the whims of people whose area of expertise isn't CSS sounds like a nightmare scenario to me. If you're bootstrapping with a small team I can understand wanting to have everyone being able to contribute, but you should also be able to recognise what the limitations of their skills are. In the example you give, I would be using my web developer tools / inspector etc. to find out the origin of the erroneous property. If you're using a preprocessor there are source maps that can help with identifying how a rule was built. I certainly wouldn't conclude it's easier to use a presentational class name just so that my CTO could understand the code.
This is definitely something I'd like to do as well, but I wanted to focus on the areas I found problematic first and foremost. I may post a follow-up based on the feedback I've received.
> Why not have the presentation be the specification, and we can just build the html to conform to the that specification instead
As I said, I don't believe this is an appropriate approach for a medium which has no absolute, definitive interpretation. A website isn't how it looks, because how it looks will differ depending on how you access it. The only absolute truth when talking about websites is the semantic purpose of the markup underlying it, because purpose is universal: a navigation element is a navigation element regardless of whether it's being displayed on a TV, a desktop browser, a smartphone, or being read out by a screen reader.
> I imagine that's just because you'd rather see better looking html than you would see better looking css.
I'm actually interested in both :)
> You have the semantic issues well thought out, however you are flat out declaring data semantics are more important than presentation semantics.
What are ‘presentation semantics’? I think this is a corruption of the concept of semantics. Semantics are what a thing is, or means, or does; not how it is presented
> My CTO and designer (2 people I have a lot of respect for) were the people who eventually changed my mind on this. They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds.
Changing how you structure the CSS in your application based on the whims of people whose area of expertise isn't CSS sounds like a nightmare scenario to me. If you're bootstrapping with a small team I can understand wanting to have everyone being able to contribute, but you should also be able to recognise what the limitations of their skills are. In the example you give, I would be using my web developer tools / inspector etc. to find out the origin of the erroneous property. If you're using a preprocessor there are source maps that can help with identifying how a rule was built. I certainly wouldn't conclude it's easier to use a presentational class name just so that my CTO could understand the code.
> What are ‘presentation semantics’? I think this is a corruption of the concept of semantics. Semantics are what a thing is, or means, or does; not how it is presented
Semantics just means to give something meaning. Presentation semantics (http://en.wikipedia.org/wiki/Presentation_semantics) are just marking up the data to declare your intent for how you would like it to be presented.
> As I said, I don't believe this is an appropriate approach for a medium which has no absolute, definitive interpretation. A website isn't how it looks, because how it looks will differ depending on how you access it. The only absolute truth when talking about websites is the semantic purpose of the markup underlying it, because purpose is universal: a navigation element is a navigation element regardless of whether it's being displayed on a TV, a desktop browser, a smartphone, or being read out by a screen reader.
A HTML document is just text. Technically adding links, particularly navigation, is just presentation markup. As you said, it's up to the interpreter to make sense of that markup. The basis of your argument is that presentational markup is bad though, so I'm left unconvinced here.
> Changing how you structure the CSS in your application based on the whims of people whose area of expertise isn't CSS sounds like a nightmare scenario to me. If you're bootstrapping with a small team I can understand wanting to have everyone being able to contribute, but you should also be able to recognise what the limitations of their skills are. In the example you give, I would be using my web developer tools / inspector etc. to find out the origin of the erroneous property. If you're using a preprocessor there are source maps that can help with identifying how a rule was built. I certainly wouldn't conclude it's easier to use a presentational class name just so that my CTO could understand the code.
I'm concluding that presentational class names are easier to fix for the regular small changes that come down the pipe in our project. Even if you're regularly making big presentational changes to your entire site, then you'd need something a little more abstract, like using a class to declare an element as a button instead of the direct color it should be, but like I'm said, the argument against presentation markup is still unconvincing in the face of simple maintenance.
Semantics just means to give something meaning. Presentation semantics (http://en.wikipedia.org/wiki/Presentation_semantics) are just marking up the data to declare your intent for how you would like it to be presented.
> As I said, I don't believe this is an appropriate approach for a medium which has no absolute, definitive interpretation. A website isn't how it looks, because how it looks will differ depending on how you access it. The only absolute truth when talking about websites is the semantic purpose of the markup underlying it, because purpose is universal: a navigation element is a navigation element regardless of whether it's being displayed on a TV, a desktop browser, a smartphone, or being read out by a screen reader.
A HTML document is just text. Technically adding links, particularly navigation, is just presentation markup. As you said, it's up to the interpreter to make sense of that markup. The basis of your argument is that presentational markup is bad though, so I'm left unconvinced here.
> Changing how you structure the CSS in your application based on the whims of people whose area of expertise isn't CSS sounds like a nightmare scenario to me. If you're bootstrapping with a small team I can understand wanting to have everyone being able to contribute, but you should also be able to recognise what the limitations of their skills are. In the example you give, I would be using my web developer tools / inspector etc. to find out the origin of the erroneous property. If you're using a preprocessor there are source maps that can help with identifying how a rule was built. I certainly wouldn't conclude it's easier to use a presentational class name just so that my CTO could understand the code.
I'm concluding that presentational class names are easier to fix for the regular small changes that come down the pipe in our project. Even if you're regularly making big presentational changes to your entire site, then you'd need something a little more abstract, like using a class to declare an element as a button instead of the direct color it should be, but like I'm said, the argument against presentation markup is still unconvincing in the face of simple maintenance.
"A HTML document is just text. Technically adding links, particularly navigation, is just presentation markup."
HTML is HyperText markup language. Hypertext is about links and references to other documents. Links are a first class citizen of a hypertext document. That's about function, not presentation.
HTML is HyperText markup language. Hypertext is about links and references to other documents. Links are a first class citizen of a hypertext document. That's about function, not presentation.
This is an argument I had with myself a few years ago, when OOCSS started becoming popular. Ultimately, what I determined is that there's a new definition of what "semantic" means in front-end architecture. Semantic doesn't just describe the content anymore, it describes the function as well. So using classes like "module-box" or whatever is perfectly fine. There's a bunch of articles out there on the new semantics, you can look them up as I can't be bothered to link to them.
Ultimately, though, the "separation of concerns" was a good principle to use when the web was a bunch of documents meant to provide content. It isn't that way anymore. The web has evolved in use to include web apps and other forms of media, so our principles must evolve as well. It seems silly to cling to past definitions as immutable when we work in a field that changes drastically nearly every year.
Also, anyone who advocates using a selector like "ul.members li a" and then complains about the maintainability issues of using non-semantic classes when an update needs to be made should really reconsider their hypocrisy. Using selectors like that (aside from being slow performing) completely tie the markup to the presentation. Hell, if all you did was update the list to an ordered list instead of an unordered one you'd have to update the CSS as well.
The reality is that any change in the UI big enough to warrant updating the markup is going to warrant updating the CSS, and vice versa. Worrying about making them completely separate is impractical and will just cause you to waste time in development.
If you're concerned about the discoverability of the code to a new developer, DOCUMENT IT. Do not create crappy selectors. Create a UI style guide that implements all of the major UI components and have the developer reference the style guide. Use something like KSS to link between the style guide and the CSS. There's no excuse for using bad selectors in the name of ease of on-boarding.
Ultimately, though, the "separation of concerns" was a good principle to use when the web was a bunch of documents meant to provide content. It isn't that way anymore. The web has evolved in use to include web apps and other forms of media, so our principles must evolve as well. It seems silly to cling to past definitions as immutable when we work in a field that changes drastically nearly every year.
Also, anyone who advocates using a selector like "ul.members li a" and then complains about the maintainability issues of using non-semantic classes when an update needs to be made should really reconsider their hypocrisy. Using selectors like that (aside from being slow performing) completely tie the markup to the presentation. Hell, if all you did was update the list to an ordered list instead of an unordered one you'd have to update the CSS as well.
The reality is that any change in the UI big enough to warrant updating the markup is going to warrant updating the CSS, and vice versa. Worrying about making them completely separate is impractical and will just cause you to waste time in development.
If you're concerned about the discoverability of the code to a new developer, DOCUMENT IT. Do not create crappy selectors. Create a UI style guide that implements all of the major UI components and have the developer reference the style guide. Use something like KSS to link between the style guide and the CSS. There's no excuse for using bad selectors in the name of ease of on-boarding.
"Ultimately, though, the "separation of concerns" was a good principle to use when the web was a bunch of documents meant to provide content. It isn't that way anymore. The web has evolved in use to include web apps and other forms of media, so our principles must evolve as well."
The "webapps are not documents" position is hokum. Web apps are merely the application of HTML, CSS and JavaScript to create more functional/dynamic documents. But documents they still are.
"Also, anyone who advocates using a selector like "ul.members li a" and then complains about the maintainability issues of using non-semantic classes when an update needs to be made should really reconsider their hypocrisy."
That's a nice strawman you've propped up there.
"If you're concerned about the discoverability of the code to a new developer, DOCUMENT IT. Do not create crappy selectors. Create a UI style guide that implements all of the major UI components and have the developer reference the style guide."
Amen.
The "webapps are not documents" position is hokum. Web apps are merely the application of HTML, CSS and JavaScript to create more functional/dynamic documents. But documents they still are.
"Also, anyone who advocates using a selector like "ul.members li a" and then complains about the maintainability issues of using non-semantic classes when an update needs to be made should really reconsider their hypocrisy."
That's a nice strawman you've propped up there.
"If you're concerned about the discoverability of the code to a new developer, DOCUMENT IT. Do not create crappy selectors. Create a UI style guide that implements all of the major UI components and have the developer reference the style guide."
Amen.
> That's a nice strawman you've propped up there.
In his defence, that's not a "strawman he's propped up", it's taken from the article.
In his defence, that's not a "strawman he's propped up", it's taken from the article.
> what I determined is that there's a new definition of what "semantic" means in front-end architecture. Semantic doesn't just describe the content anymore, it describes the function as well. So using classes like "module-box" or whatever is perfectly fine.
Semantics describes a thing, but classes like ‘module-box’ don't convey any meaning beyond presentation. If you think that ‘module-box’ is semantic, then I have a whole bunch of classnames based on colours to sell you…
> the "separation of concerns" was a good principle to use when the web was a bunch of documents meant to provide content. It isn't that way anymore.
The virtues of this approach have very little to do with the web; it's a concept that pre-dates it, so it's hard to justify it having been invalidated simply by advances in web technology. Besides, a web ‘application’ is equally composed of semantic components just as much as a document is; part of the reason HTML5 came about was to reflect the kind of elements used in modern web pages.
> Using selectors like that (aside from being slow performing) completely tie the markup to the presentation. Hell, if all you did was update the list to an ordered list instead of an unordered one you'd have to update the CSS as well.
This suggests that your workflow starts with CSS and you then build markup to fit it, which his sounds completely backwards to how I approach things. You don't tie your markup to how it is presented: you declare how you want to present the markup your app is built upon. Also, if you change the markup to something with a completely different meaning (an ordered list is meant to have a different purpose than an unordered one) then of course it follows that you'd have to update the CSS, although there's no reason why those changes need be onerous or difficult.
The whole selector performance debate is old and dead, by the way: http://calendar.perfplanet.com/2011/css-selector-performance....
> If you're concerned about the discoverability of the code to a new developer, DOCUMENT IT. Create a UI style guide that implements all of the major UI components and have the developer reference the style guide.
A style guide is a fine starting point regardless of how you want to approach your CSS, but documentation isn't the only way to aid discoverability of code. Selectors that communicate context and purpose can be very helpful for this too.
Semantics describes a thing, but classes like ‘module-box’ don't convey any meaning beyond presentation. If you think that ‘module-box’ is semantic, then I have a whole bunch of classnames based on colours to sell you…
> the "separation of concerns" was a good principle to use when the web was a bunch of documents meant to provide content. It isn't that way anymore.
The virtues of this approach have very little to do with the web; it's a concept that pre-dates it, so it's hard to justify it having been invalidated simply by advances in web technology. Besides, a web ‘application’ is equally composed of semantic components just as much as a document is; part of the reason HTML5 came about was to reflect the kind of elements used in modern web pages.
> Using selectors like that (aside from being slow performing) completely tie the markup to the presentation. Hell, if all you did was update the list to an ordered list instead of an unordered one you'd have to update the CSS as well.
This suggests that your workflow starts with CSS and you then build markup to fit it, which his sounds completely backwards to how I approach things. You don't tie your markup to how it is presented: you declare how you want to present the markup your app is built upon. Also, if you change the markup to something with a completely different meaning (an ordered list is meant to have a different purpose than an unordered one) then of course it follows that you'd have to update the CSS, although there's no reason why those changes need be onerous or difficult.
The whole selector performance debate is old and dead, by the way: http://calendar.perfplanet.com/2011/css-selector-performance....
> If you're concerned about the discoverability of the code to a new developer, DOCUMENT IT. Create a UI style guide that implements all of the major UI components and have the developer reference the style guide.
A style guide is a fine starting point regardless of how you want to approach your CSS, but documentation isn't the only way to aid discoverability of code. Selectors that communicate context and purpose can be very helpful for this too.
> Some CSS framework methodologists suggest that using IDs is a bad idea. The reasoning behind this is that IDs carry such a higher specificity [...]
No, the primary reason is that IDs prevent reuse.
If you want to build a library of reusable components, IDs are obviously not what you want.
As the person who writes these components, you do not care how often one of these components is used. From your point of view, it only matters if it's used at least once. If it isn't, you can throw it away.
Secondly, if you use IDs which were added for JavaScript or fragment links, you'll introduce some coupling which really shouldn't be there.
Same thing with JavaScript. If you need a class, you should add a prefixed one (e.g. "js-foo"). Obviously, classes like that should never appear in your stylesheet.
Nothing of this has anything to do with cargo cults. There is an actual reason behind every rule.
No, the primary reason is that IDs prevent reuse.
If you want to build a library of reusable components, IDs are obviously not what you want.
As the person who writes these components, you do not care how often one of these components is used. From your point of view, it only matters if it's used at least once. If it isn't, you can throw it away.
Secondly, if you use IDs which were added for JavaScript or fragment links, you'll introduce some coupling which really shouldn't be there.
Same thing with JavaScript. If you need a class, you should add a prefixed one (e.g. "js-foo"). Obviously, classes like that should never appear in your stylesheet.
Nothing of this has anything to do with cargo cults. There is an actual reason behind every rule.
"No, the primary reason is that IDs prevent reuse."
The fact that they cannot be reused in a single page is what makes IDs so useful.
There are benefits of IDs others mentioned, but for me properly used IDs make CSS so much clearer. An ID in CSS code is a flag saying: "custom-crafted for this part of the page only, not to be reused", or "non-modular code".
Unlike a class, an ID informs me with 100% certainty that if modified, it will not affect other instances on the page, because there are none. It's hard to overestimate the value of such information, especially when working on older or someone else's code.
The fact that they cannot be reused in a single page is what makes IDs so useful.
There are benefits of IDs others mentioned, but for me properly used IDs make CSS so much clearer. An ID in CSS code is a flag saying: "custom-crafted for this part of the page only, not to be reused", or "non-modular code".
Unlike a class, an ID informs me with 100% certainty that if modified, it will not affect other instances on the page, because there are none. It's hard to overestimate the value of such information, especially when working on older or someone else's code.
>The fact that [IDs] cannot be reused in a single page is what makes IDs so useful.
This isn't enforced by browsers. They will happily render all elements with the same ID and apply the same styles to all of them.
This kind of thing really isn't useful. If you accidentally put the logo twice on the page, it will be clearly visible. It virtually never happens and when it does it isn't hard to track down.
This "just once" property of IDs really doesn't add anything useful.
>Unlike a class, an ID informs me with 100% certainty that if modified, it will not affect other instances on the page, because there are none.
If I modify one of my building blocks, I know that every instance of it will now look like this.
Consistency is awesome.
This isn't enforced by browsers. They will happily render all elements with the same ID and apply the same styles to all of them.
This kind of thing really isn't useful. If you accidentally put the logo twice on the page, it will be clearly visible. It virtually never happens and when it does it isn't hard to track down.
This "just once" property of IDs really doesn't add anything useful.
>Unlike a class, an ID informs me with 100% certainty that if modified, it will not affect other instances on the page, because there are none.
If I modify one of my building blocks, I know that every instance of it will now look like this.
Consistency is awesome.
>This isn't enforced by browsers. They will happily render all elements with the same ID and apply the same styles to all of them.
We live in post-xhtml times, browsers will try to make sense and render all sorts of bad code.
>If you accidentally put the logo twice on the page, it will be clearly visible. It virtually never happens and when it does it isn't hard to track down.
You're assuming the visual difference in applied style is always clearly visible, like a repeated logo. No, it's often not, not until someone changes something in a class and the change is populated everywhere the class was reused. An ID is a guarantee it was not reused, or at the very least serves as a "do not reuse" sign.
Edit: formatting
We live in post-xhtml times, browsers will try to make sense and render all sorts of bad code.
>If you accidentally put the logo twice on the page, it will be clearly visible. It virtually never happens and when it does it isn't hard to track down.
You're assuming the visual difference in applied style is always clearly visible, like a repeated logo. No, it's often not, not until someone changes something in a class and the change is populated everywhere the class was reused. An ID is a guarantee it was not reused, or at the very least serves as a "do not reuse" sign.
Edit: formatting
Right, so what's the problem if it looks fine?
The only problem is that you used an ID.
>"do not reuse"
Why not? If someone wants to reuse something, they probably have a good reason. Why would you get in their way? You won't gain anything from doing that.
The only problem is that you used an ID.
>"do not reuse"
Why not? If someone wants to reuse something, they probably have a good reason. Why would you get in their way? You won't gain anything from doing that.
> If I modify one of my building blocks, I know that every instance of it will now look like this.
But that's based on your own system, which may be non-obvious to other developers. The rules of valid HTML dictate the situation in which you will encounter a given ID, so this communicates something to every developer who sees IDs used in a given selector. To me that's tremendously valuable, and far more useful than trying to graft additional meanings onto parts of a single classname.
Whether that system is BEM, OOCSS, SMACSS or some other syntax, this kind of naming convention isn't a native part of CSS.
But that's based on your own system, which may be non-obvious to other developers. The rules of valid HTML dictate the situation in which you will encounter a given ID, so this communicates something to every developer who sees IDs used in a given selector. To me that's tremendously valuable, and far more useful than trying to graft additional meanings onto parts of a single classname.
Whether that system is BEM, OOCSS, SMACSS or some other syntax, this kind of naming convention isn't a native part of CSS.
> But that's based on your own system, which may be non-obvious to other developers.
Yes, conventions are like that. You have to read the docs.
> [...] this kind of naming convention isn't a native part of CSS.
That's true for naming conventions in general.
Well, this stuff was added for a reason. If you know the rules, the SCSS and markup becomes way easier to navigate. Additionally, there are now many properties which can be automatically verified.
It adds structure which wouldn't be there otherwise.
Yes, conventions are like that. You have to read the docs.
> [...] this kind of naming convention isn't a native part of CSS.
That's true for naming conventions in general.
Well, this stuff was added for a reason. If you know the rules, the SCSS and markup becomes way easier to navigate. Additionally, there are now many properties which can be automatically verified.
It adds structure which wouldn't be there otherwise.
> No, the primary reason is that IDs prevent reuse.
Reuse of what, exactly? Selectors? Properties? My assertion is that if you need to re-use properties a lot then you should make use of a preprocessor framework and then use a combination of mixins or extends. Re-use of selectors is an unnecessary artefact of how OOCSS (and similar) suggest you should write your code.
> If you want to build a library of reusable components, IDs are obviously not what you want.
If you're building components that could end up on any page entirely outside of your control, I agree. But: horses for courses. It still has valid uses, and avoiding it entirely isn't necessary.
> Secondly, if you use IDs which were added for JavaScript or fragment links, you'll introduce some coupling which really shouldn't be there.
You're looking at this backwards: IDs exist for many purposes, not just CSS. Selecting elements by ID in JavaScript, or using a fragment identifier to link to within a page are just two other examples of how they can be used, and not considering the other purposes of the attribute is part of the problem (see also ‘CSS classes’).
> Same thing with JavaScript. If you need a class, you should add a prefixed one (e.g. "js-foo").
How does the developer benefit from writing the classname like this? Why is a prefixed classname any more informative to you than a selector that tells you a little about the context in which the element appears? I've actually come around to the view that if you're using this class to select on any other criterion than the semantic purpose of the element is wrong, and it would be more appropriate to use a data attribute to contain the hooks for additional behaviour.
Reuse of what, exactly? Selectors? Properties? My assertion is that if you need to re-use properties a lot then you should make use of a preprocessor framework and then use a combination of mixins or extends. Re-use of selectors is an unnecessary artefact of how OOCSS (and similar) suggest you should write your code.
> If you want to build a library of reusable components, IDs are obviously not what you want.
If you're building components that could end up on any page entirely outside of your control, I agree. But: horses for courses. It still has valid uses, and avoiding it entirely isn't necessary.
> Secondly, if you use IDs which were added for JavaScript or fragment links, you'll introduce some coupling which really shouldn't be there.
You're looking at this backwards: IDs exist for many purposes, not just CSS. Selecting elements by ID in JavaScript, or using a fragment identifier to link to within a page are just two other examples of how they can be used, and not considering the other purposes of the attribute is part of the problem (see also ‘CSS classes’).
> Same thing with JavaScript. If you need a class, you should add a prefixed one (e.g. "js-foo").
How does the developer benefit from writing the classname like this? Why is a prefixed classname any more informative to you than a selector that tells you a little about the context in which the element appears? I've actually come around to the view that if you're using this class to select on any other criterion than the semantic purpose of the element is wrong, and it would be more appropriate to use a data attribute to contain the hooks for additional behaviour.
>Reuse of what, exactly? Selectors? Properties?
Building blocks or legos. You create a library of these and then you just use them.
Soon, you reach a point where implementing new features/views doesn't require any new CSS. You just use what's already there.
As a result, the total number of rules is kept at a minimum, which helps with performance and also with maintenance.
>If you're building components that could end up on any page entirely outside of your control, I agree.
Well, I don't write every template/view/whatever.
>How does the developer benefit from writing the classname like this?
If you change the JS, you can freely add/remove those "js-" classes.
If you change the structure of the markup, those classes will warn you ahead of time of potential issues. They will also give you something for grepping.
Also, using those classes on the CSS side can be easily identified by tools.
Basically, it's just a naming convention which tells you something about the purpose of this particular class. In languages like Java, C#, etc. you also use naming conventions to communicate something useful. In CSS, I do the same thing. There is UpperCaseCamelCase, lowerCaseCamelCase, _withLeadingUnderscore, and x-prefixed. All of these things mean something specific.
Apart from reset/normalization and base styles, everything is written in the same mechanical style. This makes the code really easy to navigate. It's very organized.
Building blocks or legos. You create a library of these and then you just use them.
Soon, you reach a point where implementing new features/views doesn't require any new CSS. You just use what's already there.
As a result, the total number of rules is kept at a minimum, which helps with performance and also with maintenance.
>If you're building components that could end up on any page entirely outside of your control, I agree.
Well, I don't write every template/view/whatever.
>How does the developer benefit from writing the classname like this?
If you change the JS, you can freely add/remove those "js-" classes.
If you change the structure of the markup, those classes will warn you ahead of time of potential issues. They will also give you something for grepping.
Also, using those classes on the CSS side can be easily identified by tools.
Basically, it's just a naming convention which tells you something about the purpose of this particular class. In languages like Java, C#, etc. you also use naming conventions to communicate something useful. In CSS, I do the same thing. There is UpperCaseCamelCase, lowerCaseCamelCase, _withLeadingUnderscore, and x-prefixed. All of these things mean something specific.
Apart from reset/normalization and base styles, everything is written in the same mechanical style. This makes the code really easy to navigate. It's very organized.
> Basically, it's just a naming convention which tells you something about the purpose of this particular class. In languages like Java, C#, etc. you also use naming conventions to communicate something useful. In CSS, I do the same thing. There is UpperCaseCamelCase, lowerCaseCamelCase, _withLeadingUnderscore, and x-prefixed. All of these things mean something specific.
What does those four styles mean then, respectively? I'm curious.
What does those four styles mean then, respectively? I'm curious.
Subtree root node, descendent, modifier, and not CSS.
A modifier changes one or several aspects to make it more suitable for a different purpose.
You can stick subtrees into the leafs of other substrees. There is no overlap or interweaving.
So, if you look at some node, you just travel the tree up until you hit the first UpperCaseCamelCase class. That's the structure this node belongs to. It's also the name of the partial.
E.g. this is the "bricks/_Pagination.scss" partial:
If there are any modifiers, a preview (with one line description) will be generated for each of them.
Apart from the reset/normalization and base styles, everything looks like that.
A modifier changes one or several aspects to make it more suitable for a different purpose.
You can stick subtrees into the leafs of other substrees. There is no overlap or interweaving.
So, if you look at some node, you just travel the tree up until you hit the first UpperCaseCamelCase class. That's the structure this node belongs to. It's also the name of the partial.
E.g. this is the "bricks/_Pagination.scss" partial:
/// Simple pagination for search results and similar things.
///
/// <div class="Pagination">
/// <a href="#" class="active">1</a>
/// <a href="#">2</a>
/// <a href="#">3</a>
/// <a href="#">4</a>
/// </div>
.Pagination {
@include TopMargin;
text-align: center;
font-size: 0;
& > a {
background: lighten($lightBlue, 12.5%);
color: #fff;
display: inline-block;
width: $gap;
padding: $gapTiny 0;
text-decoration: none;
margin-left: $gapTiny;
font-size: $rootFontSize;
&.active {
background: $lightBlue;
cursor: default;
}
&:hover {
background: $lightBlue;
}
&:first-child {
margin-left: 0;
}
}
}
If there are any modifiers, a preview (with one line description) will be generated for each of them.
Apart from the reset/normalization and base styles, everything looks like that.
You have an accessibility issue in your example markup. Having links adjacent to each other without either non-linked readable characters, or an appropriate markup structure leads to screen readers reading out the numbers 1 2 3 4 in a "linked" tone, and it is impossible to distinguish that from a single link containing all four numbers.
That's why the web development best practice here is to mark up a list of links with a list. And before we had web standards people used to separate adjacent links with the | character, so at least screen readers would have the numbers read out in a link voice, and the 'bar' read out in a non-linked voice.
If your intention is to create reusable components, then it's essential that you're not introducing accessibility issues by default.
There's a second accessibility issue with the pagination. Why is the active page a link? What does it link to, considering that you are already in the view that should be that page. That feels like a link that does nothing. For a generic pagination, this feels like another accessibility issue to trip up developers.
Also, there's the obvious anti-pattern of using # as the href, instead of an actual URL. That leads to developers assuming that everything is handled with JavaScript. It's easy to fix in documentation, by putting in realistic looking URLs in there.
Good examples of documentation are ones that demonstrate good practice, and not encourage bad habits.
I know, good documentation is not easy. That's why we have to be careful of falling into these sorts of pitfalls. Especially when developers have no choice but to rely on documentation being correct.
That's why the web development best practice here is to mark up a list of links with a list. And before we had web standards people used to separate adjacent links with the | character, so at least screen readers would have the numbers read out in a link voice, and the 'bar' read out in a non-linked voice.
If your intention is to create reusable components, then it's essential that you're not introducing accessibility issues by default.
There's a second accessibility issue with the pagination. Why is the active page a link? What does it link to, considering that you are already in the view that should be that page. That feels like a link that does nothing. For a generic pagination, this feels like another accessibility issue to trip up developers.
Also, there's the obvious anti-pattern of using # as the href, instead of an actual URL. That leads to developers assuming that everything is handled with JavaScript. It's easy to fix in documentation, by putting in realistic looking URLs in there.
Good examples of documentation are ones that demonstrate good practice, and not encourage bad habits.
I know, good documentation is not easy. That's why we have to be careful of falling into these sorts of pitfalls. Especially when developers have no choice but to rely on documentation being correct.
> If your intention is to create reusable components [...]
This isn't like Bootstrap, mind you. It's a set of building blocks for one particular website.
> Also, there's the obvious anti-pattern of using # as the href, instead of an actual URL.
It's about the structure of the markup. "#" is used as no-op href for dummy links. "data:," is used as no-op src for dummy images.
This isn't like Bootstrap, mind you. It's a set of building blocks for one particular website.
> Also, there's the obvious anti-pattern of using # as the href, instead of an actual URL.
It's about the structure of the markup. "#" is used as no-op href for dummy links. "data:," is used as no-op src for dummy images.
I think most of the advocates for OOCSS would agree with you that preprocessors make them better. But the principles they're proposing are made better by preprocessors, they're not invalidated by them. Preprocessors let you get the benefits of reusable components without polluting the DOM with classnames. Which is better than plain OOCSS in most cases. But OOCSS allows you to have those reusable component benefits without tying you into a specific preprocessor (or any at all), and that is a benefit as well, even if you personally don't think its worth the semantic tradeoff.
Basically
OOCSS with preprocessor => reusable components + minimum DOM impact
OOCSS without preprocessors => reusable component + potentially messy DOM
CSS without OOCSS => potentially clean DOM + potentially non-reusable CSS
Basically
OOCSS with preprocessor => reusable components + minimum DOM impact
OOCSS without preprocessors => reusable component + potentially messy DOM
CSS without OOCSS => potentially clean DOM + potentially non-reusable CSS
> Nothing of this has anything to do with cargo cults. There is an actual reason behind every rule.
There may be reasons, but I find there is often a lack of understanding about the context in which that rule was developed, and the compromises that were made. A developer not understanding why things must be done in a certain way, but doing it anyway sounds pretty cargo-culty to me.
There may be reasons, but I find there is often a lack of understanding about the context in which that rule was developed, and the compromises that were made. A developer not understanding why things must be done in a certain way, but doing it anyway sounds pretty cargo-culty to me.
Well, that's the definition of a cargo cult. Following some rules without actually knowing why.
If you use IDs because some person on the internet said "Use IDs, for the love of God", you're cargo-culting.
Thing is, I know why I follow these rules. I'm the one who wrote them and refined them over the course of several years. I made informed decisions based on 13+ years of experience of which I spent the last 4 writing ecommerce related frontend code for dozens of websites.
This stuff is never done. It's always based on my current knowledge/experience and the limitations of the current boat-anchor version of IE.
Nowadays, my code is more maintainable, I can actually do some sort of "refactoring", and the total amount of selectors is very close to the optimum.
Anyhow, not using IDs makes writing CSS easier. Even if you don't understand the reasons/mechanics behind it.
If you use IDs because some person on the internet said "Use IDs, for the love of God", you're cargo-culting.
Thing is, I know why I follow these rules. I'm the one who wrote them and refined them over the course of several years. I made informed decisions based on 13+ years of experience of which I spent the last 4 writing ecommerce related frontend code for dozens of websites.
This stuff is never done. It's always based on my current knowledge/experience and the limitations of the current boat-anchor version of IE.
Nowadays, my code is more maintainable, I can actually do some sort of "refactoring", and the total amount of selectors is very close to the optimum.
Anyhow, not using IDs makes writing CSS easier. Even if you don't understand the reasons/mechanics behind it.
> if you’re writing CSS professionally then there’s really no good excuse for not using a CSS preprocessor.
CSS preprocessors aren't without their own problems as well. An app that I'm currently working on has a history of semantic HTML, but having no room for compromise had resulted in a CSS file that is 4000 lines long.
There were lots of cases where an innocent looking @extend created monster selectors (https://twitter.com/mezzoblue/status/390274599167877120/phot...). This is non-obvious behaviour that should be avoided.
CSS preprocessors aren't without their own problems as well. An app that I'm currently working on has a history of semantic HTML, but having no room for compromise had resulted in a CSS file that is 4000 lines long.
There were lots of cases where an innocent looking @extend created monster selectors (https://twitter.com/mezzoblue/status/390274599167877120/phot...). This is non-obvious behaviour that should be avoided.
> This is non-obvious behaviour that should be avoided.
Generating selectors automatically obviously carries the risk of creating something excessively large that you don't want. But I want to challenge the widely-held view that a long CSS file is necessarily bad. First of all, what does 4,000 lines mean in terms of actual document weight? And what is the weight of the gzipped file actually served? Repetition in selectors might look bad on the surface, but this is exactly the kind of thing that compresses well. Once actually served this file then ought to be cached well, and so the issue of document weight is potentially moot.
Obviously there are extremes beyond which it may no longer be sensible to serve something like this, but arguably at that point you ought to be noticing issues in your un-preprocessed source anyway.
Generating selectors automatically obviously carries the risk of creating something excessively large that you don't want. But I want to challenge the widely-held view that a long CSS file is necessarily bad. First of all, what does 4,000 lines mean in terms of actual document weight? And what is the weight of the gzipped file actually served? Repetition in selectors might look bad on the surface, but this is exactly the kind of thing that compresses well. Once actually served this file then ought to be cached well, and so the issue of document weight is potentially moot.
Obviously there are extremes beyond which it may no longer be sensible to serve something like this, but arguably at that point you ought to be noticing issues in your un-preprocessed source anyway.
> The web is fundamentally a semantic medium.
I think this premise is outdated. The web is more and more hosting apps rather than documents.
I think this premise is outdated. The web is more and more hosting apps rather than documents.
This "apps rather than documents" is hokum. Each time one of these JavaScript-mandatory websites is declared a case-study in web app development best practice, decrying progressive enhancement, there's normally something underneath about building a PhantomJS scraper so that search engines are indexing something more than a blank page.
For example, bustle.com's PhamtonJS emulation of being a good webizen: https://twitter.com/tyleralove/status/367494129091346432
I like how people keep pointing to Google Maps as an example of Web Apps, and how web development best practice is outdated: http://www.fixmystreet.com/around?pc=SW1A+2AA
For example, bustle.com's PhamtonJS emulation of being a good webizen: https://twitter.com/tyleralove/status/367494129091346432
I like how people keep pointing to Google Maps as an example of Web Apps, and how web development best practice is outdated: http://www.fixmystreet.com/around?pc=SW1A+2AA
What is fixmystreet supposed to be an example of?
Not sure what that has to do with semantics. Are you saying that NAV etc. aren't valid semantics on applications?
> Are you saying that NAV etc. aren't valid semantics on applications?
What I mean is that the (supposed) benefits of semantic use of CSS classes go out of the window when you're no longer hosting documents to be read by machines. And the user does not care if the classes of HTML elements are semantic or not.
What I mean is that the (supposed) benefits of semantic use of CSS classes go out of the window when you're no longer hosting documents to be read by machines. And the user does not care if the classes of HTML elements are semantic or not.
Some users do, assistive technologies can benefit significantly from semantic HTML and class names.
Semantic HTML elements, yes, but CSS class names are ignored by assistive technology at large.
Consider the authors examples:
The first example should really use extend or it will output the content of the news-item for each selector separately, and the news-item mixin contains many properties with static values that will be repeated. This example also couple the styles to the content, it should now only be used for news, this is not about premature optimization, but consistently working against code reuse, why cannot the authors beautiful blue box be used on something else then news. The alternative, the box-standard can be use multiple times and it is easy to understand and modify from the developer perspective and to anticipate the result (“what is breaking?”). Lastly why do author use the element (div) selector, the element selector is not necessary and it prevents author from writing it on section or article if that would semantically correct.
For the second example, yes, the example is extreme, and I do not see many people writing that many selectors, but the author is right that OOCSS will create multiple classes. Writing this box, I would probably have something like this: box box--special box--extra-padding. After the example the author argues that this is approach transfers the close coupling to the markup. Let us say we have a 100 pages and one style sheet, should the CSS really serve all those 100 pages or should each individual pages deal with one style sheet. With a 100 pages, it will be impossible to keep track of all the pages when you are writing your CSS.
From my perspective, the last example is legit, but element selectors with descendent selectors might cause performance issues, because every time the browser hits a link (a) it have to evaluate the hierarchy in the selector. Btw, the ul element selector is unnecessary.
For the second example, yes, the example is extreme, and I do not see many people writing that many selectors, but the author is right that OOCSS will create multiple classes. Writing this box, I would probably have something like this: box box--special box--extra-padding. After the example the author argues that this is approach transfers the close coupling to the markup. Let us say we have a 100 pages and one style sheet, should the CSS really serve all those 100 pages or should each individual pages deal with one style sheet. With a 100 pages, it will be impossible to keep track of all the pages when you are writing your CSS.
From my perspective, the last example is legit, but element selectors with descendent selectors might cause performance issues, because every time the browser hits a link (a) it have to evaluate the hierarchy in the selector. Btw, the ul element selector is unnecessary.
I had mixed feeling until I saw “USE IDS, FOR THE LOVE OF GOD”, then I stopped worrying and stopped reading.
> if you’re writing CSS professionally then there’s really no good excuse for not using a CSS preprocessor.
I want to compile my CSS about as much as I want to compile my grocery list. Preprocessors add a layer of complexity on to something that is already impossibly simple.
I want to compile my CSS about as much as I want to compile my grocery list. Preprocessors add a layer of complexity on to something that is already impossibly simple.
Preprocessors help with organization. I have one partial for each of my legos, for example.
They also allow you to do things like cache busting or sprite sheet generation.
Personally, I think it's totally worth it.
They also allow you to do things like cache busting or sprite sheet generation.
Personally, I think it's totally worth it.
If your CSS ‘impossibly simple’ then it sounds like you don't need it. Every tool has its place: writing HTML by hand is still worthwhile in certain situations. My article assumes you are writing CSS in a project of sufficiently large scale that how you approach architecting it is important enough to think about.
There are very few large scale projects that warrant it. Preprocessors save you a few search and replaces, little else. You're left with a stylesheet that is no longer recognizable to its author and can't be debugged via your browser's developer tools.
Good read. It has me asking quite a few questions of what I consider to be best practice.
Please stop it with the massive fonts on web pages
Please familiarise yourself with the command/control + minus shortcut.
Take a step back and realize that there is at least one more way of doing this. Why not have the presentation be the specification, and we can just build the html to conform to the that specification instead (via the use of helpers and all other commonly accepted forms of duplication reduction). Your post basically declares this Doing It Wrong™, but I imagine that's just because you'd rather see better looking html than you would see better looking css.
You have the semantic issues well thought out, however you are flat out declaring data semantics are more important than presentation semantics. For most projects, the HTML is only used in a browser, and isn't the source of truth for the application, i.e. it is inherently coupled with the presentation. They might as well be one and the same because this is it's only purpose in the world. Leading from that, the only issue is maintainability, and here is where your ideas aren't fully developed.
As will all separation of concerns, your solution (the one about breaking news) also adds a layer of misdirection. Sure I don't have to change the html to change the presentation, but now I have figure out where that part of the presentation is modified. My CTO and designer (2 people I have a lot of respect for) were the people who eventually changed my mind on this. They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds. It took probably 3 or 4 weeks for me to relent on this before I accepted, but it is much easier for everyone (think of the new hires as you pointed out!) if they don't have to know tons of info about the domain, but just look for the offending element and make a simple change in place rather than have to unravel the css toolkit to find where my button was made blue instead of green. Additionally, they know this change is only affecting this one element they were told to change. On our team, that is better maintainability because that is how real changes are specified. In your case, by the time this spec makes it's way to the developer, it needs to have traveled through people who know that part of the web page is a breaking news container and translated from whatever the original complaint was or the developer will likely have another problem to figure out before he can even begin changing what will likely end up being a single css rule.
Loose coupling is simply about defining avenues of change, and it only improves maintainability when it enables making changes easier. This has been extrapolated to mean "does this have to change or not", which is over thinking it a bit. In my example, I made a typical update by changing exactly one thing in exactly one place, without having to traverse any levels of misdirection. Just figuring out how to make one thing not have to change doesn't make it more maintainable.
When we're talking about web pages, it's also important to realize that we're typically not changing just the presentation of static data; we're adding and removing features to figure out what makes this page more useful. The HTML is typically going to change anyway when we're modifying the page, which again leans in favor of a common set of CSS selectors to build against (in terms of avenues of change).
As I said, I'm probably the most outspoken person at my office when it comes to semantic HTML, but it's only when I'm describing actual data, i.e. the parts you read. These parts tend to change very little and can be generated and stored in their already rendered state. The parts that do change more often gain a lot from the benefits of OOCSS and BEM techniques.