By Harry Roberts
Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.
Written by Harry Roberts on CSS Wizardry.
For a while now, sensible naming conventions and semantics have been confused.
Things such as class="left"
or class="clear"
have been deemed insemantic,
whereas in reality, semantics really doesn’t stretch that far… Let me illustrate
with some code examples:
The following code is just plain wrong, it’s insemantic, using the wrong elements for the wrong job:
<div class="nav-link"><a href="/">Home</a></div>
<div class="nav-link"><a href="/about/">About</a></div>
<div class="page-title">About</div>
<div>This is some page text about some stuff...</div>
This code is perfectly semantic, it just uses some silly classes:
<div class="border">
<h2 class="red">This is a heading</h2>
</div>
…and not the names assigned to them. Using the correct element for the correct job is as far as semantics goes. Standards concerning naming of those elements is all about sensibility.
Semantics sets a standard from which it is very difficult to stray. Headings are
marked up with a <h1-6>
, a list with <ul/ol/dl>
and so on. You cannot,
however, define a convention for naming the IDs and classes of these.
<div id="contact">
, <div id="kontact">
and <div id="contact-info">
all
bear different names, but are all equally as semantic. All three are examples of
semantic and sensible code.
However, take the following examples: <div id="bottom">
,
<div id="lower-area">
and <div id="b">
. These examples exhibit semantic
code, but with insensible namings.
Semantics should be adhered no matter what—web standards are good. Naming
however is totally down to you, you can call your elements whatever you wish.
<div id="a">
, <div id="b">
and <div id="c">
are all possible, but not
sensible.
Always code like you’re working in a team, even when you’re not.
I have actually seen markup like this, and the developer’s reasoning was I
like to keep my markup as lean as possible, and I know what
a
, b
and c
do.
While this is all correct, and passable, it’s not really very sensible. He might
know what a
, b
and c
do, but what about the person who inherits the
project? For all his justification of code bloat was somewhat advanced (really
decreasing markup size), the impression the next guy to see his code will have
will be ‘WTF was this guy thinking?!’ Always code like you’re working in a team,
even when you’re not.
An ID/class should be as short as possible but as long as necessary.
Jens Meiert
Semantics and sensibility are not the same. Anyone who tells you that
class="left"
is insemantic is wrong. Be semantic and be sensible. Pick names
which are descriptive. An ID/class should be as short as possible but as long as
necessary.
Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.
Hi there, I’m Harry Roberts. I am an award-winning Consultant Web Performance Engineer, designer, developer, writer, and speaker from the UK. I write, Tweet, speak, and share code about measuring and improving site-speed. You should hire me.
You can now find me on Mastodon.
I am available for hire to consult, advise, and develop with passionate product teams across the globe.
I specialise in large, product-based projects where performance, scalability, and maintainability are paramount.