Front-end for the Middle: Coding and CMSing for Relationships

This is part three of a series called “Front-end for the Middle”. Honestly, I didn’t mean to write three posts. But when one post is over 2,000 words without being finished, it’s time to get slicing.

Previously, we’ve talked about directing a front-end developer’s focus away from design, and on to content. And we’ve also discussed semantics and schemas. Now I want to zero in on the impact that the new HTML5 semantic elements has on how individual pieces of content relate to one another.

HTML5 didn’t introduce semantics, it just improved it. So, while much of what I mentioned in prior posts has been with us for a while, what was missing was a way to group collections of content together in a meaningful way. And this is incredibly important to how a front-end developer does her job well. HTML5 in particular introduced “sectioning elements” which allow us to group individual pieces of content together in a meaningful way:

A complete and self-contained piece of content. In Tridion, think of this as a schema.
A thematic grouping of content, where everything inside of it is related. In Tridion, think of this as a region, or a component that links to other components
Obviously for navigation. But, it could be navigation to somewhere on the site, or somewhere on the page. In Tridion, think of a link list.
Content that is tangentially related to the content in its parent section. In tridion, think of this as a schema that’s a promo. Or content delivered dynamically from smart target
Introductory content for its parent section.
Closing information for its parent section.
All of the content that is the primary purpose for the page’s existence counts as the <main>. In Tridion, this would be your page template goodness.
Headings. You can now have multiple <h1>s on a page now. In fact, you get one per sectioning element.

HTML4, 3, 2, and heck, even 1, offered some amount of semantic support for the content. HTML5 introduces this idea that you can mark up a block of content, and establish a relationship between that block, and other blocks of content on the page. This is is new, and it’s kind of a big deal.

If you’re curious to know when to use any of these semantic elements, check out this nifty flowchart.

Didn’t we already talk about head and feet

We talked about <header>, <footer>, <article>, and <aside> previously, within the context of authoring a single piece of content.

The first big idea was that your <article> is just any piece of self-contained, syndicated content. And that <article>, could, itself, contain a <header>, <footer>, and <aside>.

But don’t think that <header> happens only within the context of a piece of content. It can actually happen once per section — and the <article> is only one kind of section. So you can put the <header> at the top of your page, in each <section>, and as you know, in each <article>.

So think about this when you have a collection of products. Your list of blog posts on ECL providers, collection of power tools, or gallery of Warby Parker eye glasses could all go in a section, and they could be introduced with a <header> and concluded with a <footer>. So, in this context, your <header> and <footer> could very well be components!

In fact, most “interior pages” on a site, such as this Starbucks page will be best served by wrapping their banner image and title in a <header> for a <section>

Relational Content

It’s very easy to see how every single component in Tridion becomes an <article> now. But revisit, the definition of a <section>, and let it settle it in.

Front-end developers delight at the use of these elements, because it eliminates div-itis, that horrible disease where everything is wrapped in a <div> and you lose track of where anything is on the page. We love the semantic elements because it helps reduce <div>s, thus making our code easier to read. But, there’s a danger in our newfound semantic freedom…

Semantic freedom could have CMS implications

While front end devs are being more semantic, we’re also establishing relationships between blocks of content. In fact, we’re picking and choosing our semantic elements very carefully and thoughtfully. We visit the flowchart, check out Html5 Doctor, consult specifications, and debate with each other. I have had two hour discussions on the merits of <aside> vs. <footer> before; we take our semantics very seriously.

The implication is that we are establishing how content authors are building pages.

That’s right.


Front-end developers.

We are choosing semantic elements that create a relationship between two pieces of content, and we are expecting that content authors will somehow form the same relationship. As a result, we expect the CMS to understand this, too.

And, let me tell you something very, very, very important:

We can get it wrong.

Super wrong.

Compare and Contrast bad semantic groupings

Let’s do an exercise in semantic grouping:
Example 1:

Taken from:
Taken from:

Now, don’t bother looking at the markup for that page, because it’s not marked up semantically at all. The image is just an example of how we could get our groupings very wrong. In truth, a lot of the content blocks on that page is related to each other. But exactly how each piece of content is related is not something that the front-end developer should decide alone.

In truth, that page could be marked up a little more like example 2:

Taken from
Taken from

Take the time to compare the two images, and how containers have been pieced together.


  • The first example puts the center column in a <section>, containing two <article>s
  • second example has only one <article>


  • Example one says that the description below the image has nothing to do with the image. at all
  • Example two says that everything on the page is related


  • The first example puts the second column in a <section>, containing <aside>s, but no <article>s
  • the second example puts the second column in <div>s


  • Example one says that there’s a section with a bunch of content that isn’t related to anything
  • Example two says that the stuff in the second column is totally related to the stuff in the first


  • The first example puts the description of roast in a <div>
  • the second example puts the description of roast in a <figure>


  • Example one says that the description of a roast matters to… nothing other than that right column
  • Example two says that the user is learning more about the content, because of the roast information, but if the user didn’t know anything about it, life would be fine


  • The first example puts the image in a <figure>
  • the second example puts the image in a <div>


  • Example one says that the viewer could do without this giant picture of the product.
  • Example two says that the viewer would find this giant picture of the product crucial to understanding the content

Example one is a great case of how we could ruin content with semantic elements. Example two is how we can connect everything together. The power to do this in in the hands of the front-end dev.

This is not good.

We could easily produce a two column page template that worked perfectly in laying out this product page in semantic HTML, while simultaneously degrading the quality of the content.



Stop us.

The big idea here

Front end developers are probably going to just fine writing semantic markup — for a piece of content. We can drive conversations about meaningful schema design and component template development.

But once it comes to putting the page together, someone, anyone, should stop us. Or at least question us. A business analyst or an information architect should step in, and tell us how this all fits together. We can see the little picture of lots of pieces of content blocks. But putting content blocks together should be a partnership between front-end, and the middle.