- About the author
- Jonathan Christopher
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
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.
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.
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?