Structure != Semantics != Style

I have a relatively purist approach to development and, like many developers, I have to be mindful that this can lead to the mindset of process for process’ sake. However, I also think that having a strict set of ideals can also lead to challenging your approach during development; thinking, can I make this closer to my own “best practice”.

The reason I start with this is that I know that a lot of developers will disagree with what I’m about to say, and that’s cool. This is an article to explain the way that I approach front-end web development and I’m not endorsing it as the way I think everyone should approach front-end dev, or suggesting it is in any way “better” than any other approach, and I’d be really interested to debate the pros and cons, and explore approaches that other developers find works for them.

I’m also sure that many people have written far better articles on this topic than me but, this is for me; a chance to organise my thoughts on my approach and, perhaps whilst I rationalise these ideas in order to present them here, I may be able to refine and adapt these ideas, too.

When I begin putting together front end code, I’m very careful to think about structure, semantics, and style separately. Of course, there are places where these concepts naturally overlap and so I’m not saying that they do not affect one another, but the consideration of each should be isolated to within it’s own concerns.

At a very high level:

Structure is the meaningless “boxes” that organise content on a page into a visually coherent layout.

Semantics is the meaningful tags and attributes which describe what each bit of content is about. These organise the content flow.

Style is how each of the elements appears visually within the structure, and may or may not have any bearing on the Semantics.

I normally start with the semantics stage: describing what each piece of information is. This is all about the choice of tags used, along with any other considerations for things like accessibility. But starting like this, I can make sure that the content reads well when the style is removed.

<section>
<h2>News stories</h2>
<ul>
<li>
<a href="/news/news-story-name" aria-labelledby="news-card-1">
<h3 id="news-card-1">News story title</h3>
<img src="https://unsplash.it/300/200" alt="A description of the image">
<p>This is a brief description of the news story</p>
</a>
</li>
...
</ul>
</section>

Then I start to fill in the structural elements. I tend to use a slight modification of the BEM approach (inspired by Harry Robert’s Namespaced BEM article) so that structural classes are easily distinguishable from block classes. These don’t have to be mutually exclusive, though, and so an element can contain both a structural and a block class, if it makes sense and cuts down on the tag cruft.

<section class="s-content-section">
<h2>News stories</h2>
<ul class="s-card-collection">
<li>
<a href="/news/news-story-name" aria-labelledby="news-card-1">
<h3 id="news-card-1">News story title</h3>
<img src="https://unsplash.it/300/200" alt="A description of the image">
<p>This is a brief description of the news story</p>
</a>
</li>
...
</ul>
</section>

In this case s-content-section is a standard content block which is used throughout the site. It sets a standard width, a standard set of margins, and centres the block on the page.

The s-card-collection is a flex box object which is used throughout the site to hold collections of card objects in rows. It is just a framework; it doesn’t dictate the width of the cards it contains, leaving that to the cards themselves.

These structural classes are two of around ten that I would expect to use in different scenarios: s-content-oversize, s-content-fullwidth, etc. In combination, these provide a coherent and standardised framework within which the content of the site sits.

And then, finally, we get to the actual styling.

<section class="s-content-section">
<h2 class="section-title">News stories</h2>
<ul class="s-card-collection">
<li class="news-card">
<a href="/news/news-story-name" aria-labelledby="news-card-1">
<h3 id="news-card-1" class="news-card__title">News story title</h3>
<img src="https://unsplash.it/300/200" alt="A description of the image" class="news-card__image">
<p class="news-card__precis">This is a brief description of the news story</p>
</a>
</li>
...
</ul>
</section>

This last stage should ensure that the style that a class brings to a tag, and the tag itself, should be as divorced as possible. So, I should be able to swap the h3 for a div and, so long as the same class is used, there should be no visual difference. The tag should not dictate the style of the element.

We had a recent example of this in a project where a search page was displayed. At the top, in large letters was the title “Search results” and then, underneath, in smaller letters, was the subtitle “34 instances of <search term> have been found”.

In terms of the styling of the site, the “Search results” text was styled in a manner normally reserved for an <h1> but it actually felt that the title of the page should be the “34 instances…” text as it closer represented the content of the page.

Now, you could argue that this is a fault with the design, and that may be true. However, it reinforced to me the importance of not tying a style to a tag.

You can see a CodePen of the code above, along with some basic styling, which may help illustrate my approach a little better: https://codepen.io/petewj/pen/zdNrXr

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.