It was a hot Summer Sunday afternoon. I’d just stepped off the Acela Express from Boston to New York City, and I was confused as ever about HTML5. I thought I was alone. Impossible in mid-town Manhatt– no, alone in being confused about the next chapter of markup specifications. I figured something was wrong with me. Was I not reading up enough about HTML5? Well no, wait, I’d been doing a fair amount of reading up about HTML5, yet there was still this partial confusion about a number of aspects of the proposed spec.
Personally, I came away from that day less confused, but more importantly feeling more positive about HTML5 in general. Along with this newfound positiveness, came some clarity in specific portions of the spec that seemed troublesome. The rest of the group (I can take zero credit for its publication) crafted a “guide to HTML5 hiccups” in the hopes that the powers that be would listen and healthy debate might begin on these specifics.
A few of those items that stood out for me were:
- Offering an HTML5 syntax option when validating. This has nothing to do with HTML5 itself, but it’s important for the validator to simply and easily add an option for checking syntax that would help to foster good coding habits, avoid head-scratching rendering issues, etc. That’s why I choose to code XHTML today — it’s a personal preference that helps me maintain, optimize and troubleshoot code, and I’ll continue with that convention no matter the doctype.
- HTML5 introduces a lot of new elements. All at once. Some of which seem unnecessary (e.g.
- While at first I was cringing at the idea of redefining the semantics of certain elements, it does start to make sense. Instead of introducing even more elements, HTML5 reuses and redefines. For example, the
smallelement would now “represent side comments such as small print”, rather than a presentation instruction for font size.
- The concept of “sectioning content” I didn’t quite get at first from the high level overviews I’d been reading, but seen in practice, it’s quite excellent (e.g. where the
sectiondictates scope of the heading elements it contains).
- That said, folks will use
footerfor exactly the areas that they’re now assigning IDs with those terms, while in HTML5 they can mean different things (header and footer of a section, for which there could be many on a page).
I still have an enormous amount to learn about HTML5, am still concerned about certain aspects of it, but overall optimistic about the future of markup.