Warning: Illegal string offset 'filter' in /var/sites/t/theproactiveprogrammer.com/public_html/wp-includes/taxonomy.php on line 1409
There is a lot of dogma in programming. I don’t know if there are similar levels of dogma in other forms of engineering, but the adamance with which some programmers subscribe to certain practices and approaches can be quite disturbing. One of my favourite stackoverflow threads is a post entitled – “What’s your most controversial programming opinion?”. A number of the answers allude to the problem of dogma in programming, for example: the only best practice you should be using all the time is ‘use your brain’.
One ‘best practice’ which I have been thinking about recently is the idea that you should never write inline css. I have always written a lot of inline css. I must admit, I do so largely out of habit, as I have never really worked on a team where this practice was considered unacceptable. From time to time however, I come across a view that strongly condemns inline css. The reasons given tend to be one of the following.
There are times when you want a certain style to be reused many times. An obvious example is a button. Typically you will want all of your buttons to look the same, therefore it is of course common sense to not repeat yourself (remember the DRY principle). I absolutely agree with this justification, and in cases like these I tend to advocate the use of an external CSS file.
In reality however, there are a lot of cases where an element needs to be styled in a unique way. In these cases, I prefer not to use external styling. The reason for this is that I don’t see the point. It may only take a few seconds to flick between your html and CSS files, but every second counts when you are trying to maintain a sense of flow.
Generally I think inline CSS only affects readability when there is a lot of it. There have certainly been times when I have overdone inline CSS, and this is one area where I do feel I could improve. What I plan to start doing, is using <style> tags more, to separate css from html without having to flick between css and html files. In terms of general code prettiness, I actually find the idea of a css file containing thousands of classes, many of which only contain a single attribute, rather ugly. I also feel that adding CSS to the <style> tags on a page maintains a sense of cohesion, with the elements and their styles being stored in the same file.
HTML5 allows <style> tags to be placed outside of the <head> tag, allowing us to add <style> tags to partial views which contain no <head> tag. This is a feature I have yet to take advantage of, but plan to start doing so.
In other words, you need to consider your individual circumstances and requirements. I tend to lean away from premature optimization, favouring readability, speed of development, and good design as guiding principles. If performance is an issue, it needs to be defined as such, with specific requirements for how quickly a page needs to load, and under what circumstances. If a site is failing to meet performance requirements, then I would happily look at the effects of inlining versus external files.
I am keen not to sound like I am saying that inline CSS is good, and external CSS is bad. My point is that under certain circumstances, inline CSS is acceptable, in my opinion. What is more important than my opinion however, at least as far as inline CSS is concerned, is the opinion of my employers and team-mates. Consistency is good, therefore if I were to find myself in a team where inline CSS is prohibited, I would happily adjust my approach. But I have never been on a team like this.
I do plan to start using <style> tags more, as this seems like something of a compromise. It will probably make html files more readable, without the ugliness of an enormous external CSS file. An additional benefit of this I guess is that if I ever did decide, for some reason (e.g. performance), to move my CSS into an external file, it would be much easier to do so from <style> tags.
There is something to be said for reading the thoughts of more intelligent and better programmers, and basically doing what they do, particularly early on in our careers. However I feel it is more important that we critically evaluate what we read, and decide for ourselves the best approach. The rule of thumb I follow is to be generally weary of rules of thumb.