What we can say with certainty is that the lessons are all HTML. Much of what we use is essentially HTML 4. Given that browsers are staying on top of the emerging recommendations and have a hand in many of them, we can anticipate support for most new iterations of what is a living language.
Indeed, we do see the elements that came into use with HTML5, and there are lot of new elements with the jump from HTML 4. Few of them were any surprise, though since they basically evolved out of what was a regular practice for assigning roles to key segments.
<div id="main" class="main">
Nothing changes in terms of the makeup of the element’s default style rules. It’s akin to saying,
Something that has always existed in the HTML API is the ability to create elements. It follows right on the heels of XML. Trouble was that if a browser did not support (permit hooking by style sheet and script) the elements we created, there wasn’t much we could do with them.
HTML5 evolved within the same constraint. Browsers, most particularly Internet Explorer needed to be told that an element existed, and since it could not be told in the HTML, or the CSS, it had to be told in script. Using script to create the element definitions meant they could now be hooked by CSS and DOM script. Thank Remy Sharp for what became a universal implementation that enabled the crossover from HTML 4 to HTML5 during those tricky, spotty support times… html5shiv.js.
We are not likely to see this script in use, these days, though I wouldn’t doubt it is nestled away (in principle) in the core of a few frameworks, to this day.
It’s still a useful tool if we want to create our own elements, also not something to try, just yet. It’s not a requirement of HTML authors to invent elements. It’s a rabbit hole we don’t need to go down. Fun to know it’s there, though, isn’t it?
Vendors toyed with their own ideas for a considerable number of years. They shared their ideas through their own non-partisan working group and each created their own draft version. It’s what made it necessary to use ‘vendor prefixes’ on selectors, and use that vendor’s property declaration. We see it to this day in reams of legacy code either from the period, or still, in most cases, unnecessarily.
W3C had a big hand in all the proceedings, but only led their own group who were charged with examining the outpourings of the vendor group and seeing what could be reasonably and purposefully added to the specifications. It’s why we see the last selector rule always without a vendor prefix. It’s the W3C recommendation, and today, more than ever, vendors are sticking very close to the W3C line. In other words, we can almost depend upon it.
There are sites such as ‘caniuse’ and ‘quirksmode’, et al that may or will have current information on which browsers support which features. Ultimately, that is just a wee bit down the road in terms of where one would spend their time most effectively. Find them, and bookmark them, then back to learning!