From then on, your experience with HTML may have been something you sort of learned by osmosis. Whenever you wanted to practise styling a button, you might have felt that a div appeared to give you a clean slate from which you could pour your CSS talents on to. Actually, you might have begun to feel that divs rule HTML. If you needed a new element, slapping some divs down seemed to work alright. What really mattered, you felt, were the ids and classes. Rather than using semantic elements, you would let ids do the heavy lifting from a readability standpoint.
All of the above in some ways describes me; though, starting out I did invest in the Visual Quickstarter Guide for HTML5 and CSS(notice how HTML usually doesn’t stand alone). I still remember being fascinated by how specific HTML can get in its layout. The book teaches readers what elements like article and section can be used for. Rather than using a boring div, use an article tag for content-rich pages. Use an aside for your sidebar rather than floating a div.
I was working on front end UI with a friend who was just learning the front end. I quickly slapped together some markup for him to style; though, knowing that he was slightly new to HTML, I decided to do the responsible thing and write semantic HTML. When we met up on Google Hangouts to discuss the code, he acted as if I’d written Greek.
His confusion can be summed up in one question: “Why didn’t you use divs?”
That gave me the opportunity to explain that part of writing good HTML is writing semantic HTML and that writing semantic HTML not only makes it easier for us to read HTML, but it also makes it easy on web crawlers.
Of course, there are a bevy of other benefits that actual HTML experts can elaborate on. But you can see how it’s easy to feel that you know enough HTML to be dangerous. That thinking is what prevents one from getting to the meat of HTML. So, Lambert concludes his post by outlining ways in which one can learn the nuances of HTML. The resources he listed are worth checking out.