I learn a lot from frequenting forums such as Sitepoint, and working through tutorials from sites such as lynda.com, but I have reached the point in all aspects of my web development including CSS, where I feel the need to standardize the way I do things so that I don’t waste so much time starting from scratch every time I build a site for a client. So I am building myself a small library of templates and base themes (right now it’s in WordPress) in which I want to include the ‘right way’ of doing things.
The problem is there are so many self-confident ‘experts’ who insist that their way is the right way in sometimes a very intimidating manner (not always), I tend to not be able to settle on which of their ways to choose. So I am asking for help deciding in which direction I should go.
My dilemma right now is whether or not to use ID’s as well as CLASS’s in my CSS. This topic has popped up now and again and I understand the problem with ID’s is an issue with specificity, but I tend to use them for major structural items such as wrapper, site header, site footer, sidebars etc. Is there anything wrong with that?
I was wondering if the people of Sitepoint could summarize for me what their preference is, and why so that I can make a definitive decision for myself. (I apologize for the extreme length of my post).
There’s no right or wrong way about structuring your site “assets”, I would say try to make your structure logical so other developers can see what’s going on, an easily find something if they need to modify it.
For general site assets I tend to use a common pattern such as am /assets folder in which you add all “asset” files (logical eh?), eg
/assets
/assets/css - folder for css files
/assets/images - folder for global/standard images
/assets/js - folder for javascripts
/assets/fonts - folder for fonts
… and so on.
Once you have something like that set up it’s easy to call assets into your templates.
Classes and ID’s
There’s nothing wrong with using ID’s where you know an element is unique, or needs to be targeted with Javascript or anchor links.
In this case you can apply both ID and class to the element, but only use the class for styling, the ID serves no purpose but it’s there if you ever needed to use it. You could of course use the ID for styling if you wanted to!
The current opinion is not to use ids in your CSS but to use classes only and avoid the specificity issues. By all means use ids in the html to delineate structural areas but just don’t use them to target elements in the css.
These days I’m also leaning towards using more classes than using descendant selectors as I always seem to get caught out when the client changes the structure. e.g.
.header p {color:red}
That’s fine when there was only one p element in the header but over time the design changed and now there are three p elements in the header and not all of them need to be red so you end up ‘undoing’ styles before you start.
If I’d used a simple class to start with the issue would have been avoided:
p.highlight {color:red}
It does depend on the context and how sure you are that things will never change. Its quite common to use descendant selectors to style list elements “#nav li” as it is likely that the list elements won’t change and if more are added they will most likely be the same.
In the end its a matter of choice but often consistency is the key to easier maintenance. If that means a few extra classes in the html then that’s a small price to pay.
The only css I use on the basic structural ID’s such as wrapper are positioning, size and background, etc that make up the basic bare-bones site. So are you saying that I should probably add more classes to the smaller elements just in case down the road I may need them for my styling? So I should never use
#right-sidebar a{ color: #fff; }
but actually add a class, say ‘right-link’ to the anchor tag in the right sidebar and use
.right-link { color: #fff; }
?
I’ve often wondered at the number of classes WordPress uses in the same elements (most of which I never touch when I’m building a custom theme for a client) - whether it was okay and even useful or whether it was going overboard. One of my reasons for building my own themes and templates for my use, is to keep things as lean as is practical.
That’s the general idea but I would never say never
If you can be sure your content won’t change and that you always want all anchors in that section styled the same then the descendant selector is ok. If you have hundreds of anchors all the same in that location then the descendant selector is the way to go. If on the other hand you may have requirements for various anchors then classes are the way to go and indeed will be parsed quicker than the descendant selector (not that that’s a real issue in most cases).
I would not use the id to target them though because of situations like this.
e.g.
#right-sidebar a{ color: #fff; }
If you then want to add a class to a special anchor you may try this.
a.special{color:red}
However because of the extra specificity of the id the above won’t work. You would need to qualify the rule.
#right-sidebar a.special{ color: red }
If you had used classes from the start you would simply do this.
I’ve often wondered at the number of classes WordPress uses in the same elements (most of which I never touch when I’m building a custom theme for a client) - whether it was okay and even useful or whether it was going overboard. One of my reasons for building my own themes and templates for my use, is to keep things as lean as is practical.
Yes wordpress does seem to over-use classes and there is a danger of making things too complicated so you do need to plan ahead and decide enough is enough and just create a new class instead of multiple modified classes.
I’m not keen on “current thinking”. I don’t want my code to look like the kind of amateur garbage that WordPress and its ilk churn out, with classes scattered around like confetti. It’s a nightmare to work with and causes loads of unnecessary bloat. The beauty of CSS is that it allows descendant selectors and specificity to enable really powerful and efficient coding. Why throw that all away just because there’s a risk someone might one day come along and b****r around with the HTML?
So if I am developing a site for a client that uses a content management system, which seems to be the bulk of my work, and want the code, css and structure to be lean and efficient (not a lot of extra code for “just-in-case” bells and whistles, my best option would be to build a custom cms?
I remember once playing around with developing a theme from scratch in Drupal 7 and being stunned by the number of layers of nested divs that it produced around elements for no apparent reason. Styling would be a nightmare.
You don’t need to build a custom system, but if you want full control over templates, content, and output, then choose a CMS that allows you to do that. Systems such as Wordpress and Drupal often come with a lot of bloated code, especially using pre-made themes and addons - you can of course strip out the bloat but that’s time consuming.
Many CMS’s don’t impose any type of structure offering you a totally blank slate so you can develop the site however you wish, one of these options may be a better fit for your intended workflow?