There are many concepts in front end web development. One that seems to be thrown around everywhere is semantics. In today’s article, I will examine the semantics of front end development and what it means.
So what are semantics?
Personally, I think semantics is hard to define. Merriam-Webster defines semantics as “the study of meanings.” In front end web development, semantics refers to code that corresponds to the information on a web page as opposed to the presentation of it.
An example of bad semantics would be something like this:
<div class="grayBorder"> <div class="blue">Awesome Blog Post</div> <div class="blogpost">Here goes content!</div> </div>
A better approach would look like this:
<div class="post"> <h1>Awesome Blog Post</h1> <p>Here goes content!</p> </div>
The top example is considered bad because class names such as blue does not describe what the content is when in fact it is the heading of an article. It may look like a heading on a page, but it is not defined as one, as shown in the bottom example.
If you are using HTML5, then <div class="post"> could be <article>, which would make it even more semantic. As a side note, HTML5 is considered more semantic because of these new tags like <article>, <header>, etc. that actually describe the content that they contain.
Tips for Semantic HTML
The biggest tip for writing semantic HTML is to omit unnecessary markup. Consider this example:
<div class="post"> <h2>Title</h2> ... ... </div> <div class="hr"><hr /></div>
Let us assume the <hr> is just a simple line that divides the content. While you could argue that <hr> is not wrong since it is used to define a change in content, the parent <div class="hr"> is largely unnecessary. I would personally argue that the whole line is not needed because .post defines the change in content and the border property on .post would be enough.
Another tip for writing semantic HTML code is to use the tags are they were intended. For example, don’t use a <div> when you really mean <h1>. Also, use <table> for tabular data, not the webpage layout. Remember way back in the day when people used <table> for webpage layout? That is not an acceptable practice anymore.
Tips for Semantic CSS
I think the definition for semantic CSS is even more vague than that of HTML because CSS deals with presentation, not information like HTML. However, there are some tips to make CSS semantic.
Using appropriate names for classes and IDs would make the CSS code more semantic. For example, as shown in the top example, .grayBorder is less semantic than .post because .grayBorder describes the presentation of a <div> element that we want to denote as a blog post. The class name .post is more semantic because it describes the content, which is a blog post.
Similarly, using conventional classes or IDs would be more semantic. For example, the terms “header,” “footer,” and “sidebar” are so common that they have become conventional. That means those terms actually have a meaning associated with them. For example, I would recognize “header” to be the top section of a webpage, and most front end developers would also assume the same. For that reason, using those conventional terms for classes and IDs would be semantic.
Argument Against Semantics
I think web developers should strive to make their code as semantic as possible, but there are exceptions. For example, defining a CSS class and reusing it could be really beneficial. For example, if the website mockup has a certain gradient on elements, using something like .gradient and having all the CSS gradient styles on it would be convenient because classes could be reused and it cuts down on the size of the CSS file. Along the same lines of naming convention, .left and .right would also be acceptable to float elements to left or right.
Another exception is when dealing with cross-browser compatibility. Sometimes, especially with IE, there are times when an extra <div> is necessary.
Conclusion
The ability to work well in a team environment is important for anyone, but I think keeping the code as semantic and clean as possible definitely helps the work flow in a web development team environment. Whether your views on web development semantics is more strict or flexible, I hope you found the article useful.