CSS and inflexible CMS’s
January 21, 2008
I don’t write about CSS as much as I’d like to. I spend a lot of time working with them on an advanced level, however, both in my day job and in any side projects.
I spent a few minutes looking around on Google for issues that arise when designers need to work with and use CSS within the confines of a CMS that does not allow access to things inside the head
of the document. Apparently, this is not a rare issue, so I’d like to post a few solutions that, while they are not ideal, do work.
Disclaimer: these options do not validate. The only valid way to include a CSS is inside the head
of the document
Option One
Use inline styles. This method is, unfortunately, still the most common way of doing this. A designer might have the following code in place:
[prism key=”option-1-a” language=”markup”]
If the div is, for example, defined with its ID or class as a very small div floated to the right, but it needs to be a very large div floated to the left, a designer might do this:
[prism key=”option-1-b” language=”markup”]
Option 2
Option 2 allows the designer to access the head
of the document through JavaScript. There are a number of techniques for doing this, but they have significant issues.
Mainly, this breaks the separation between content, style, and behavior that provides much of the underlying theory of why a designer would want to use CSS in the first place. In addition to this, it breaks the accessibility of the page. Anything that doesn’t have to be done with JavaScript, shouldn’t be done with JavaScript.
Option 3
This is the option I spend a lot of time using when working in this situation. A designer might have the following scenario:
[prism key=”option-2-a” language=”markup”]
[prism key=”option-2-b” language=”markup”]
The benefit of this is that it works in all major browsers and on all major platforms and, at least, mobile devices (this statement counts Linux and the iPhone as major platforms, for what it’s worth). Also, of course, there is the benefit that the given stylesheet can be called throughout the site, which inline styles do not allow.
There are a few downsides to this technique. Browsers, for one, have to work a bit harder to do this kind of thing. When they encounter style information outside the head
, whether it’s in an external file or in the page, they have to break their normal flow of rendering content, and thus this causes pages to be slower. This slowdown, however, is not usually noticeable.
Of course, because browsers have to work harder to do this, and because it does not validate, it is possible (though it is highly unlikely) that future versions may not support this kind of functionality.