Article tags semantics

We all recognize that we should be writing semantic code. Maybe, you're even using or correctly, and feel pretty good about yourself. But, are you also considering the implied contract that exists when you code?

Let's imagine that a customer requests a text link, “See More, ” which should reveal additional text on the page. with a click handler should work perfectly, right? Hey, it looks and functions as requested!

No, it will not always work correctly, as it violates the contract between you and the browser. In particular, I'm referring to the one that says the href attribute must have a value that is a valid URL.

There are practical problems which can arise when violating contracts, and those are much better reasons to write semantic code than things you usually think of when you hear the term, “semantic”.

Popular Arguments for Semantic Code

There are, however, much more practical reasons to care about semantics: contracts.

If you ask an average developer what the value of semantic code, you'll likely hear something along the lines of:

• It assists the disabled
• Properly describing code makes it easier for machines to interpret

Both are, unfortunately, very easy to neglect. “Blind people and robots are not the target audience” is too simple of a response, regardless of how misguided or ignorant it might be.

In other cases, you might even hear cyclical reasoning, such as “non-semantic code is bad, because it is not meaningful.” It is such a popular notion to the point that parodies on it have already sprung up around the web!

Usage Contracts

Any time that you use some functionality provided by browser vendors, your programming language, or an API, you are relying on a contract.

On one side of the contract exists a provider of functionality. For example, when you use an tag, browser developers are promising to you that they will provide an easy way for the user of your application to navigate to the specified URL.

As always, however, there's the other side of that contract. The implementer of the functionality promises to use the functionality as specified. As soon as he misuses this functionality, all bets are off - leading to potential failure.