You’ve been seeing <main> for a while now, and I’m happy for you. <main> will help screen readers and other assistive technologies understand where the main content begins. I figure that since you had already distinguished asides and sections, maybe you thought, “why not clarify the remainder?” Of course, I’m not sure where this leaves content that isn’t explicitly in <main>, <article>, <section>, or <aside> now.
<main>I found my special purpose!</main> <p>Where did I come from and why am I here?</p>
Nevertheless, I can understand the desire for such a definite element.
So, about headings
Listen, it’s been a while now, and you’ve still not added an element to mark up subheadings, subtitles, alternative titles or taglines, and it’s time we talked about it. This is a sore subject, and I can understand why. Things with <hgroup> didn’t work out too well. Let’s relive history for a moment. It’s important to remember where we come from, because it helps us move forward.
At first, <hgroup> wasn’t so bad. You figured if people were already marking up subtitles as headings, <hgroup> paved the cowpath. Then you started noticing how easy it was to goof up the strict semantics, and how often it required a detailed knowledge of the markup structure. Then you started questioning whether you had added it “simply to support the newly created outline algorithm”. And let’s be honest, you started doubting the new outline algorithm altogether, because you certainly weren’t a fan of sectioning elements reseting <h1-6>. It wasn’t long after when you broke it off.
But the WHATWG did not drop <hgroup>, so developers are caught in a rift. It’s hard to implement a standard in an area where two major standards bodies have irreconcilable differences. And let’s be frank, the WHATWG’s real world examples accurately reflect the usefulness for an element to signify a subheading, subtitle, tagline or byline. After all, that’s why they have not dropped <hgroup>.
There is another
Remember those real world examples? <subhead> covers these and more (bylines, taglines, etc.), and its semantically less confusing. Unlike <hgroup>, <subhead> is more backward compatible because it does not force a new <h1-6> grouping pattern upon the markup where none previously existed. <subhead> also addresses scenarios where the subheading does not immediately follow the heading element.
<subhead> is cleaner than some of the hackier alternatives. Unlike <small>, it’s neither an inline or sectioning aside, and it doesn’t represent a side-comment or “small print”. And unlike <aside>, it doesn’t represent a section of tangentially related content. I know you never recommended these methods in your suggested alternatives, but these are just ways clever developers have tried to fill the hole.
<subhead> gives authors a clear and flexible element to mark up existing and future content structures. <subhead> does not require taglines, bylines, subtitles etc. to be marked up as <hx> headings, and <subhead> can be a child of a heading or a sibling of a heading.
<h1>Dr. Strangelove <subhead>or: How I Learned to Stop Worrying and Love the Bomb</subhead></h1>
<h1>brucelawson.co.uk</h1> <subhead>Gorgeousness in a gimp mask</subhead>
Think about it.
Your friend and fellow developer,