The Importance of Separating Structure from Style

Gabriel Zanzotti
Wolox
Published in
4 min readOct 5, 2018

--

When I started working in Front-End I asked myself many times, “When should I use an H4 or an H5?”, “Should I use a div? A span? Or is it better to keep using heading tags?”. In the end, what the users will see is what the style says and not what the element represents; I could use a span and style it to look exactly the same as the biggest headline in my page so, how does this really work?.

At this point, I started questioning myself and came to the conclusion that HTML elements are useful to guide the programmer when designing the structure of a web page and are also useful to the user when they are not able to see the styles of the page correctly. None of these advantages are related to styling, and this is because your styles shouldn’t be related to HTML elements. There’s a link between the HTML and the CSS and it is through classes (yes, you could use IDs too but they might lead to specificity problems).

Style classes, not tags

If you only style your elements using classes, something that’s an h2 today can be an h4 tomorrow if more important fields are added and the user would be none the wiser. Also, by avoiding the use of IDs you can prevent specificity issues and limit the style overriding to class nesting.

As you may know, each HTML element has a style defined by the browser which may affect the way we want an element to be displayed. To avoid this, the use of a CSS reset file is very important. At Wolox we created our own reset file based on Eric Mayer’s “reset.css” and made every element look alike. We call it “the equalizer” and by using it you’ll need to redefine how all your elements look. Buttons won’t have that ugly gray background and border and anchors won’t be underlined or look blue or purple. This allows us to change HTML tags without affecting how elements are displayed visually. It also removes the styling from some tags like “strong” or “italic”. Although we encourage developers to use the tag “strong” to make emphasis on a statement, since it helps users that depend on the page reader, we removed the bold styling because this shouldn’t be directly related on a bolder font. Perhaps what I really want is to make the text bigger or in another color and that should be done through classes in the CSS.

Choosing between CSS or HTML

It’s also very important to understand what goes in the HTML and what goes in the CSS. A common question could be: “should I use a background image or an image tag?” The answer to that question is directly related to the question: “is the image something aesthetic?” If it’s something aesthetic you should add it in the CSS, either by using a background image or a pseudo-element like ::before or ::after. If it’s part of the content, like the cover of a book in a book’s list, it should be added in the HTML.

Another case would be the use of “br” tags. Most of the time they are used to separate things into different rows. This shouldn’t be done that way because what you are trying to achieve in that case could be done by using display block and leaving a margin to separate each block.

And another bad practice that I sometimes encounter is the use of empty HTML tags to add aesthetic lines or transparent overlays or just an image that needs to be added using a background. For this cases, almost every time a pseudo-element can be used instead of polluting the HTML with unnecessary tags.

Simplify your HTML

To conclude, I’d like to suggest you check your HTML looking for extra tags. Having a tag that contains only 1 element inside of it is most of the time an error. Almost every time this happens you can merge those two elements and their CSS styles and simplify the nesting in your HTML.

Well, that’s the end for now. Thanks for reading, I hope this could help you for the next time you start a page. If you have any suggestion or opinion we can keep in touch and exchange views on it.

--

--

Gabriel Zanzotti
Wolox

Senior Frontend Engineer at Hygraph & Co-Host at the Frontend Army podcast