Sour. Me Fish. Like! Like, BBQ
This may sound a little strange coming from a guy who spent the last 5 or 6 years submerging himself in the world of semantics, tags and attributes, but I have a little secret to share with everyone: html is really easy. You don't have to be some kind of abstract-loving, purism-craving brainiac to make a decently marked-up html page. Some very limited knowledge of the core concepts of html coupled with some basic training will get you a long way, and yet ...
Language
Before I go on about the specifics of html, let's talk language in general. Just consider the following three sentences:
- 1. I absolutely adore grilled salmon with a lemon on the side.
- 2. I like salmon on grill with little piece of lemon.
- 3. Sour. Me Fish. Like! Like, BBQ
I think it's pretty obvious that the first sentence is preferable. The second one has some grammatical issues and lacks the semantic depth and clarity of the first one, but it's still perfectly understandable. The third sentence is just one big mess. Sure enough, work really hard and you can try to make something of that last sentence, but I think we can agree that nobody wants to be associated with this level of skill.
Now, if English isn't your mother tongue speaking at the level of sentence 2 is acceptable. It isn't perfect, but it's good enough to make yourself unambiguously clear. Similarly, if html isn't your core skill perfection shouldn't be a goal, but you still want to reach an acceptable level of output.
Aim For 75
If you truly immerse yourself in the finer points of html you can talk hours on end about semantic grey areas. Is it div, article or section and where to draw the line? Enough food for discussion right there. Getting the whole wai-aria deal implemented to the letter or enriching all your data with the correct html5 microdata values and attributes can also be tricky business. And what about the most logical way to structure your page? Is it really meaningful to place the entire site header at the top of your document? Ask 10 different people and you'll quickly see there is plenty of room for personal differentiation.
But I'm not going to talk about getting your html "done, finished, over, hands-off!" ready. Instead, I'll be talking about writing sound, fair and usable html code. The kind of html code that wouldn't be too hard to improve if you've been staring at W3C documents for the greater part of the past decade, but is good enough to start working with considering the budget and constraints of a project. The kind of html code you'd give 75/100 if you were to grade it.
Getting there isn't all that hard, as long as you keep the following core concepts in mind.
Pillar 1: Semantics
As you may know, html5 added quite a few elements to the html vocabulary. But even with all these extra elements, html remains a very limited language. In total there are about 120 tags, that's it. On top of that there are a few attributes to learn, but these too are extremely limited.
If 120 elements still sounds a little daunting, let me assure you that you could probably make do with 20 or so different tags when building an average html page.
- Use
<html>/<body>/<link>/<script>
for your html page frame. - Use
<div>
for structure, ignore the other elements. - Use
<p>
for paragraphs of text, nothing else. - Use
<ul>/<li>
for lists, leave<ol>
alone. - Use
<a>
for links. Not that you have much choice. - Use
<hX>
for headings. - Use
<img>
for images. - Use
<table>/<tr>/<td>
for tables. - Use
<form>/<button>
for forms and submits. - Use
<input>/<select>/<textarea>
for form input
With the elements above you should be able to handle most pages in the wild. Of course it won't yield perfect html, but it will suffice. The other elements all have their function and will add plenty of extra semantic value to your pages, but you can worry about that later.
Pillar 2: Targetability
This is basically your class and id management. Two simple rules will guide you through this process.
- Make sure instances of the same component can be targeted throughout the site.
- Make sure each component on a specific page can be targeted.
To accomplish that, simply:
- add a body class for each page template.
- use the same class for every component instance across a site.
- add an extra class for each functional/visual component variation.
This will leave you with a html structure that can be manipulated both on global site level and on a very detailed component/page level. That's all the leverage you'll ever really need.
Pillar 3: Structure
Structure is probably the hardest part to grasp for people not used to writing html. This is a bit more abstract, but the basic premise is once again extremely simple though:
Group everything that belongs together.
What do I mean by grouping? Just put divs around elements that belong together. Have a heading and two meta data elements? Group the meta data. Do you have body content too? Group the heading and meta data to separate it from the body content. Have social links to go with that? Just group those in a div.footer element. Worry that you'll end up with too many divs in your code? Stop doing that, nobody cares.
The point is, if elements have a logical connection, just throw a structural element around them. This structural element will group the parts that belong together and it will separate the elements that don't. It may be a little abstract at first, but you'll get the hang of it soon enough.
Conclusion
If dealing with html is your daily job the rules above don't really apply. Extra semantic meaning, saner structures and better source order will all add to the overall quality of a website. So will all microdata and wai-aria decorations. I'm not saying these things are not important, but if you're just starting out with html or html isn't your core skill, the extra hurdles will only detract from the core principles of html.
So why the rant? Well, when I look at the standard output of most cmses (and even custom back-end development) today the output is still light years removed from reaching that basic quality level that's needed to do some proper front-end work. They are at the level of sentence 3. They may claim to output html, but in reality what they output doesn't make the slightest sense. They don't care about the language that html is supposed to be, instead they only see abstract hooks for css and javascript.
There is plenty room for purism in html and that should be dealt with when working against strict deadlines and limited budgets, but there's still a base level of quality that should be met even if time is sparse. If you can't reach that level, you're probably not fit for the job and web design isn't the field you should be working in. And don't blame it on html being too difficult, because it's probably the easiest part of building a website and mastering the basics shouldn't take you much longer than a week or so.