by

Two Front-end Tidbits for Tridion Guys

As I’ve mentioned previously, I recently left Tahzoo and started working at a new company called Content Bloom. Last week was Content Bloom’s global training summit, held in Halifax, Nova Scotia, Canada (if that’s a real place). Everyone at the company presented on a topic; it’s a chance for us to all teach each other. I was nominated to speak on Front-end, but with only a 30-minute window, I had to be very focused on what I was going to teach on. Very focused. So I picked only two topics— and I only went over by an hour.

Following along at home

This is a recap of the HTML-based presentation which I gave.It’s based off of Google’s 2012 HTML-based slidedeck. It’s the same thing I used at the Tridion Developer Summit in Amsterdam — but mashed up with Grunt so that I have more time for content and less for code. If you want to use it, I left it for you over on Github.

Front-end: How to Suck Less and Win More

I could do a five-day lecture on front-end architecture and the CMS. But what can I do in 30 minutes ‽ I needed to teach some top-notch Tridionnauts some tech that they didn’t know. So I settled on two topics that were near and dear to my heart. Then I decided to teach one topic as a thing not to do and another topic as a thing to do. i.e.: sucking less, winning more.

Sucking Less in the Cascade

There’s a [myriad , plethora, multitude] of topics that could fall in the “suck less” category, but I wanted to touch on a topic that’s probably relevant specifically to CMS developers. Tridion guys, in particular, are usually handed someone else’s front-end code and told to drop it in to a Tridion implementation somehow. Even though they didn’t write the CSS, they’re responsible when it fails to do its job.

As a result of drop-kicking code, many Tridionnauts shoot from the hip with the !important keyword. And that’s a bad approach that usually comes from not understanding the C in CSS.

Know the Cascades

According to the specifications, there are, in fact, three cascades that occur:

  • User Agent
  • Author
  • User

We, as developers, are involved in the middle cascade.

The Order of Cascades

The specifications also elucidate the order of the cascades.

  1. The User Agent cascade is the browser interpreting its own, internal styles; these are the styles that we’re overwriting with a “reset” or a “normalizer”
  2. The Author cascade is our stylesheet being interpreted
  3. The User cascade is the browser interpreting any styles the end-user has; not especially common, except for users that may be visually impaired

!important in the Cascade

It’s a good time to point out that the browser also sorts declarations within these cascades. First for normal declarations, and again for !important declarations:

  1. user agent declarations
  2. user normal declarations
  3. author normal declarations
  4. author important declarations
  5. user important declarations

Take note that the order is user agent, user, author normal, author important, user important. So it’s the browser first, then the user’s styles, then ours, and finally, the user’s !important styles. So it’s not so much of a rock-paper-scissors as it is a rock-paper-scissors-lizards-spock.

The key thing we extract here is that !important wasn’t meant for us. It was meant for the end-user who ultimately may have additional accessibility needs—beyond what we’ve accounted for.

Don’t start a Nuclear War

What I outlined in the presentation is that !important is a nuclear option. It ruins friendships, wreaks havoc on our lives, and worst of all, makes the end result workable— but less sustainable. We ran through examples of how to avoid using !important that I’ve touched on in another blog post I wrote: The End of !important.

Winning More

The next thing we talked about was selectors and specificities. While it is often the case that finished code is handed-off to us, there are still plenty of times where CMS developers need to write CSS, too. Just as .NET and Java people have an understanding of how their code is compiled (¿right?), CSS people know how the browser reads their code.

Reading a Selector

Almost a year ago, I wrote The Selector and Grammar where I explained the parts of a selector and how to read it. The big takeaway is that a selector is read from right-to-left. In jQuery, our selectors are read left-to-right, so those developers coming from a programming background may think that writing a longer selector is better — but it isn’t.

In CSS, the last element in the selector is the one that gets the styles. As Rob Morrow pointed out in the presentation, this is probably why there are serious challenges with getting a parent selector into a CSS specification.

Smaller is Faster

Since the right-most selector is the one getting the styles, it pays to write shorter selectors. Google points out the perils of chaining an element to an Id in their own recommendations. Not only that, the right-to-left issue means that reducing the number of general, or specific, descendant selectors will improve performance, too.

IDs aren’t necessarily your friend

While it is true that an unchained ID is faster, it’s not considered best-practice these days. In fact, styling on IDs is a slap in the face of Object-Oriented CSS— and I hear that these programmer-types are all about object-oriented.

Not only are styles on IDs sketchy, they’re a slippery slope. You’ll try one now. Eventually you’ll be using IDs all the time. You’ll swear that you’ll be casual with it, but you’re lying, buddy. Eventually, you’ll end up in a ditch in Tijuana with an itch that you can only scratch with !important.

We talked through some rad and crazy techniques that I outlined in The End of !important. Even if all you have is an ID, you can still treat that ID as a class selector and keep specificity low. And with a low specificity, everyone’s your friend.

Classes make everyone happy

Classes are a great starting point in writing CSS. It’s best to shoot for needing only one class to style anything, but if you don’t go beyond using two classes, I don’t think you’ll hurt anyone’s feelings. Writing a more-specific classname, instead of an ID, leaves plenty of room for reusability and scalability. Not only that, BEM is a methodology that makes it easy to keep that specificity super low. Not only is BEM good for specificity, it plays nicely with Tridion, too.

In summary

Give me a chance to tell the top Tridion Techs in the business only two things about front-end, and I’ll say this:

  1. Don’t use !important because it makes code, and friendships, unsustainable
  2. Shorter selectors are better because it improves performance

I learned a heckuva lot at the Content Bloom Global Training Summit— if I tried to write about everything I learned there, I wouldn’t finish before the next one. But maybe I’ll talk about what a front-end guy learned about core services in the next week or so.