Nearly each and every project I work on professionally is heavily integrated with a custom Content Management System that has been developed by programmers on the team for many years. What’s great about having a custom built CMS is that I can personally talk to the developers regarding a feature request, and that feature can be added within the next few days, or even by that afternoon. Content Management Systems are a great thing in my opinion, but like everything, they’ve got their limits.
Limitations range greatly from one CMS to another, some have embraced Web standards and produce semantically rich and valid markup, while others have put standards on the back burner. One issue I’ve had some reoccurring trouble with in the past is the combination of a CMS with managed images that are part of the design as opposed to having informational value. To be more clear, sometimes a client will request to have control over a piece of stock imagery represented on any number of pages. This becomes an issue because traditionally, when images are uploaded in context, they’re treated as having informational value and included using an img tag with a descriptive alt attribute.
So what’s the problem with inline images?
There’s nothing at all wrong with inline images — as long as it is applicable that they be represented in the markup as an inline image. When images are included in the markup, they should have informational value. Images with the sole purpose of adding to the design can be better included via your style sheet as to preserve the separation of style and content.
Inline images definitely have their place on the Web, but it is a far different position than images used for the site design purposes only. Those images should be included via the associated style sheets, defined either by hand, or through the theme management of the CMS. Keeping that in mind, there can be a time when images that should be defined using CSS are instead included via the CMS front end.
What can be done about the situation?
The trouble with trying to give a client control over design-oriented images is when it comes to referencing the dynamic content. With inline images, it’s easy in that the image URL can be pulled from the back end and used in any way you please. It becomes a bit harder when a style sheet needs to be updated with a change in URL. I’ve read an article or two about using PHP (or any other server side language) to generate style sheets on the fly, but including PHP echos in CSS doesn’t sit well with me. It also restricts that style sheet to the language in which it has been written, therefore forcing an otherwise unnecessary update should the style sheet be written strictly in CSS.
Another way to go about things would be to have the CMS handle a number of style sheets the can be, as was an original intention, cascaded upon one another. These files could be generated, taking into consideration any images that are managed via the CMS, and then included with the site CSS.
A more abstract method that could be possible is using a static URL in your style sheet that references the dynamic image, but instead of updating the URL, the CMS will update the image file itself. Effectively the URL remains the same, but the target image itself can be updated by the client via the CMS.
What’s this got to do with inline styles?
While any of the above can be considered a solution, not everybody has open access to the inner workings of their CMS. Sometimes you’re literally stuck with an image URL and that’s all you get. At this point, is it better to include the image as a background-image via inline CSS? Is it acceptable to ignore document semantics and include the image inline?
In my personal opinion, I think I’d opt to go with using inline CSS and a background-image as opposed to sacrificing semantics. While inline CSS is considered difficult to manage, in this case the CMS is doing the management for you. While the end result isn’t completely ideal, I have to consider it more appropriate than using an inline image.
Is this an issue you’ve ever had to worry about before? Do you really consider it an issue at all?
Comments
For me this a case of balancing common sense and pure separation of structure and presentation. Lots of background images can result in an ugly load process and whilst it is correct in the purest sense clients just don’t stand for it.
Personally I have never had a massive problem with inline images if meaningful semantics are attached.
Which one causes you more grief – inline CSS or sacrificing semantics? I’d drop the one that causes more pain and deal with the consequences if I were you. Both are messy but one or the other is unavoidable!
I would go with the method to put static URLs into the Stylsheet pointing to a PHP script which handles the image-switch!
Another way I used in my framework is to use a stylesheet like a template with placeholders and parse this template using PHP. That way I could easily change an image on the fly 🙂 And that way helps getting around with mod rewrite 🙂
I worked regularly on a site whose authors used regularly to use in order to adjust letter spacing and font sizing so that
headlines of news stories would always take up equal horizontal room.
Obviously, each headline was different so it would be barbaric to give
each news headline an id and have an ever-expanding stylesheet.
It was the content editors who played with the styles, and swapped
synonyms and different phrases into the content until they achieved
the desired effect, so there was no possibility of doing this through
scripting.
I totally agree with you on this although I am the first to admit going down the inline style route can be a slippery slope. I am extremely guilty of putting in way too many inline style rules throughout my site – just because it was easier than re-organizing facets of my CSS file.