HTML Semantics – Why Proper Markup Matters

htmlhtml5markupsemantics

_{Note that I (try) to mark up as semantically as possible because I like they way it looks and feels, but not because I'm aware of any other stunning advantages. The point of my question is to be able to educate others}

Well, I've seen a lot of articles and tutorials which often state "Let's mark this up in the most semantic possible way".

But a strange thought came to me, why?

Why would one need (or want) to bother with the specific elements which convey the correct semantic meaning? Specifically, I'm referring to the new HTML5 elements, such as <time>, <output>, or <address>. Especially, if the page "works" (it renders nicely in all browsers).

Why would I want to use elements like <time> or <address>, where nothing at all (or at the worst case, a generic <span>) works just as nicely?

I'm asking this because I'm seeing a multitude of (very popular) websites (this one included) which does not follow these so-called best practices.

Best Answer

Free Functionality

Properly using <label>s means you can click the label to enter the text field. Many browsers will add logical default functionality to many tags per the official specification, meaning you can use fewer JavaScript plugins and write less code than a site made entirely out of <div>s and <span>s.

Accessibility

Related to free functionality, semantics mean a lot to screen reader software. Text in front of an input field won't be read in quite the same way as a <label> will. Screen readers will ignore most of your CSS, so it's mostly up to the structure of your HTML.

Logical CSS

Why use a div #header when you can use a <header> and style that directly? Semantic tags make it easier to mark things up and make your style much more portable; if you have a certain style for strikeout and always use <del> elements the style is much more portable. <del> means the same thing to everyone, but everyone will name their .deletedText class differently.

It also helps keep everyone on the same page in large projects; no one enjoys learning other people's esoteric class naming conventions.

SEO

Search engines like Google have made increased use of semantic HTML and metadata. Google's Rich Snippets also use special metadata meant to convey semantic content.

Why it's not all that common

It takes work, and people are used to judging a website by how it looks and works. Often there's no accounting for semanticness because people who write the business case for apps don't understand it or why it's important.

It's very hard for non technical people to understand or evaluate HTML semantics.

If a website looks good and it appears to work, why fret? Many people may not even know there is anything more to it. Similar to accessibility, this tends to get ignored until someone on your team really understands this.

If you want semantic HTML to be a priority on your project, you need to present the case for it. Showing your team/boss how your website works in a screen reader is also a helpful tool.

Related Solutions

Why No PUT and DELETE Methods in HTML Forms?

This is a fascinating question. The other answers here are all speculative, and in some cases flat-out incorrect. Instead of writing my opinion here, I actually did some research and found original sources that discuss why delete and put are not part of the HTML5 form standard.

As it turns out, these methods were included in several, early HTML5 drafts (!), but were later removed in the subsequent drafts. Mozilla had actually implemented this in a Firefox beta, too.

What was the rationale for removing these methods from the draft? The W3C discussed this topic in bug report 10671. Mike Amundsen argued in favor of this support:

Executing PUT and DELETE to modify resources on the origin server is straight-forward for modern Web browsers using the XmlHttpRequest object. For unscripted browser interactions this not so simple. [...]

This pattern is required so often that several commonly-used Web frameworks/libraries have created a "built-in" work-around. [...]

Other considerations:

Using POST as a tunnel instead of using PUT/DELETE can lead to caching mis-matches (e.g. POST responses are cachable, PUT responses are not(6), DELETE responses are not(7))

Using a non-idempotent method (POST) to perform an idempotent operation (PUT/DELETE) complicates recovery due to network failures (e.g. "Is is safe to repeat this action?").

[...]

It's worth reading his entire post.

Tom Wardrop also makes an interesting point (href):

HTML is inextricably bound to HTTP. HTML is the human interface of HTTP. It's therefore automatically questionable why HTML does not support all relevant methods in the HTTP specification. Why can machines PUT and DELETE resources, but humans cannot? [...]

It's contradictory that while HTML goes to great lengths to ensure semantic markup, it has to date made no such effort to ensure semantic HTTP requests.

The bug was eventually closed as Won't Fix by Ian Hickson, with the following rationale (href):

PUT as a form method makes no sense, you wouldn't want to PUT a form payload. DELETE only makes sense if there is no payload, so it doesn't make much sense with forms either.

However, that's not the end of the story! The issue was closed in the W3C bug tracker and escalated to the HTML Working Group issue tracker:

https://www.w3.org/html/wg/tracker/issues/195

At this point, it seems that the main reason why there is no support for these methods is simply that nobody has taken the time to write a comprehensive specification for it.

JavaScript – Why Separate JS Hooks from CSS Hooks in HTML?

Maybe you notice that because, as you said it yourself, you have to work with inexperienced programmers.

In practice, the distinction you observe doesn't exist. Frameworks, by the way, discourage such distinction.

For example, jQuery encourages pretty well to use selectors in a general way, which means that you use IDs to target a single element and classes to target multiple elements.

In the same way, a not totally retarded developer would quickly notice (learn) that classes are bad candidates for unique elements on a page: of course, you can replace all IDs by classes in both HTML and correspond CSS, but it would make things slightly... let's say unreadable, if nobody cares about performance.

As for the inexperienced programmers, they may tend to do strange things. It took me a few weeks to explain to one fellow colleague that:

<div id="entry">Some text here</div>
<div id="entry">Some other text</div>

is wrong, because IDs are unique. Take one beginner who have just read an article explaining how to use classes in CSS and another article about data- attributes in jQuery, and you easily understand why this beginner starts to use classes for CSS and data- for jQuery selectors.