Add <h> element

[jonathantneal]

We need a heading element without implicit order. We need a heading element that can be updated without being replaced. Please consider <h>.

The <h> element is desired for situations where the “ranking” context changes for a heading, either before or after the source is sent to the browser. The current process of figuring out the appropriate “rank” of a heading is as unnecessary as requiring <li> to be <l1-n>.

Which also brings up a secondary point; there are not only 6 levels of headings.

So, please, please thoughtfully consider a single heading element like <h>, which would represent the heading for its section. The “rank” of such elements would be determined by outline depth.

If it helps, this addition might be developed on the shoulders of the XHTML 2 <h> element proposal, or @stevefaulkner’s html5-h proposal which answers to this bug. I believe Steve recognized that a fiction of the document outline was its retroactive impact on <h1-6> elements, which this new element would not be impacted by.

Should there be concerns regarding the time between specification and implementation, polyfills like the one The Paciello Group created would provide developers an appropriate and accessible fallback before the new element is widely adopted. Things like this have been done in similar situations, like with <picture> not being recognized in all browsers for a time, or with <nav role="navigation"> not being recognized with an implicit landmark.

[bkardell]

If we're serious about this, I'd suggest working on a better polyfill and considering several things... @stevefaulkner was kind of proof of concepting it pretty early, and that was great, but it currently this uses polymer and from what I can see it is probably incomplete... Should probably just be vanilla v1 - It also could use some more thought/tweaking in implementation (should probably consider aria roles for sections maybe as well, probably not use imports, should work with dynamic mods/lifecycle, etc)... I agree this is kind of important, I use a build time process to do effectively the same thing for my blog in fact - another challenge is that the currently all or nothingness of it makes it hard... Like, if you also have an <h1>...<h6> somewhere in your page, it will be wonky.

[Marat-Tanalin]

a fiction of the document outline was its retroactive impact on <h1-6> elements, which this new element would not be impacted by.

Exactly.

[jonathantneal]

If we're serious about this, I'd suggest working on a better polyfill

That’s fair. Here is a speculative polyfill: http://codepen.io/jonneal/details/wgombw/

consider aria roles for sections

I expect to rely on existing expectations; following what browsers and a11y tools already interpret when, say, a [role="section"] contains a [role="header"]. Backwards compatibility with existing apps should be paramount.

Relevant: https://www.w3.org/TR/html5/sections.html#outlines

[chaals]

This is a really common request for HTML. The use cases seem clear, there have been several attempts to make it happen, and it would seem helpful.

Is there evidence of widespread usage of polyfills to make it happen in practice?

[Marat-Tanalin]

Fwiw, when I need a levelless heading, I currently use either DL element (just to exploit its DT as a heading):

<section><dl>
    <dt>Heading</dt>
    <dd>
        <p>Some content.</p>
    </dd>
</dl></section>

or a bare HEADER (not quite correct, but it at least has similar/related semantics):

<section>
    <header>Heading</header>
    <p>Some content.</p>
</section>

In both cases, HTML validator, as expected, complains of that the section lacks heading.

The usecases include e. g. a heading for each of sections in a sidebar [1], or for an aside block that is placed after article text, intended for printing and contains a list (index) of all links used in the article [2].

[1] http://tanalin.com/en/about/ [2] http://sergeytroshin.ru/articles/windows-7-tweaking/

Also, considering the forever-weird magic behind the existing LEGEND element, as well as the fact that it is only intended for FIELDSETs and cannot be used for forms themselves, I would like to use a new levelless-heading element (free of any legacy magic) in such cases instead of LEGEND.

[jonathantneal]

Okay, let’s make this happen. I’ve written a specification proposal for a contextual heading <h> element:

https://rawgit.com/jonathantneal/h-element-spec/gh-pages/

I’ve written a speculative polyfill that gives the appropriate role="heading", aria-level="n", and <h1-6>-like styles to contextual heading elements (using a custom element namespace) in real-time:

https://github.com/jonathantneal/hfill

I’ve written a postcss and posthtml plugin that would allow you to use and style contextual headings JavaScript-free.

https://github.com/jonathantneal/postcss-hfill https://github.com/jonathantneal/posthtml-hfill

[rubencodes]

I haven't had my morning coffee so this took me a minute to grok.

I think when most people think about <h[x]> elements, x denotes the prominence on the page of the heading, but here you're more talking about the interpreted semantics of <h[x]>, yes? If so, totally agree and seems like outline depth is a good measure, assuming it's relative to the rest of the <h> tags on the page.

[pxsmith]

This is quite sensible. 👍

[LJWatson]

Thanks for the proposal and polyfill @jonathantneal

[domjtalbot]

Awesome idea @jonathantneal, seems quite logical!

How about <heading> as a more semantic approach, perhaps? :thought_balloon:

[pepelsbey]

You can’t always control you modules/blocks nesting while using templating or partials systems. It’s too easy to make a mistake or get caught in a nesting you can’t possibly control. That’s why explicit heading levels numbering is so useful. <h> would be as fragile as nesting-based languages though we used to think about HTML as bullet-proof markup that will always forgive us all mistakes.

[pxsmith]

@domjtalbot first of all, <header> is six letters longer than <h>. 😂 But on a serious not, it seems like HTML5 Doctor suggests using <header> as a wrapper for <h1>, <h2, etc. I was wondering that, myself, about using <header>—glad you asked the question.

[chaals]

@pepelsbey

You can’t always control you modules/blocks nesting while using templating or partials systems. It’s too easy to make a mistake or get caught in a nesting you can’t possibly control.

The way I think - e.g. when you are trying to write content that will drop into someone else's template or page, being able to use nested sectioning/h elements and have the outline generated automatically is a positive thing. That's why it has been proposed for XHTML2, included in HTML 5 despite no implementation, and why it keeps coming up as a request.

So I don't understand your conclusion, which seems to be the opposite - if you have the nesting calculated for you, something will go wrong.

Or did I just misunderstand?

[pepelsbey]

@chaals, you're coming from optimistic conclusion that outline is always correct and everyone knows what they are doing. But since outline is just and idea existing only in the spec, but not in browsers, developers’ minds or real-life code, I'm inclined to think that it's wrong by default and as an author of a module you can't control the proper nesting level. I wouldn't rely on outline when <section> is just a new fancy <div>.

[stevefaulkner]

@chaals @pepelsbey I agree, the heading level being reliant upon the nesting of article and section elements is problematic because there is no requirement that either include a child heading and the outline algorithm does not take into account section/article elements which do not contain child headings.

for example

<h1>heading</h1>
<section>
<section>
<section>
<h1>heading</h1>
</section>
</section>
</section>

results in h1 h3

And this is not a theoretical markup pattern, there are plenty of examples in the wild where multiple nesting of section elements can be found. will provide some later.

[stevefaulkner]

252 HTML5 pages using the section element

The following pages are a subset of pages that use the HTML5 doctype that also use the section element. The section elements have been styled to indentify section elements and section element nesting (up to 2 deep). http://www.html5accessibility.com/HTML5data/section/section.html

[LJWatson]

@stevefaulkner broken heading hierarchies happen routinely with numbered headings already, chiefly because developers choose headings based on factors other than their semantic importance. So in this regard, this proposal probably doesn't gain us much ground - we're likely to end up with broken heading hierarchies whichever way we go.

As an aside, I wonder whether the conformance validator would be better able to detect errors in sectioning as opposed to heading numbering? Ping @sideshowbarker

But the appeal of this proposal is that it seems to provide a way to solve the content reuse problem. Drupal is a good example: it uses panes of content to construct templates, and a pane can be reused across multiple templates - each of which may have a different heading hierarchy. Right now it's next to impossible to maintain robust heading hierarchies across multiple templates unless you have a website of draconian simplicity.

So given an equal playing field (a developer who understands both heading hierarchy and sectioning hierarchy), the <h> proposal would seem to solve a relevant problem for content reuse.

[nico3333fr]

Even if the idea is really not bad, I see a lot of cases where it will fail. Consider this code :

<section>
  <h>Lorem Ipsum<h>
  …
  <h>Dolor si amet<h>
  …
  <h>Consegur<h>
  …
  <h>Blahblah<h>
  …
  <h>Blahblah 2<h>
  …
</section>

How do the browser will know that it means :

<section>
  <h2>Lorem Ipsum<h2>
  …
  <h3>Dolor si amet<h3>
  …
  <h3>Consegur<h3>
  …
  <h2>Blahblah<h2>
  …
  <h3>Blahblah 2<h3>
  …
</section>

or

<section>
  <h2>Lorem Ipsum<h2>
  …
  <h2>Dolor si amet<h2>
  …
  <h3>Consegur<h3>
  …
  <h3>Blahblah<h3>
  …
  <h4>Blahblah 2<h4>
  …
</section>

Etc.

In fact, this idea (even if I find it really cool) moves the problem of the Hx-outline to landmarks (section, header, etc.). If so many sites are already failing to provide a correct Hx structure, I really fear that they won't be able to do better using landmarks.

[SebastianZ]

I assume this requires to nest them in subsections, e.g.

<section>
  <h>Lorem Ipsum<h>
  …
  <section>
    <h>Dolor si amet<h>
    …
    <h>Consegur<h>
    …
  </section>
  <h>Blahblah<h>
  …
  <section>
    <h>Blahblah 2<h>
    …
  </section>
</section>

Additionally an optional attribute level could be introduced allowing to overwrite the level defined by nesting, e.g. <h level="3">. That's more verbose than <h3>, but cleaner, because the level is considered as attribute of the heading and fits well into the nesting concept.

Sebastian

[Heydon]

@SebastianZ @nico3333fr

Yes, I believe the proposal is just for when sectioning elements are employed. You would use equivalent heading levels if sectioning elements were not employed.

[AndySky21]

@nico3333fr, is it really necessary to consider such a case? I have been reminded that authors don't read specs and this can be right or wrong, but I strongly think that there are structures whose meaning is unquestionable.

<section>
  <h>Lorem Ipsum<h>
  …
  <h>Dolor si amet<h>
  …
  <h>Consegur<h>
  …
  <h>Blahblah<h>
  …
  <h>Blahblah 2<h>
  …
</section>

Ages of simple markup have taught us that elements of the same type in the same level mean the same, so if authors wants deeper levels they will have to use nesting sections.

Authors are not that dumb. Otherwise structures like nested lists (which present the same issue) wouldn't even be possible. They will understand that the choice is to sacrifice immediacy of semantics (given by numbered headings) or simplicity of markup (and thus nest sections), but not both.

@SebastianZ, I think that using a level attribute would have the same issues of explicit <h#> elements. What happens when content is reused or authors break the order chain? It should be stated that numbers have no value meaning but they only serve for relative ordering. I.E. <h level="y"> is to be considered a deeper outline level than <h level="x"> when x < y, regardless of actual values. This is not a scenario I'd like to see when resources start being shared, because it would involve authors' skills and content stability to a deeper level than I'm going to trust...

[Heydon]

Some thoughts regarding the CSS part:

Obviously, nobody wants to write

section section section h { font-size: x }

for an h4. Also, it becomes highly complex when you have to consider all the combinations of sectioning element, like

section article section h,
article section article h,
article article section h,
section article article h,
article article article h,
etc {
  font-size: x;
}

In which case, I would propose that heading element selectors acted as aliases for nesting depth.

So

h2 {
   font-size: x;
}

would effectively be

h2, 
section h, 
article h, 
aside h, 
nav h {
  font-size: x;
}

[jakearchibald]

Why is this proposal better than the current <h1> + <section> + outline algorithm?

[jakearchibald]

@Heydon https://developer.mozilla.org/en/docs/Web/CSS/:any

[Heydon]

@jakearchibald My first thought is that the "<h1>s everywhere" idea was much vaunted to begin with, followed by widespread retractions when folks worked out that the outline algorithm didn't exist. In which case, maybe there's something to be said for stepping away from that car wreck and getting a new car, to use a mangled analogy.

Yeah, :any() helps, but I think the alias thing would be sweeter (if not likely to incur performance issues).

[jakearchibald]

@heydon I get that the outline isn't implemented, but neither is <h>. This proposal needs to state why it's more likely to succeed than what we already have + implementation of the outline.

[AndySky21]

@jakearchibald, I think that relying upon section + h1 was a mistake because it implied a new use for an existing element. Which proved wrong when h1 headings ended up being used everywhere without the outline algorithm

On the other hand, a brand new element would have no meaning outside of said algorithm or without a proper polyfill, which reduces misuses.

[Heydon]

@jakearchibald Agree, especially since it may be more work. But I think a new element means a clean (conceptual/cognitive?) break. The outline algorithm would work via <h>, where implemented. Where <h> is not implemented, the algorithm wouldn't be either. For me, at least, that's easier to grok than <h1> working differently depending on how/where it is used, but only if the outline algorithm is supported.

[Marat-Tanalin]

@pepelsbey Numbered and levelless headings are just for different usecases. They would just coexist. Numbered headings would continue to be used for continuous texts with no subsections marked-up as explicit sectioning elements (primarily in main content of HTML document) while levelless headings would be useful e. g. for layout blocks (e. g. sections in sidebars) and widgets each marked-up as a separate sectioning element with its own heading that should not depend on where exactly the sectioning element is placed in HTML hierarchy. As noted by @LJWatson, the same block can potentially be reused in different contexts nested differently. Currently, such situation is only partially solvable by using DL/DT/DD (not a numbered heading anyway), but this is still not perfect semantics-wise, and validator complains about that the section lacks heading.

@nico3333fr Each sectioning element should obviously have just one levelless heading. Wrong uses by those who don’t bother to read specs, docs and/or use a validator is not a reason not to use semantics or not to do other clever things in general. Many people use <b></b> instead of headings, and that’s not a reason for those aware of proper headings not to use proper headings.

@jakearchibald One of reasons why it’s undesired to use H1 for each nested sectioning element is that it may be treated incorrectly by search engines that, most likely, do not implement the outline algorithm too, so multiple H1 elements would just ruin SEO by making search engines consider actually-minor headings (e. g. in some aside blocks) as major headings (like first-level heading of main content of webpage).

[jakearchibald]

SEO arguments seem really tenuous to me. Is there any evidence? Surely creating a new tag, which will initially have no meaning to search engines, is at least as concerning.

@Heydon

I think a new element means a clean (conceptual/cognitive?) break

I think we need stronger reasoning than that. If it can be shown that implementing the outline in terms of <h1> would break the web, whereas <h> + outline would be "totes fine", that seems reasonable.

[stevefaulkner]

What would be nice is implementations of the outline algorithm by browsers, without them this effort is doomed to failure just as <h1>'s everywhere has been.

[nico3333fr]

@SebastianZ yes, you are right, that was what I tried to say in my last sentence : we are moving the hx management problem to landmarks management problem.

@Heydon @AndySky21 @Marat-Tanalin yes, I know my example is stupid. However, as MANY sites can't deliver a correct hx structure, we have to consider theses cases (same as people that think that <section> is the new <div> that @stevefaulkner mentionned). I'm sure accessibility experts would have many example of people/websites which are that dumb :)

Other issue : when we insert a h in a classical hx structure (let's say a h3), is it at the same level or a level deeper ?

However, please don't be angry with these stupid examples, the most important is: if the good cases are ok AND the worst cases can be better than actually, that means it is a fucking good idea. :)

[Marat-Tanalin]

SEO arguments seem really tenuous to me.

At least that’s the main reason why I don’t (and not going to) use H1 where I would use a levelless heading. And that’s why DT is my choice for cases when I need a levelless heading.

creating a new tag, which will initially have no meaning to search engines, is at least as concerning.

Given that levelless headings are primarily needed for minor blocks like widgets and subsections in sidebars, treating such blocks less important than they are (like as if there were no headings in them at all) is much less bad thing than treating them much more important than they are actually intended to be. In other words, unimplemented-by-search-engines levelless heading is much better than H1 which is surely implemented by search engines and may be treated wrong.

[LJWatson]

@jakearchibald for a new element to be included in the spec, it has to demonstrate widespread adoption (enough people using the polyfill to convince browsers to implement it natively). Given this, I think search engines would likely factor it into their algorithms?

[Marat-Tanalin]

@nico3333fr

people that think that <section> is the new <div> that @stevefaulkner mentionned

(That was not @stevefaulkner, btw.) I’m not sure incorrect uses of the SECTION element by some people of the same type who uses <b></b> instead of headings is really relevant in terms of general semantics and ways of improving it.

when we insert a h in a classical hx structure (let's say a h3), is it at the same level or a level deeper ?

I would be totally fine if spec would explicitly disallow using more than one levelless heading per sectioning element. And such restriction is probably the only reasonable option.

Levelless heading is a first-level heading for the closest sectioning element that contains it. For other uses, currently available numbered headings should continue to be used.

[Marat-Tanalin]

@stevefaulkner

What would be nice is implementations of the outline algorithm by browsers

It probably makes sense to clarify how exactly the outline-algorithm implementations in browsers would look like and how exactly that could be used UI-wise.

I’m almost sure the algorithm has not been (and most likely not going to be ever) implemented in browsers exactly because its usefulness for end user is unclear, while AT could have their own DOM-based algorithm built-in regardless of whether specific browser implement the algorithm natively.

Actually, the main (only?) implementation that really needs the outline algorithm is search engines and that has nothing to do with whether regular browsers have it implemented.

[jakearchibald]

@LJWatson I totally I agree, and it's why I think the "h1s are bad for SEO" arguments are spurious.

[stevefaulkner]

@Marat-Tanalin Here are some bugs filed about implementing the outline algorithm in browsers: At a minimum browsers would need to implement the algorithm in the acc tree. I suggest that in order to have a chance at making it work practically an API for devs is needed.

• https://www.w3.org/Bugs/Public/show_bug.cgi?id=25003 modify required heading mappings to reflect reality – HTML spec bug
• https://code.google.com/p/chromium/issues/detail?id=365070 expose (heading) level in acc layer based on heading elements outline depth – chrome bug
• https://bugzilla.mozilla.org/show_bug.cgi?id=998590 expose heading level in acc layer based on outline depth not heading numeric value – Firefox bug
• https://bugs.webkit.org/show_bug.cgi?id=131920 AX: expose (heading) level based on heading elements outline depth – Webkit bug
• http://connect.microsoft.com/IE/feedback/details/856898/expose-output-of-html5-outline-algorithm-as-a-dom-method expose output of html5 outline algorithm as a DOM method – IE bug

[Marat-Tanalin]

@stevefaulkner Some specific brief conclusions from what can be read there relative to my question (how exactly the outline-algorithm implementations in browsers would look like and how exactly that could be used UI-wise) would be welcome.

[jakearchibald]

I agree with @stevefaulkner here.

What we need to make <section><h1></section> work:

• Get browsers to implement the outline algorithm.

What we need to make <section><h></section> work:

• Add <h> to the elements spec, including DOM bits.
• Update the parsing spec to cater for <h> (it may be difficult at this stage to make it parse similar to other heading elements).
• Update outline algorithm to cater for <h>.
• Get browsers to implement <h> spec.
• Get browsers to implement the outline algorithm.

Given that the work needed to make <section><h1></section> work is a subset of what's needed to make <section><h></section> work, it's difficult to justify this proposal.

Someone needs to explain why the steps for making <section><h></section> work are more achievable & desirable than <section><h1></section>. If it can be shown that implementing the outline algorithm for <h(n)> would break existing content, then <h> becomes a lot more interesting.

If, however, implementing the outline algorithm for <h(n)> would improve the accessibility of the existing web, inventing a new tag (that wouldn't have that benefit) seems kinda pointless.

[Marat-Tanalin]

@jakearchibald

I think the "h1s are bad for SEO" arguments are spurious.

Please don’t let the SEO term to make you biased. To be clear, I’m not a SEO geek, I just believe that quality ranking in search engines is important in general for all of us who search information. That’s why I don’t want my page to be as relevant by a minor sidebar-section heading as by the real page heading marked up as the first-level heading of the entire page.

[Marat-Tanalin]

@jakearchibald

What we need to make <section><h1></section> work

What we need to make an element work is actually just to add some styles for it. As for default browser styles, display: block; font-weight: bold for the H element would be enough.

Create a spec for <h>.

A whole spec for a single HTML element? Wow.

Update the parsing spec to cater for <h> (it may be difficult at this stage to make it parse similar to other heading elements).

HTML5 parsing is universal, a priori supports any new elements, and does not need to be updated when a new element is introduced except for cases when the new element requires some special parsing rules like for TEXTAREA or TEMPLATE.

Update outline algorithm to cater for <h>.

Be my guest:

“The first H element in the sectioning element is a first-level heading for the closest sectioning element that contains it.”

Get browsers to implement <h> spec.

It does not need to be implemented in browsers for it to be able to be used.

If, however, implementing the outline algorithm for <h(n)> would improve the accessibility of the existing web, inventing a new tag that wouldn't have that benefit seems kinda pointless.

In terms of accessibility, it’s up to AT to implement the outline algorithm or not. This does not depend on what specific HTML element is used as a heading.

[stevefaulkner]

In terms of accessibility, it’s up to AT to implement the outline algorithm or not.

This is not the case, it is up to the browser to implement the outline algorithm to expose the correct heading structure/ levels via the acc APIs in the browser. AT's use the information from the APIs to convey the semantics to the user.

[Marat-Tanalin]

@stevefaulkner Don’t AT have access to DOM at all even if they needed/wanted?

[stevefaulkner]

@Marat-Tanalin depends on OS, Mac OS/iOS none, On windows AT do dependent on browser, e.g. Edge does not expose DOM to AT. Other browsers provide legacy support, but increasinlgy AT are moving away from accessing the DOM as it is not efficient for them. For example NVDA does not access the DOM in Firefox, they do in IE but only as a last resort due to IE's poor acc API implementation. ChromeVox has moved from being a DOM based AT to an acc API AT due to limitations of DOM use.

The article Why accessibility APIs matter may be helpful.

[Marat-Tanalin]

@stevefaulkner Thanks. Fwiw, I believe that a really quality screen reader should not settle for less by just relying on accessibility features provided by browsers, and a custom DOM-based reading algorithm could provide much better user experience for physically impaired people.

Anyway, given that the outline algorithm is not implemented in browsers, classic H1 used for nested sectioning elements is not correctly announced to AT too, so, in terms of accessibility, a new heading element would at least not be worse. But once the new levelless heading element is standardized (but not before), web developers who care about validity could really start using it.

With speculative polyfills for H, we would have either to use DIV with bolt-on ARIA semantic additions (so that validators wouldn’t complain about invalid element), or just to start using the nonstandard element and live with its inevitable invalidity and non-future-proofness. The both polyfill-related options seem suboptimal (and, fwiw, unacceptable for me personally — I would prefer just to continue using DT until H is added to the spec: validator warning is better than error).

[jakearchibald]

@Marat-Tanalin

What we need to make an element work is actually just to add some styles for it. As for default browser styles, display: block; font-weight: bold for the H element would be enough.

But <h1> already has styles, so that's not a good justification for adding <h>.

A whole spec for a single HTML element? Wow.

It doesn't need to be a separate document, but it would need to be equivalent to https://html.spec.whatwg.org/multipage/semantics.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements.

HTML5 parsing is universal, a priori supports any new elements, and does not need to be updated when a new element is introduced except for cases when the new element requires some special parsing rules

So you're saying <h> would behave significantly differently to <h1> during parsing? As in <p><h>Hello</h></p> would produce a different shaped tree to <p><h1>Hello</h1></p>?

“The first H element in the sectioning element is a first-level heading for the closest sectioning element that contains it.”

That's not an outlining algorithm. See https://html.spec.whatwg.org/multipage/semantics.html#outlines

It does not need to be implemented in browsers for it to be able to be used.

If it isn't implemented, what's the point?

In terms of accessibility, it’s up to AT to implement the outline algorithm or not. This does not depend on what specific HTML element is used as a heading.

The browser exposes the AT tree. The whole problem being discussed here is how browsers haven't implemented the outline algorithm, because browsers expose the heading level.

a new heading element would at least not be worse

That isn't true, as <h> wouldn't even be recognised as a heading. Also, "not worse" is not an acceptable justification for a new element.

I could propose a <wombat> element that's like a <span> but about wombats - sure it's no worse than a <span> today, but I need to do better than that. I need to show that it wouldn't break the existing web, and that it'd benefit the web and justify the work needed to implement.

[tomByrer]

I'm torn. In the modern world of component-HTML (Polymer, X-Tags, React, VueJS, etc), there may be times where an article-component should have an <h3> header, but the same article-component may be re-used somewhere else & should have an <h2> header. So a generic <h> tag would be great here. An <h2> hard-coded into component-HTML could be problematic to truly be a reusable component in different scenarios.

But there may be times where a computed header level is a problem, especially if new <div> wrappers are added in the browser page, or if there are even number of wrappers around headers: DOM tree initial rendering:

<div id=articles-wrapper>

    <div id=top-header>
        <h>I'm the Top Header Title</h>
    </div>

    <div class="article">
        <h>I'm the first article</h>
        <div class="article-copy">Lorium Ipsum</div>
    </div>

    <div class="article">
        <h>I'm the SECOND article</h>
        <div class="article-copy">Ipsum lorium</div>
    </div>

</div>

</div>

Triggered re-rendering after plugin ran:

<div id=articles-wrapper>

    <div id=top-header>
        <h>I'm the Top Header Title</h>
    </div>

    <div class="article">
        <h>I'm the first article</h>
        <div class="article-copy">Lorium Ipsum</div>
    </div>

 <div class="router-jump-to-article-plugin">
    <div class="article">
        <h>I'm the SECOND article</h>
        <div class="article-copy">Ipsum lorium</div>
    </div>
</div>

</div>

[jakearchibald]

I'm torn. In the modern world of component-HTML (Polymer, X-Tags, React, VueJS, etc), there may be times where an article-component should have an <h3> header, but the same article-component may be re-used somewhere else & should have an <h2> header. So a generic <h> tag would be great here.

But this is exactly how <section><h1></h1></section> is spec'd to behave. Why do we need a new thing to do the same thing?

[cynthia]

I'm with @jakearchibald on this one. (As in section.h1)

Also, while this might be a stupid point - if a document ends up with the equivalent of <h16>, what should be the browser style for that element? If it stops scaling down after a certain point (given a unstyled document) the visual hints won't be of any help distinguishing the outline level.

Even a logarithmic scale for font sizes will become pretty difficult to read at that nesting level. Considering this proposal makes it easier to make that mistake - especially in a world where people simply copy&paste snippets without thinking too much about the consequences - it seems like bringing in another problem for the sake of getting rid of one.