Dear Ms. FEWD,
I have a website being managed in a CMS. I’ve read your past articles about how you should separate content from presentation. But, what if the presentation is managed as content? For instance, if the Content Author needed to change background images, colors, or even font treatments, when would you create classes vs utilizing inline styles?
You down with CMP? (Yeah, you know me)
When presentation is managed as content, we have three real options:
- Create a class (within an External Style Sheet)
- Inline styles
- Style element, also known as an Internal Style Sheet
Create a Class (within an External Style Sheet)
Creating classes is a great option for theming. It still splits up the content and presentation, while giving the Content Author options for choosing the theme based on what they need. For instance, the following example shows a header and paragraph, where the header is themed by use of the theme-alpha, theme-beta, and theme-gamma parent classes:
The naming convention allows the classes to make sense even if the colors change. If you have entire pages that are themed, and not just specific components, it may make sense to put the theme class on the body element, instead of the component’s parent section element shown in the example. For instance, in the case that you cited about different font treatments, having different body classes for each font theme, and then the font(s) changing globally based on those body classes will probably be your best bet.
It’s also worth mentioning that you could separate theming out by style sheets. You’d have one external global style sheet that takes care of default and global styles, and then theme-alpha, theme-beta, and theme-gamma external style sheets that would be attached as needed to their pages or structure groups within the CMS. This is advisable if there are massive differences between the themed layouts to keep the size of your served stylesheets down.
I can hear the gasps from here. “But, Ms. FEWD!” you exclaim. “Inline styles are EVIL! BURN THEM WITH FIRE!”
Yes, inline styles are terrible for most of your development work. We need to be mindful of keeping our CSS DRY (Do not Repeat Yourself) and easily maintainable. This means, if the style is not managed in the CMS, put it in your style sheet. This will allow you to only update the styling in one spot (vs. changing that inline style on every element it occurs) if the design changes.
But what if it’s a content managed image, and one that does need to be treated as a background-image? One use-case would be when the image needs to expand or shrink in height with the amount of copy. If the background-image is content managed, the Content Author is responsible for updating and managing it, and therefore is safe to put in the HTML style attribute. All other styling would remain in the style sheet.
Please review the following example:
In the first block of HTML, we have an example of a content managed image, using the image element. As developers within a CMS, we usually want to default putting a content managed image in an image or picture element, in order to separate content from presentation. You will see a block of text, positioned absolute to the relative parent container, over the image element. I have overflow:hidden around the parent container, so that when the user is in the smallest end of the viewport, it won’t mess up the rest of the layout, as the copy may have more height than the image itself. You can see that, when the viewport is large, there is more than enough image, but a gap shows in between the end of the copy and the end of the image.
In the second block of HTML, we have a content managed background image. The style attribute is implemented for only the background-image, and solely because it is content managed presentation. The rest of the styling goes in the external style sheet, so that if we ever need to update the layout for these pieces, we still do the update in one spot within the CSS. This solution will prevent large spaces being shown between the end of the copy and the end of an image, as occurs with text that is positioned absolutely over an HTML image element, and the image will grow and shrink with the copy height. Please make sure to have more abstract art within the image, one that doesn’t change meaning if cropped to the text. For example, if you’re using an image that contained a person or people, you may end up with the image cropped in an undesirable way (only torsos showing), because the copy doesn’t have enough height to show the top and bottom of your image.
If the Content Author enters a lot of copy into this space, they could run out of image height of the image is too small. This can be remedied by the Content Author uploading a new image, with more height (if the design allows), to the component to accommodate the larger text. Remember: an image has a maximum height and width. If you increase the height and width from the original image, or change the image size ratio, the image will blur or distort.
Ultimately, deciding whether your image needs to go in an image/picture element or within the style attribute depends on the design’s and client’s needs.
Don’t know whether you should use image or picture, or what the difference is? Check out this previous Ms. FEWD article on responsive images.
Another use case in which you may want to employ inline styles, would be when you need to implement author controlled styles (think: color picker) within the component. The Content Author has decided they need to be able to style the title in each repeatable promo block, in any color they choose. An internal or external stylesheet wouldn’t fit well here, because there may be multiple components of the same type on the page, and styling on an element or class would target all with the same color. Both present the same issue – there would simply be too much code to support every color. So, what’s a Dev supposed to do? One option is to give your Content Author a Rich Text Field (RTF), and let them put inline styles on whatever they want. However, this is not a perfect solution. We shouldn’t assume our Content Authors can code in HTML, and other styles could get introduced that may make the site lose that cohesive feeling. The better option is to create an inline style for that author controlled styling of the element, in order to allow any color from the color picker to be fed into this piece and prevent other pieces in the promo block from mistakenly getting styled.
Style Element, also known as an Internal Style Sheet
On occasion, you may have content managed presentation that will always be there, and you need CSS on the template side to feed the component data into. You can go about this in one of two ways: by putting it into an inline style or within a style element. However, there needs to be some thought put into this. If you have repeating blocks of content that all have different content managed background images, you wouldn’t want to define those in an internal style sheet under one class, so putting the image within an inline style is better in this case. If you have the one non-repeating global component that shows up on every page, like a content managed hero banner or global rail that contains a content managed background image, putting this in an internal style sheet is acceptable. Likewise, if you have a theme component option for your Content Author, where you need to feed their choices into a global stylesheet, the style element may be a good option.
If the reasoning is thought out well and your code will remain DRY, inline styles and internal style sheets aren’t the terrible practice that they’re made out to be, even if they seem naughty by nature. We need to first make sure there are no better options. We also need to guarantee that the solution we choose will keep the code DRY – if you find yourself declaring the same thing over and over, look at the solution and retool it. Then, we need to ensure that implementing an internal style sheet or inline style is not going to create a maintenance nightmare. They should be implemented only to solve an issue, not create one.
Do you have a front end development question? Ms. FEWD has answers. Email her at MsFEWD@tahzoo.com.