The primary building blocks or components of HTML are "elements" (aka "tags"). One common (and overused) example would be a div element which would look something like this: <div> According to the W3C spec the div element is
a generic container for flow content that by itself does not represent anything
Semantic HTML means using elements that are descriptive and thus represent the information/data that they contain. For instance there is a <nav> element which is intended to be used as a container for navigation elements. Similarly there is a <footer> element which is for footer content in relation to it's parent element. For example if I wanted to have a copyright declaration at the bottom of my website I would place that within a <footer> element. As you may know not all HTML elements are truly semantic and not every developer uses newer HTML5 semantic elements. However from a readability standpoint you can see how utilizing semantic HTML makes markup itself much better and even self-explanatory. For a more in-depth explanation of semantic HTML I'd sugest you read the Semantic HTML Wikipedia entry.
Now that we've covered semantic HTML, let's consider what semantic CSS might look like. There are many schools of thought on CSS selectors and the naming conventions that follow. Before I dive into some examples I'd like to make a distinction between semantic and expressive (or rather verbose) names. I would say that the class names "col" and "column" are both semantic but "column" is also expressive/verbose. I'm personally of the persuasion that expressive/verbose names are ideal; but to each their own.
The idea of semantic CSS is really a simple one. Ultimately you want your CSS selectors to explain what it is they're doing. For instance, if you use the class name "column" style vertical columns on a page, that's would be semantic. So if someone can read your selectors and (without seeing the styles) know what their purpose is then you're doing things semantically. One really greate example of this is Semantic UI, a front-end framework that aims to be as semantic as possible.
Breaking away from what web developers usually associate with being semantic, let's take a look at how these same principals might apply to programming in general. I'll note here that I'm not so much talking about semantic-oriented programming. Really I'm concerned with applying some of the above concepts to general programming practictes. Obviously if we're dealing with an object oriented language this process would start with classes (or whatever parent they're implemented from; interface, parent class, etc). So if you had a class for dealing with users, you would probably want to name the class "User". Again, a simple/obvious concept for most people, but we have to start there so that we can carry the concept all the way through our code. So a User class would probably need a function to retrieve personal details and you might want it to return all of the details at once. A semantic way to name this function would be "getPersonalDetails". Of course, keeping in mind good naming practices you would want to keep the verbage consistent with the rest of your codebase but that is just one example. The litmus test here is very simlar to markup and css. If you can look at the usage of this function and understand what it's supposed to do, then you've done a good job. Here's an example usage of our function in PHP:
$bob = new User(); $personalInfo = $bob->getPersonalDetails();
The next level in programming would be variable naming. Often times variable names can become an after-thought and you end up with single character named variables such as "x", "i", or "y". The most common place to see poor naming like this is in loops. Programmers are inherently lazy (hence why they're so good at finding easier ways of doing things) and "for" loops need a variable to use as a counter so it's common to see "x" or "i" used for this. In this particular case, it's become such a common practice that most programmers would understand this variable; however, it's not semantic and often exposes a larger lack of semantic naming. In the case of loops even just naming the counter variable "counter" is helpful. One tenet of good naming conventions is being almost overly explicit when naming things which marries well with semantic naming.
If you can get into the habit of following these guidlines your code will become much more readable and understandable at a glance, which is always a good thing. Most of the time these arguments are countered with "I'm the only person reading my code so it doesn't matter", which is a very poor argument. This is because (as experienced developers will know) as time goes on we forget all of the quirks, edge cases, and weird caveats in our old code. Even with some good naming conventions (including semantic naming) it can be difficult at times to understand legacy code at first glance. So the more that you can embrace semantic everything, the easier you'll make your job and the job of others that use your code.
The last area I'd like to look at is database design. The same principals we've discussed apply here but instead of classes, function, and variables we're talking about tables, columns, and foreign keys. Again, the goal here is to have someone unfamiliar with your project be able to read your schema and immediately understand what they're looking at. They shouldn't have to understand anything about your project to be able to easily read your database. So if we were to store our users from earlier, a semantic name for that table would obviously be "users". Most tables need a column that's used as a unique identifier and our users table is no different. Normally this would be a user id and a good name for the column would be "user_id". Many times if you're using a database administration tool such as PHPMyAdmin and you create a foriegn key relationship, it will give you a default name such as "FK1". But that doesn't tell us anything about that foreign key or the tables it's connecting. If we were connecting a user with an animal where each animal relates to one user, we might want to name the foreign key "AnimalOwner".
Hopefully the takeaway is clear: when naming anything it's always best to be as descriptive and explicit as possible. In several cases this is obvious, but often times not taken to it's fullest extent or embraced totally. However, I think it's clear that the benefits far outweigh the small amount of extra time required to fully embrace it. I'm of the opinion that semantic everything is a great idea.comments powered by Disqus