- In a Q&A article on Smashing Magazine I answered a question about how to look at CSS and determine if it’s good or bad.
-
Harry Roberts expounded upon my answer with lots more specific examples about bad things you can find in CSS (e.g. magic numbers, qualified classes, too vague of selectors). Harry says in this article:
Use IDs in HTML for fragment identifiers and JS hooks, but never in CSS.
- Jeffrey Zeldman reacts to this and defends using IDs. Jeffrey compares abandoning ID’s to OOCSS and avoiding descendant selectors.
- We have Jeffrey on ShopTalk to discuss. We don’t spend too much time disagreeing – but instead focus on a much bigger agreement: being too dogmatic about these things is the worst possible stance.
- Totally coincidentally, we have Harry Roberts on ShopTalk next week.
Now my turn again. I love blogging.
I feel like if anyone gets off-put by Harry’s writing, this article or any others, it’s that he sometimes comes off as being dogmatic. If that term doesn’t mean anything to you, just think of it as inflexible thinking. This is the way things are dammit and that’s that. Having strong opinions is awesome, having inflexible ones is not. Writing about what works for you is awesome, writing iron-clad manifesto’s is not.
I’ve met Harry. He’s a nice guy. I’m not sure how dogmatic he is in his thinking (I doubt much). We’ll talk about that on ShopTalk.
Jeffrey called “bunk” on the decree that ID’s should never be used:
Say it with me: There is nothing wrong with id when it is used appropriately (semantically, structurally, sparingly). There is plenty wrong with the notion that class is always preferable to descendant selectors and semantic, structural ids.
To me that edges just as close to dogmatism as Harry did. And I’m guilty of this as well. I wrote about this in my article “A Line In The Sand, A Story About Meaty Chili and Using Classes”:
I’m not going to use ID’s to style things. No compromise. Even if an ID might seem like it could save me in a short term way, the long term benefits of never using them are greater.
Avoiding ID’s altogether has lead to a better CSS authoring experience for me. I probably should have framed it more like that, but hey.
I feel like Jeffrey thinks that avoiding ID’s means over-classing everything else, giving up on the cascade, and not using intelligent selectors that encourage clean markup. I don’t think ID’s have anything to do with those things. Over-classing is dumb, don’t do that, and don’t think that that’s what OOCSS means (I think of it like: find a pattern, give that pattern a class). The cascade is still useful, but in limited ways. You could argue it hurts as much as it helps. And finally, I’m all about descendant selectors. They work equally well with classes as with ID’s. Better, I’d argue, since the class is re-usuable.
I also feel Jeffrey has a deeper perspective on this as Harry or I might. As we talked about on ShopTalk show, Jeffrey worked through some eras where markup was extremely nasty and helped usher in an age of clean markup that we’re used to seeing today. I can understand being nervous if he feels things move back the other direction.
I’m in situations all of the time where I’m creating a single page site that has a short life. OOCSS is great for some things, but for small projects with a quick turn around sometimes it is just too much.
I know it is good to use best practices, but sometimes you just gotta lean on what will work in a pinch.
Even though I wrote it twice in my comment, I’ll write it again. I mean sometimes. ID’s don’t need to be off-limits all of the time.
But why even use an ID? A class that you only use once accomplishes the same goal, except that you don’t have a headache further down the line when the project expands. Even if the project never expands, you didn’t expend any more time or effort using a class, did you?
@Scott, I haven’t used IDs in a long time, but I agree with Zeldman about being overly Dogmatic about putting down a practice when it still works. All the sites I make have been responsive for the last two years, but don’t mind others making something that is fixed-width.
Table layouts still work…
It may be a good idea to build a styleguide for yourself on which to create sites; similar to bootstrap, but not as fully fledged since you don’t want to spend all your time re-writing tons of styles:
http://larrybotha.github.com/styleguide/
Delete what you don’t need when starting a project, test how everything looks before implementing it, and then simply put your site together like a puzzle. It’s scary how quickly a site comes together once the majority of the elements have already been laid out.
Wesley,
I’m not sure I agree with you. OOCSS is just as fast, if not faster for me actually. In general, its a good habit forming to do your CSS in this manner. Inheritance is your FRIEND! Even on small projects, scoping things will get messy with IDs especially if you tend to re-use your code. ID scoping for me is actually more important on enterprise level websites where you have unknown CSS classes living underneath your code, and you don’t want them to conflict. (This can still be avoided with OOCSS, but then sometimes you have to get more crafty with your naming convetions) So in my opinion both have their place.
For me it’s plain and simple over optimisation, not using an ID for the possibility that you “might” use that style again in the future is wrong.
While it’s unique and ID is fine, once your duplicating then you need to look at optimising and using a CLASS instead, but only for aspects that are relevant.
So if your writing everything to be OOCSS with the idea that you can take it and use it anywhere in the future, then sure CLASSes are the way to go.
Just don’t fall into the habit of Premature Optimisation.
“Premature Optimization.” Sounds like lazy development to me.
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” –John Woods
Its not just that we “might use that style again in the future,” its that we’ve found patterns in the designs, and have chosen to use classes that can be applied and extended for unique instances, instead of repeating the same 4 declarations for 10 different selectors.
I’ve watched all this unfold since Harry posted his article the other day. I have huge respect for Jeffrey, yet he seems to have the belief that using IDs instead of classes is more “semantic”. This isn’t true however as the browser doesn’t gain any information from the contents of the ID.
Harry may come across as dogmatic at times, however they’re always for incredibly justifiable reasons. CSS architecture has changed a crazy amount in the last couple of years, so we need people to say “this is the way it should be done and here is the evidence to support it”. I feel CSS is becoming less of a designer’s responsibility, and falling more into the hands of people who fully understand concepts such as OOCSS.
I’m very interested to hear Harry’s ShopTalk episode.
Just gonna dive in dead quick and say:
Thanks man, that means a lot :)
I think I am pretty confident in my thinking; I spend all of my working life scaling CSS, writing CSS for large teams who work on sites whose development takes months (if not years). I have a lot of conviction in my thinking, and I really regret that it comes across as dogmatism.
I’ve learned the hard way when IDs have tripped me up in even the most unlikely of circumstances, where loose and convoluted selectors have led to half-day refactoring jobs where it should have taken a few seconds.
Experiencing and circumventing this first-hand is something I am (overly?) keen to share, because it’s not until you realise where you’re causing yourself work that you realise how much easier things can be.
I guess I work in an environment where it is very important that rules are enforced because I’ve seen where things spiral if there aren’t any. If I wasn’t as forthright and confident in my opinion in my day job, I’d really struggle to do it.
Really looking forward to chatting on Shop Talk tomorrow.
Cheers,
H
A great tool for learning the proper use of a tool/technique is to use it all the time. Use it until it hurts. This is a technique employed by my father when he was teaching me to drive stock car. He’d have me go faster and faster into the corner until I spun out. That identified how fast I should go and also taught me the consequences.
I think Zeldman hits it on the head with “Giving every paragraph element in the sidebar a classname is not only a needless waste of bandwidth, it’s also bad form.” That being said — what if you never even look at your outputted HTML? In that case does it really make a difference?
The bandwidth issue is moot. I mean, everyone’s using gzip (right?) so adding 10 identical strings makes virtually no difference. (Hell, if bandwidth is such an issue why is Zeldman encouraging “semantic” ID names? They should all be 2 characters long.)
The actual potential issue is simply by adding more code you make your code uglier and possibly harder to read through and debug later. Still, a fairly minor issue IMO.
Related Twitter thread:
This is exactly the confusion that exists. It ultimately is not a do use IDs or don’t use IDs debate. They co-exist in the same ecosystem and serve different purposes. For small to large projects I tend to use OOCSS because its great for habit-forming and code re-use. On the other hand, when working on large-scale websites where you haven’t worked on or have underlying code, there’s probably a solid chance that your loved “.text” class is already being used for something else. That being said, when you want to scope your CSS specifically with the intention of not sharing and being self-contained then IDs can come in handy.
I think that as long as you write your code in a certain way for a reason, and not just because you’re blindly following whoever or because you copy and paste it from somewhere without understanding it, it’s okay.
The OOCSS and the SMACSS approach are great guidelines, but sometimes you have to break the rules to solve a particular problem in a project.
Don’t understand the ID phobia either. Yes, in terms of JS – it’s not safe to use the same ID for several items, but it doesn’t mean that you must not use them. It really is dumb to “over-class”.
I also don’t understand the “table” phobia :) Also extremely dumb.
Off topic – how do you guys put your avatars? Do I need to sign up in the lodge?
Goto Gravatar.com.
Putting together a large site with ID’s is the worst possible experience you can set yourself up for. I’ve been there, and that’s where Harry Roberts’ focus of work is.
Not using ID’s comes from the nightmares that ID’s in CSS creates.
Not sure on what you’re qualifying your statement, but again, attempting to write flexible styles that scale without using modular methods in writing your CSS becomes a nightmare.
How do you define ‘over-class’? 3 classes? 5 classes? 10 classes? Is there a magic number applied to the number of classes you may apply to an element, or is your reasoning deeper where the number of classes perhaps depends on the situation, the number of times that particular type of element appears, and how modular you can make the default state of the block?
This is again an issue coming from experience in building large websites.
John Lueders – thanks :) worked
Larry Botha – large web-sites – yes. And still, sometimes it happens so that you need to set an ID for JS. Why to declare a new class if you can simply use it’s ID. The point is that you must not limit yourself. It doesn’t say – you should use ID’s everywhere :)
Hello Chris, I very much agree with your overall opinion about dogmatism in the web design industry. I don’t think that it is limited to how to do CSS – we see it in a lot of places, especially with regards to mobile and responsive web design. I wonder if you have read this article: CSS Architecture by Philip Walton? From what I gather he is suggesting using the cascade less and trying to be more specific with classes, and avoiding complicated and generic selectors. This bit of CSS from his article illustrates what he is saying:
Cheers, Mark
I’d argue that those sorts of practices are not about using the cascade less, but about better understanding how it operates.
I completely agree with this part of the article, some people are taking from it that they need to add classes to every single element (like adding a class to all
<p>tags), but it’s not about that imo. It’s about decoupling styling from markup, ideally we would want to create a stylesheet that doesn’t need to be modified whenever we make a markup change, for example deciding to use a set of divs for a navigation rather than list items. This probably wouldn’t happen but a problem I recently had was creating a flexible styling solution for accordions that can be dropped in anywhere in the code and still function correctly, at first I had markup that looked like:Obviously this would be easy enough to style using selectors like
.accordion h1,.accordion h1 + pbut it’s not very flexible…what if we decided to use h1-h6 throughout our markup instead of h1’s everywhere, different accordions could have different title tags, and what if<p>wasn’t always appropriate for the content we wanted to display within each section…simply adding a class name to the<h1>and<p>solves these problems with minimal effort.This is only a tiny part of what could potentially be a giant site though, I have just as many problems battling with Magento’s default stylesheet and over-specific rules (previous devs simply overrided Magento’s stylesheet when theming instead of creating a new one), having to try and overwrite rules like
ul#main-navigation li.item a.navigation-link.current-item.overis just as annoying as coming across a stubborn id which is why I lean more towards Harry’s approach of single class names, at least I know I and the other people on our team won’t experience the same frustrations I did!FWIW, I feel a fair amount of this “code smell” discussion is over generalising. Talk about the same thing 5 years ago (or ask Harry 2 years ago) and the answers would be very different. Even reading Harry’s points today, almost all of them have significant exceptions or are a reflection of a specific architectural approach that he employs at this point in time. That’s not to say that there isn’t worth in these discussions.
I’d argue that this is really repeating the importance of a coherent architecture, set of principles, and working towards keeping that whole structure self-consistent. You can have “code smell” within a context but that doesn’t necessarily make them universals that always apply. In other contexts different decisions can be made and you can appreciate why smart people have made them. Otherwise, there is a tendency to move from dogmatic position to dogmatic position – something that (anecdotally) is not infrequent in this sphere.
Once a hard-line position is taken up, it’s not always easy to move away from it, especially if you have invested a lot of time and effort. Zeldman, to his credit, was prepared to adjust his well-known position based on some well argued points in the comments on his article.
But many developers have found that the effort to “separate concerns” also led to a different kind of tight coupling between them, which is exposed most clearly in contexts where it results in maintenance woes. The efforts people are making to loosen that coupling don’t threaten Zeldman’s past efforts, they build upon them and move on from an overly strict (in today’s context) understanding of HTML-level semantics that tied CSS-hooks (like class names) to document- and content-level semantics. Likewise, you can expect that we’ll be employing different tactics in the years to come and possibly looking to avoid many of the approaches that may be considered “good” today, especially as the web stack continues to evolve.
Nicolas, I completely agree that most of these discussions are primarily contextual and relative to the concerns derived from today’s web stack.
Most of the suggestions I gave in the article Mark Dixon linked to stem from the fact that in today’s web it’s very difficult (if not impossible) to completely encapsulate CSS components.
But in the (presumably) near future, a lot of these woes may be alleviated by web components which do allow for complete encapsulation of CSS and HTML.
Frankly this is a weird discussion. If you cannot handle ids you cannot handle classes either. It’s as simple as that.
Yup, id has higher specificity and is only allowed once on the page. That does not make as much difference as some may think.
In short: “don’t” use ID is stupid advice. I am sure advocates of this approach were bitten by classes many times too, but chose to ignore that.
I tend to agree. The whole debate and discussion is silly. I immediately turn off when someone starts spewing dogmatic crap about whether to use IDs and what makes life easier. It’s all just subjective conjecture.
I think either method is alright as long as there is some effort put into organizing and structuring the CSS. No one likes to spend the first couple of hours trying to read and understand someone else’s (or you own) stylesheet.
When working on a stylesheet, I try to keep it organized to a rhythm like so:
Have classes / IDs follow a consistent naming convention
Make sure those names are human readable
Put comments in the stylesheet that explain what it’s referring to, a hack, etc
A table of contents at the top is also a nice touch
I believe we should be using what ever fits our design, come on people, we are designers we are problem solvers, code should be serving us in that way, if an ID is needed, totally go for it, if you can go with using just classes that’s fine.
As long as we can keep it clean, working and if it solves our needs or problem then yeeei! if it dont, solve it some other way.
I think this is a discussion like the one from preprocessors, we should be using the one that suits us and works for us!
I appreciate the “just solve problems” and “whatever works for you” attitude, but be hyper self aware about it. This conversation is saying that you might have an “ID’s are totally fine” attitude even though it (might be) shooting you in the foot.
Rodrigo to put what you said into context…. lets say the support beams under your house are giving out and you have 24 hours to implement a solution. You decide to use 10 rolls of duct tape and wrap them around all the beams. Did the solution work? Yes. Is it the best way to do it? Most might decide not. Just because a solution will work does not always mean its best practice or the right thing to do.
I feel dogmatism often spawns in areas of great change and transition where we all want to feel we are doing things ‘the right way.’ When we settle into a system, using OOCSS is just one example, we tend to evangelize our position. If we are open to the idea that there is a better way than we are doing it, that uncertainty can make what we do challenging. This is dramatically magnified in large teams/systems where having a calculated approach is crucial.
Have 10 rockstar developers design the same site and you will have 10 different CSS solutions – all of which work. There is a difference between fundamentals and top level guidelines.
I love Harry’s article and I also love what Zeldman said. Both are right. It’s more about the context than the strategy.
These discussions are helpful to us all in an effort to better to what we do. The problem lies where folks behave ‘elitist’ in their approach as if their way is the ONLY way.
Carry on. Build cool stuff!
Your “10 rockstar developers” theory intrigues me… Initially they may all look the same and function the same. I think the issue that OOCSS is addressing is the sustainability of the code. If those 10 rockstar developers continued to work on the same site would we see some that are using less than ideal code structures start to struggle with upkeep and maintenance? What if you handed the code off to another developer? How easily can they pick up the slack and run with it?
I guess the biggest question is when discussing code theory is: Does it add value to the web dev community as a whole to have as many people as possible working in the same way?
Andrew, I agree with everything you said, especially when having a system that creates continuity. That being said, I think trying to nail down one single system for all projects, companies and contexts is like shooting a moving target. Additionally, I’m thinking the CSS ID debate is just one example of where ‘dogma’ comes into play. We could be talking responsive web design vs fixed width vs separate mobile sites, or another such debate. I am super pro responsive, but realize that isn’t necessarily the right solution for all projects and I’m not going to condemn someone for choosing another path.
In other words, Harry’s article totally makes sense and we should all take note and move in that direction with our work, but we have to also realize that there are exceptions as well as the fact that CSS is an evolution.
Just because a developer doesn’t follow Harry’s guidelines perfectly doesn’t mean he/she isn’t a rockstar developer, just as someone that does doesn’t make them a rockstar either.
Where dogma is an issue is when folks in the community unfairly criticize someone’s work because it isn’t done in a particular way based on the principle of the dogma itself rather than the actual work or the result.
I love these threads. We work in an incredible industry.
On the specific issues of IDs as class selectors, I’m firmly (now, not always) in the “never” camp. I’ve worked on too many large projects with too many large teams where the use of IDs as selectors has created specificity nightmares that required near complete CSS refactoring to fix something that was actually quite small. In my practice now, CSS only hooks into classes (and semantically structured HTML elements), and IDs solely exist as jQuery hooks. In fact, I’ll sometimes give an element an identical class and ID for the CSS and jQuery, respectively. Is that the most efficient way of doing things? Maybe not. Is it the most manageable on a large project in a team environment? My experience says yes. (Your mileage may vary.)
On the larger issue of dogmatism & CSS, I feel that in team environments and large projects, you need a certain amount of dogmatism (I believe that used to be called coding style guides?) in order for everyone to be on the same page. If you didn’t want to bump into other people’s work, deal with specificity and other problems, and overall deal more with headaches than getting your project out the door, certain rules needed to be laid down and followed by everyone.
FWIW, I agree with 99.999% of Harry’s post. His tips represent good CSS practice that I have been trying to follow in my work for awhile now. I don’t want to say that I’m dogmatic about it, but… :-)
Nothing in Harry’s (excellent) article strikes me as dogmatic. I think you’re confusing dogmatic with definite.
Harry’s advice is definite because it is lacks qualifying or “softening” conditions. This makes it confident and clear, rather than timid and vague.
Dogmatism has nothing to do with definite or strong beliefs. Dogma is resistant to change or persuasion. A dogmatic person will not change his beliefs even when presented with compelling evidence or arguments.
(Dogma primarily refers to deeply ingrained religious beliefs that are considered impossible — or heretical — to revise.)
You can answer just about any question with “It depends”; but that is a useless answer. It is good to be definite when you can.
This extreme black-and-white view is actually one of the things that puts me off of some of the recent best practices (in particular the use of ids).
Now, to preface this, I completelly see where they’re coming from, and I even agree – you should strive to ensure that your CSS is reusable, but I do that in different ways: I use a pre-processor and mixins/similar things (I don’t think I need to give more details on how I use that!)
Here’s my issue: I have an element on my site, let’s go with a targeted affiliates area (not using header/footer as an example, as I’ve more and more started using [role=blah] for those). Due to reasons not related to CSS, I have an ID on that element, and to me it makes a lot more sense to use that ID since it’s already there, rather than adding one/more classes to the element. I guess it feels like a waste of a perfectly fine identifier =)
That said, if I was needing to write this in pure CSS without Sass/Less/Stylus… I would likely be grumbling, but adding that “rounded-corners” class on it, because needing to repeat one set of styles again and again and again and again is annoying!
That mindset is part of the problem when trying to create more maintainable, scalable CSS.
Being “efficient” by reusing this ID causes your CSS to become coupled to your javascript, or to other aspects of your code (depending on what you’re using the ID for). It also makes those CSS styles much more specific than other CSS styles, which can be a problem when trying to extend / override your styles. And of course, it means that the styles are not reusable.
Writing maintainable code doesn’t necessarily mean using the smallest amount of code possible. It’s often better to be methodical.
CSS pre-processors can help with writing more maintainable code, but they are only part of a good solution. A pre-processor is no substitute for good CSS structure.
But that’s my exact point when it comes to pre-processors — it is reusable.
The rest of your points I find interesting, and will need to ponder, since those are good reasons. May or may not “convince” me, but it’s at least a lot closer than the specificity/reusable arguments. Thank you =)
Oh yes, you’re quite right about pre-processors allowing reuse of styles, even when hooked to an ID.
There is a slight difference: the output CSS code will repeat your styles. This is not a problem for maintenance, but it affects performance by making your stylesheet larger. Having said that, Gzip should crush most of this, so that may not be a big deal.
Actually, it won’t repeat itself, not if one uses extensions. Admittedly, one still can run into issues with specificity and ending up with something being written high up in the file, when you want it to override something further down.
(My arguments now are less about why one should use IDs, and more about pre-processing, but I’m enjoying the discussion)
Though, what are your thoughts on using, say [role=main] in this way – would you still feel that it’d be an issue to use that, so that one should use a class instead?
“Premature Optimisation” Sounds, nasty… What was that cure? common… common.. oh yes common sense! I am joking of course, but it does seem to me that we are in a period of change, where we are inventing new technologies that have very little benefit (OOCSS despite its claims on speed gains, is after all CSS, as is LESS (in compiled form)).
For a good article on OOCSS (basically states you can use id’s and oocss is not for small projects) check out smashing magazine article .
“An Introduction To Object Oriented CSS (OOCSS)”
http://goo.gl/Phq53
@EdPoole. Semantics are not limited to browsers, they also have meaning to search engines and developers. I’d say the semantic gain of a properly used ID is tiny, but still semantics are not limited to a browser.
“this is the way it should be done and here is the evidence to support it”. No matter how much somebody thinks he is right, this exactly is the problem. It’s dogmatism. Nobody in the community has the right to say how things should be done. Nobody has the right to present opinion as fact.
We’re talking about best practices here. They are opinions by their very definition. OOCSS is definitely not factually the only valid way of architecting CSS in every possible situation. That makes it an opinion, a debate, with multiple views. Not a fact.
I feel like the whole “don’t use IDs” movement has hurt accessibility a little in that I don’t see people using skip menus anymore. We’re using ARIA, sure, but it doesn’t degrade well in older screen readers. Something folks miss a lot is that JAWS (the most popular screen reader) works best with IE, and is super-expensive to upgrade, which leaves many people with older versions that won’t work with the new HTML features.
Personally, I use IDs for major layout components (header, nav, content, footer, etc.), JavaScript (DOM access), skip menus and form elements (obviously). But I also wouldn’t shy away from them in other situations.
Also, the new footer makes it look like you’re creepily eyeballing the merch girl… I approve.
That’s a good example of where dogmatism is scary. If you’re NOT including a skip menu because of a styling decision, your doing it wrong. Even though I’m a proponent of the “don’t use ID’s to style” side of this debate, the to style thing can’t be forgotten. Please continue to use ID’s for anything else ID’s are useful for.
Is there a good resource anywhere that someone could recommend for css styling and structure that also implements the no-id power? I like the idea and am always looking to improve my practices and habits, just looking for some direction and good reads on the subject.
I believe the discussion comes from some people thinking that some people advocate “using IDs is bad, ever!“, and not “don’t use IDs for styling“. The first statement sounds terribly dogmatic, but with more nuance (in the second statement), it doesn’t sound that dogmatic at all.
But, whereas Chris’ article had more of a “meh, this is just how I choose to code my stuff” type of feel, Harry’s article may have come across a bit more ‘aggressive’ maybe? A little bit like “if you use IDs, you’re doing it wrong” and I almost felt attacked. As a result, Zeldman’s article in which he defended the use of IDs, in turn almost felt like defending me.
That may sound a little overdramatic, but my point is that the tone of the three articles in question has a lot to do with how the actual message is received by the public.
Fwiw I commented on this in the past, in your CSS Style Guides article.
My take on this is that when you work on very large projects, every single tool in the box is valuable. Because sooner or later, any tool in that box may become the right tool for the job.
Maybe it’s just me but I really don’t understand how styling IDs can cause so much headache in the long run. Sure classes are more reusable and it’s probably better to use them rather than IDs, but if it’s that difficult to change in an existing project then perhaps the code wasn’t written that well in the first place. With that said, after reading some of the comments here I’m probably going to use IDs even less than I do now, but I would like to hear some real world examples of how using IDs gutted anyone’s (or any team’s) production time in a large project.
I think the thought that it must be a very large project to affect the outcome is misinformed. To me, that’s like saying:
“I’m not going to use hot-keys in PhotoShop because this is just a quick project.”
Time is money. Become more efficient. Always.
We had an issue (medium sized site) where a QA added an ID to an element so they could write a Selenium test. It just so happened the word he used was used as an ID on a different part of the site – at that time we were styling IDs. One of the big reasons for us to go to class only styling is that classes are only used for CSS whereas our IDs are used for multiple things therefore it feels safer to style only classes.
I think the most important thing is you make a decision on how you use IDs and classes and ensure everyone working on your code is aware of the rule.
That’s a good example, thank you, so I think I am thoroughly convinced outside of the cases of “it’s already there!”, and that one I’m still not decided on.
Mind you:
That. So much that. Imagine if the ID hadn’t just been used for styling, but as a javascript hook for something else? Sheesh.
To the women who commented in this male dominated profession: Welcome.
I have been a professional web designer for about 18 months now; I am a bit intimidated to comment at all (especially since I don’t understand all the implications of ‘object oriented’ code).
That said, I am surprised no one has brought this up:
Aside from the big site vs. small site consideration, what I see in the comments is a rift between dynamic vs. static designers…
I haven’t quite mastered scripting yet. Custom Modernizr is about as dynamic as I get. Therefore, id’s aren’t problematic to me.
Code style, extensibility and comments I understand, but having never worked on a team, I often learn by ‘view source’ which really should be minified (e.g. comments removed) anyway.
On my personal website, every page features a logo/brand (with an id of “brand” in the menu [upper left corner]), since this is an element that needs to be consistent and will only be used once per page, it seems fitting (and concise/semantic) that it be given an id.
Further—and maybe this has changed recently—in the MDN article on writing efficient CSS and other articles (especially relavant in the mobile context) they go into great detail about how ‘expensive’ the descendant selector is and even some of the CSS3 styles are.
Much of this is based on what I have read by Paul Irish and Steve Souders and I am just taking them at their word…
Sure, I could use pseudo-class: last-of-type, but knowing how expensive it is, I tend to opt to manually add a class of ‘last’ to the last element instead (etc.). But, as noted, I tend to work on smaller, static sites.
My current website is built on Twitter Bootstrap but I felt it ‘over classed’ many elements so to make it more mobile-friendly I substituted some CSS3 properties with approximate CSS 2.1 properties, simplified classes, added id’s, deleted unused CSS rules, and modified it to include new semantic HTML5 elements (i.e. ‘nav’).
Touching on Tim’s comment, I also added id’s for skip links and such (and then added styling properties to them since they were already there). I am no whiz kid but I do believe it is our duty—if we are able—to make our content available to as many people as possible…
[g@!-%&?n I.E. users excluded—that’s what they get for using a browser that ignores standards!]
Truth be told, I’d love to learn more about scripting, accessibility, best practices, etc…explain it to me, point me to resources or click the link and visit my domain to send me an email or offer me a job :-D and teach me a better way.
As someone who’s been coding for the last 15 years (though admittedly professionally for only a year), perhaps I should welcome you, instead! =)
May I ask how you see a rift between dynamic/static pages? I don’t think that anything of what has been said would be different on a dynamic vs a static page, with the potentional exception of using a CMS that litters the code quite liberally with hooks (Yes, WordPress, I love working with you, but I’m looking at you!)
You shouldn’t take someone’s word for anything, is my feeling. This doesn’t mean you should question every word by them, but see how they’re supporting their statements, so that you have some kind of verification of why they are saying things.
You should also not be afraid to ask why, as long as it is on topic. I think that one of the strengths of the web is that most things can – and should – be questioned, though one should obviously not argue things that are objectively untrue (no, #000 is not the colour white!)
Hi Marie, all,
From what I read in the MDN article, from the Google PageSpeed stuff (Irish and Souders, too) etc. about how CSS is parsed, it is read from right to left so because descendant selectors have to try to match through every node(?…I think that is the term) it is time consuming…”dreadfully expensive” is the phrase I recall.
Then there is the dreaded ‘repaint.’
If I only use classes to prevent specificity problems down the road, wouldn’t I have CSS that is littered (great word…and a prolific example) with class-only descendant selectors and then potential repaint issues any time I dynamically change those classes (position in the DOM and the properties changed would be factors)?
My gut feeling (I have asked on Stack Exchange w/o answer) is that a static page without classes being added, elements being created and inserted. etc. (Analytics being given a pass on this one), would innately be faster than one that not only must be parsed for DOM and CSS but also scripts. Am I wrong?…Within reason*, is it enough of a difference to be significant?
*for me includes mobile.
when you need something only once, you use an id. If it needs to be called again elsewhere in the future due to your oversight, you replace it with a class. when you have a class to represent a button, for example, but need more specificity on one particular button that requires a different border-radius at its left corner, you give it the same class and additionally an id and override that border-radius.
Is there something wrong with this?
Absolute dogmatism? truth:
Don’t use classes to style the same thing on the same properties already styled with an ID rule… because: it won’t work… Or use 256 or 257 of ’em…
…
IDs are strong and individualists; classes are classy and work better with everyone else.
In my humble opinion, this discussion is :not too !important …
My figure painting teacher once told us, “It is our job as art teachers to teach you the rules, it is your job as art students to tell us we’re wrong. But in order to break the rules, you need to know them first.”
I don’t see rules like Chris’s “Line in the sand” or Harry’s “dogma” anything more than that, rules. You shouldn’t break rules unless you know them first. Once you know them, and know why they are what they are, you should break them. Because only then will you be doing so with true intent.
One thing I love and hate about learning web stuff is there is always something new to learn. In my prior comments I felt I had a pretty good grasp on CSS and commented without reading the articles linked in the top, or even noticing that little snippet about using IDs in HTML but not CSS.
I found the article by Zeldman, and even more so the following comments, to really clarify things, so I am now on the ID-free CSS train (with the caveat that for something I truly expect to always be unique that has needs an ID in the HTML, I might style it rather than adding an extra class). Great, insightful discussions and I have learned a lot from all of you, thanks.
I read somewhere and wholly believe that CSS is not a programing language. IDs are artifacts from programming. Lists, Divs, Spans all need to be manupulated by the language. I find more organization of my IDs to use for menus, accordions and such. Classed to me are a great way to keep the formatting and visual cues. It is very easy to combine and mix these up. To say IDs shouldn’t be used or that too many classes is not optimal is really a way to look at who is doing the code. I will stand behind CSS as visual formatting and not programming a page. Use JQuery or JavaScript to add functionality and leave CSS to look pretty.
I have been in situations where the ID vs Class has spun me in some wicked circles, until I learned how to organize and template my CSS, utilize the JQuery classes and keep my scripting in scripts.
IDs were created and used for functionally programming on a web page and not for CSS formatting. Leave CSS to its fundamental class based formatting.