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:
- 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.
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
- A different QA team tests the development
- Requirements come from different business units
- Release schedules are different
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
And when I say, “you can”, what I really mean is, “I have”.
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
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:
- Maintain your architecture in Tridion; multiple components for each
- 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.
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.
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.