Reading Time: 5 minutes

I had a discussion recently about whether to put CSS into Tridion as multimedia components or code components, and it triggered a really fun discussion. We talked about all of our different strategies and use-cases for managing the CSS in SDL Tridion, and it seems like something that other folks may ask about in the future. So what I’d like to do here is summarize my thoughts and experiences on front-end architecture, and what implementation options you have in Tridion.

A quick summary of CSS architecture

I’ve expanded on general CSS architecture ideas with an older post entitled The Layers of Design. The big idea from that is that CSS should be written, and split, into three big pieces:

• Brand
• Layout
• Content Flow (Components)

I’ve also discussed exactly one method of delivering this CSS architecture in another post, creatively titled, Architecting the CSS in a Tridion Implementation. I’ve changed a bit since that post, and I’ve had a few different experiences managing CSS. So now I’d like to build on the principle of CSS architecture and discuss a variety of implementation options.

Option 1: Keep the CSS and JS out of Tridion

I’m not a huge fan of this approach, but I think there are cases where this is your best option.

CSS and JS aren’t served from the same place

It’s not uncommon that a big client might use a Content Distribution Network (CDN) to deliver static assets. Limitations in the concurrent connections to a single domain, pre-caching, distributed data centers, and even version control can be reasons why the CSS doesn’t go to the same place as the content.

When content is published to a different place than the CSS and JavaScript, rather than fiddling with multiple publication targets, it might be easier to just leave the front-end code out of Tridion entirely.

Though I have not had to configure Tridion to publish to different locations for different schema types, my understanding is that this is definitely possible. Issues with publishing targets may be used as an excuse, rather than a reason. But an impending deadline might be a good reason to keep the front-end out of Tridion.

OPP: Other People’s Problems

As a front-end guy who dabbles in Tridion, this has never been the case for me. But I know that I am the exception, rather than the rule; many in the Tridion community have little reason to touch the CSS or JavaScript because of how the client has organized itself.

Some organizations draw a very clear line between the front-end and the back-end. One team writes the HTML, CSS, and JavaScript. Another team makes sure the CMS works and delivers content. In these cases, the front-end team may have its own development life cycle:

• A different QA team tests the development
• Requirements come from different business units
• Release schedules are different

When the organization treats CSS differently from CS, and JavaScript differently from Java, then it may be best to heed the warning, and not cross streams.

Option 2: Keep the CSS and JS in Tridion

If you don’t have separate-but-equal teams developing front-end and back-end code, then it’s entirely possible that the CSS and JS will end up in Tridion. In this case, you have two options: use Code Components or use Multimedia Components.

When you go this route, I absolutely recommending that you split apart the CSS into logical pieces. Give it an architecture, rather than dropping a single blob into Tridion. After all, you wouldn’t just put a whole page in Tridion, would you?

2a: Code Components for CSS and JS

When I say “code component”, what I mean is a schema with a plain text field. At the bare minimum, it has one field, for storing the code.

Debugging is easier

Some clients did not have a “static prototyping” phase in their development cycles. This meant that when we got an enhancement or a change request, we didn’t have an opportunity to first develop the front-end in a non-Tridion environment. In this case, we’re modifying the component template and the corresponding CSS at the same time. So being able to open up a component and change a few lines of CSS was helpful, and made for faster debugging.

It’s very easy to diagnose and resolve an IE bug when you can access the code directly inside of Tridion.

Development can move quicker

It’s great being able to add a few lines of CSS or JS to the top or bottom of an existing component. Not only that, you can add new components when necessary. So on top of debugging, creating new blocks of CSS is a huge win. Sometimes, a responsive design could be as easy as adding a few media query break points in the appropriate place in a text field.

Death by Copy

The primary means of moving large blocks of code from a prototype becomes ctrl + c, ctrl + v. And, from experience, there’s many ways to mess that up.

• You can paste code in the wrong component
• You can paste above or below existing code
• You can miss copying an ending } or ;

And when I say, “you can”, what I really mean is, “I have”.

Murder by !important

Lately I’ve been kind of on a tear about !important and how awful it really is, pretty much always. It’s entirely possible that you get called in to fix someone else’s CSS. Rather than spend 16 hours rewriting the CSS so that it doesn’t use IDs, or just organizing selectors in a sensible fashion, you get right in there and throw down an !important.

And then I go nuts, and people get hurt.

Flame war of formatting

One thing that really sucks is editing code in Tridion. It doesn’t format code. Now, you can get yourself a fancy code mirror extension to make TBBs prettier. But that ain’t gonna work for schemas out of the box.

Are you going to spend the time to write a proper formatting GUI extension? No?
Which is better for indentation? Tabs or spaces?
Why does it matter, when Tridion doesn’t care, anyway?

The benefit of quickly debugging and developing is completely lost when the CSS becomes unreadable after 2 days.

If you want to have nicely formatted code, you’ll have to keep that code offline, in some sort of editor, and make every single change to that code offline. And then you’ll need to copy and paste it into Tridion. Rather than editing it directly. Which segues perfectly into our final option…

2b: Multimedia Components for CSS and JS

You have flavors within this approach:

1. Maintain your architecture in Tridion; multiple components for each
2. Maintain your architecture outside of Tridion

I prefer to maintain the architecture within Tridion. I like the idea of the presentation broken into small pieces because then it can be reused by other areas of the site. Having a “brand” component is invaluable when you need to spin up a microsite.

Syndicated Design ™ can be your friend if you keep the CSS and JS broken up.

No death by copy

A big win in the multimedia component approach is that you reduce the “transcription errors” to zero. The code is the same as it was in the repo, and it always will be.

Automatable

Since you don’t have to deal with manually copying and pasting code, you can take advantage of Tridion’s ability to take uploads via WebDav. And that means that a grunt.js task or a shell script can take your files from your repository and push them directly into Tridion.

Debugging becomes a pain

This reads just like I’ve said previously. Especially in a very agile development phase, it can kind of be a pain to open up the file in an editor. Save it. Commit the code. Then upload the component into Tridion. Just so you can debug.

But, that pain of debugging can be resolved by creating a “static prototype” step in your development process. Develop and do your QA in a non-Tridion environment, first.

In summary

You have three major options in managing the front-end with Tridion: Not at all, with code components, with multimedia components. There’s Pros and Cons to each approach which vary widely with the organization and the architecture that’s already in place. Pick the approach that works best for the users. And remember that you’re a developer for end-users of a website, and middle-users of a content management system.