Add <h> element #774

Closed
jonathantneal opened this Issue Jan 17, 2017 · 186 comments

Projects

None yet

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.

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.

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

Exactly.

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

Collaborator
chaals commented Feb 6, 2017

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 commented Feb 6, 2017 edited

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 commented Feb 7, 2017 edited

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

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 commented Feb 7, 2017

This is quite sensible. 👍

Collaborator
LJWatson commented Feb 7, 2017

Thanks for the proposal and polyfill @jonathantneal

Awesome idea @jonathantneal, seems quite logical!

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

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 commented Feb 7, 2017

@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.

Collaborator
chaals commented Feb 8, 2017

@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?

@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>.

Contributor
stevefaulkner commented Feb 8, 2017 edited

@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.

Contributor

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

Collaborator
LJWatson commented Feb 8, 2017

@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.

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 commented Feb 8, 2017 edited

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 commented Feb 8, 2017

@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 commented Feb 8, 2017 edited

@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 commented Feb 8, 2017

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;
}

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

Heydon commented Feb 8, 2017

@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).

@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.

@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 commented Feb 8, 2017

@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 commented Feb 8, 2017 edited

@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).

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.

Contributor

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.

@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. :)

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.

Collaborator
LJWatson commented Feb 8, 2017

@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 commented Feb 8, 2017 edited

@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 commented Feb 8, 2017 edited

@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.

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

Contributor

@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.

@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 commented Feb 8, 2017 edited

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.

@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 commented Feb 8, 2017 edited

@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.

Contributor

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.

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

Contributor
stevefaulkner commented Feb 8, 2017 edited

@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 commented Feb 8, 2017 edited

@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).

@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 commented Feb 8, 2017 edited

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>

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?

Contributor
cynthia commented Feb 8, 2017 edited by jakearchibald

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.

jonathanKingston commented Feb 8, 2017 edited

After discussing with @jakearchibald one factor to not implement the outline algorithm on <h1-6> could be the impact/improvement on accessibility.
It seems like it would be hard to disprove and I can't find any evidence of anyone suggesting that as a blocker to implementing.

The <h> tag however wouldn't suffer from breaking the semantics of current pages. Unless developers were required to opt-in existing markup to use the outline algorithm on <h1-6> by some boolean on html or similar (<html outline>)?

aardrian commented Feb 8, 2017

@cynthia:

Also, while this might be a stupid point - if a document ends up with the equivalent of , what should be the browser style for that element?

Have the browser set the lowest rank to the base content size, and then scale up from there (whether by n% increments or whatever). So on a page with <h16>-equivalent, an <h1>-equivalent would be far larger than an <h1>-equivalent on a page that only nests to <h3>-equivalent.

Marat-Tanalin commented Feb 8, 2017 edited

@jakearchibald

<p><h>Hello</h></p> would produce a different shaped tree to <p><h1>Hello</h1></p>?

That would be fine. Both are syntactically invalid, and validator would point that out, that’s enough. It’s not necessary to change the parser here. For those who care about validity, possible changes in how browsers correct errors once H is taked into account would break nothing.

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

The point is the ability to use the new element in practice without making HTML invalid. As I said, web developers who care about validity would not use a nonstandard element until it’s standardized. So saying “Use the element with a polyfill, and then we maybe add it to the spec” is a dead-end road. First make the element valid, then we’ll use it.

Contributor
cynthia commented Feb 8, 2017

I'm not sure if I understood @aardrian correctly, but based on my understanding...

Wouldn't that break the layout whenever a new level is introduced? Not always does the original page author have control over what content can be in the page. Your algorithm would effectively bump the font size for everything in the event a unexpected element is put into the content.

Blog posts affecting blog template/theme design doesn't look like something anybody would want.

@tomByrer Fwiw, unless your DIVs are supposed to be converted automatically to some sectioning elements like SECTION, your code does not make sense since it does not contain sectioning elements: DIV is semantically transparent, so you effectively have just invalid multiple H elements without even a sectioning container. For even more clarity:

<section>
    <div>
        <h>This heading is for `SECTION`, not for `DIV`</h>
    </div>
</section>

@Marat-Tanalin

The point is the ability to use the new element in practice without making HTML invalid.

The benefit of using the element in practice is still missing from your argument, and that's really the most important part.

Marat-Tanalin commented Feb 8, 2017 edited

@jakearchibald

The element is valid per spec → the element is used by web developers → the element support is implemented in browsers (incl. accessibility-wise).

aardrian commented Feb 8, 2017

@cynthia

Wouldn't that break the layout whenever a new level is introduced?

Yes, it could if the site developer doesn't use CSS at all. I suspect, however, that a developer would pin all <h> elements to set size in certain contexts. In a nested comment stream for example, visually showing the hierarchy with font size changes is likely unnecessary.

Collaborator
LJWatson commented Feb 8, 2017

@jakearchibald the problem with the existing <h1> outline algorithm thing, is that it would instantly break perfectly good ranked heading hierarchies out in the wild. The <h> element would not do that.

@LJWatson got any examples of cases it'd break? But yeah, if implementing the outline breaks more than it fixes, <h> may make sense.

@Marat-Tanalin

The element is valid per spec → the element is used by web developers → the element support is implemented in browsers (incl. accessibility-wise).

That isn't what happened with the outline algorithm.

Collaborator
LJWatson commented Feb 8, 2017 edited

@jakearchibald any site that uses the following pattern would break I think:

<main>
<article>
<article>
<h1>...</h1>
...
</article>
</article>
</main>

It's a pattern I come across pretty regularly (possibly because my screen reader identifies the sections more readily than is apparent visually). Typically, the only example I can call to mind now though is html5doctor.com, which has something like:

<main>
<article>
<article>
<header><h1>...</h1></header>
...
</article>
</article>
</main>

If I understand things correctly this would turn the present <h1> into an <h3>.

@jakearchibald The outline algorithm is unneeded for web developers and most users. What’s unneeded is rarely implemented.

@Marat-Tanalin that brings me back to: The benefit of using the element in practice is still missing from your argument, and that's really the most important part.

@jakearchibald Thank you for your attention.

@LJWatson I wonder if the outline could fix cases like this. If h3 is the topmost heading, reduce all heading levels by 2.

I guess there could be cases that are just plain broken. But if implementing outline makes 90% of the web better and 10% worse, it might be worth it.

AmeliaBR commented Feb 8, 2017

I think this discussion makes it clear that there needs to be a concerted effort to (a) Fix and (b) Implement the outline algorithm. And by "fix", I don't mean write up something theoretically nice, I mean with careful consideration of existing usage patterns like those highlighted by @LJWatson.

If the only way to fix it effectively is to introduce a new element that doesn't bring along any semantic baggage, that's worth considering. In contrast, if it is possible to create an outline algorithm that correctly exposes the implied/visual semantics of the vast majority of web pages, without introducing a new element, that should be preferable.

But while many devs implicitly rely on context to define the structure of their headings, I fear that other devs are using h1, h2, h3 as meaningful numbered levels, irrespective of their (possibly incorrect) use of sectioning elements. Numbered headings (and their default styles) may be used to imply relative importance of disjoint sidebars and sections, unrelated to a single document outline.

There isn't an easy, automated way to test how many sites would break (versus how many would be fixed) by applying the outline algorithm as written. The best approach I can imagine would be a crowd-sourced initiative to ask people to compare alternative outlines for a site & say which one makes more sense. But without some sort of data either way, it will always be easier to argue for a new element than for changing the behavior of existing elements.

Even if headings & sections are being used a little incorrectly, it might be better to encourage developers to fix that. Eg, we got the majority of developers to fix their use of <table> rather than write-off <table> and spec <tableForRealsThisTime> to be the same thing.

AmeliaBR commented Feb 8, 2017

In response to @Heydon's "thoughts regarding the CSS part":

I think a key to getting outline algorithms used correctly (with or without <h>) would be a CSS :level(n) or :heading-level(n) pseudoclass selector.

Web authors could chose whether to style an element based on its context (e.g., heading for the article always looks the same regardless of whether its the main article or in a sectioned index page), or whether to style it based on the computed heading level. And because computed heading level would be exposed to visual-focused devs, those devs may be more likely to fix their markup, improving accessibility.

jakearchibald commented Feb 8, 2017 edited

My frustration with some of the discussion here is that the current implementation of headings, in the real world, is being compared to a future world of perfect implementations and usage of this new tag.

With that in mind, do these action items sound fair?

  • Investigate a11y/SEO problems caused by implementing the outline algorithm against the current web.
  • Compare any problems to those of introducing a whole new tag, which will be unknown & without any semantics to current user agents, and carry the same risk of being introduced without a correct implementation of the outline.
  • Compare the effort of teaching developers to use a new tag, to the effort of teaching them to fix their usage of current tags (as we did with <table>).

If we can't fix <h1> considering the above, then we can look at introducing something like <h>, and restricting the outline to it. Or, something like adding an outlined attribute which would opt into the outline for that element's descendants.

WebDevCA commented Feb 8, 2017 edited

@nico3333fr said:

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.

This is exactly what I have been arguing for years at different sites and discussion boards. I find exceedingly few instances where web developers actually know how to provide a correct Hx structure for their document. A lot of them don't know that 6 comes after 5 which comes after 4 which comes after 3 which comes after 2 which comes after 1. Sometimes there's no sense whatsoever to the structure they use, often skipping in a document from an H1 to an H4. I guess they skip over H2 and H3 to an H4 because they like the styling that browsers apply to H4's? Maybe? Another problem is developers loving to use H1's all over the place so they can try to up their "Google juice." Another problem is tagging header content without any Hx tag at all, but possibly something like <p><b></b></p>. Another problem is developers thinking that a website title and an article title are of equal weight (hint: they're not). And another problem is developers just poorly structuring all of their code. And I see these problems on websites coded by actual developers; I'm not just talking about sites generated by people who don't pretend to be coders. We're coders (implying that we're supposed to be on the smart side), but so many of us don't even know how to put 1-6 in order.

So I concur with @jakearchibald's concern that adding a new tag may only increase confusion and with @nico3333fr's concern that browsers may not actually know how to correctly number an unnumbered h tag or set of such tags.

@WebDevCA

browsers may not actually know how to correctly number an unnumbered h tag or set of such tags.

There is no need for any implicit numbering of levelless heading. It’s enough just to know that levelless heading for its closest sectioning container is like the TITLE element for entire HTML document. There is just a section and its heading, and there are no numbers.

acjay commented Feb 9, 2017

@AmeliaBR

I think a key to getting outline algorithms used correctly (with or without ) would be a CSS :level(n) or :heading-level(n) pseudoclass selector.

Or :outline-depth(n)!

Contributor

@Marat-Tanalin

There is no need for any implicit numbering of levelless heading.

This is incorrect, unless the nesting level of a heading is exposed via acc APIs (as they are now) then it will be a flat outline.

jakearchibald commented Feb 9, 2017 edited

Ideas for testing the HTML outline algorithm

Take some sort of meaningful sample of the most-popular pages on the web, apply the HTML outline algorithm, and find out:

  • How many pages change heading structure as a result of the outline algorithm?
  • How many pages start with an h1 currently, but no longer start with an h1 after applying the outline? However, it's difficult to assess how bad this is.
  • How many pages improve with the outline vs how many get worse.

That last one doesn't seem automatable, and I don't have any strong ideas. We could create something like an extension or a bookmarklet that toggles the outline and ask AT users to test - @LJWatson does that sound useful?

Alternatively we could crowdsource it, by creating a "game" where the page presents a random link from the dataset, and two heading outlines, one using the flat system, the other using the outline algorithm, and ask people to vote on which outline is the most accurate.

@stevefaulkner is there any prior art here?

Heydon commented Feb 9, 2017 edited

Even if headings & sections are being used a little incorrectly, it might be better to encourage developers to fix that. Eg, we got the majority of developers to fix their use of <table> rather than write-off <table> and spec <tableForRealsThisTime> to be the same thing.

@jakearchibald I don't think <table> is a fair comparison to the <h1> situation. Tables were simply being used in a way that was inappropriate. Regarding <h1>, authors do — frequently — use it inappropriately too, but that's orthogonal to the issue of introducing a new use case / behavior for an old element. It's not like <table> was for layout then somebody thought, "let's make it work for actual table data too."

Aside from that, I think the criteria are sound.

I'm not sure if <h> is worth the investment, but the mixed messages authors have been given about <h1> RE the outline beleaguer it, to say the least.

jakearchibald commented Feb 9, 2017 edited

@Heydon the outline doesn't break correct usage of flat <h1> etc, it only breaks if the outline is used incorrectly, as shown in #774 (comment).

I'm not sure if <h> is worth the investment, but the mixed messages authors have been given about <h1> RE the outline beleaguer it, to say the least.

Again, this is comparing the current reality to a perfect future world. There's nothing to say that browsers wouldn't make the same mistakes with <h> + outline as they have with <h1> + outline. We must make comparisons on equal grounds - if we're going to talk about a perfect future implementation of <h> + outline, we must compare it to a perfect future implementation of <h1> + outline, unless we can show that isn't possible.

The only thing that can beleaguer <h1> + outline is evidence.

@jakearchibald

Investigate a11y/SEO problems caused by implementing the outline algorithm against the current web.

One thought : even if I'm not working for Google/etc. and not speaking for them, neither as a SEO expert (I'm more interested in accessibility), I fear the SEO point of view could be negative for the h tag : search engines will have to implement too the outline algorythm (which makes it really critical), in order to calculate the correct structure of the page (to know which h has the most important weight, key words, etc.).

I'm almost sure they can do it, not sure they will do (and as said above, the outline algorythm is really critical).

Heading element levels stopping at 6 is quite arbitrary, so it seems like the <h>-element should have been there from the beginning, with a level attribute (a proxy for the aria-level attribute). <h1-h6> as a concept should be deprecated, there are no other elements defined with numbers in such an arbitrary manner.

Regarding incorrect usage, that happens now with <h1-h6>, will happen with <h>, will happen regardless of browsers correctly implementing document hierarchy, etc. That should not be an argument for or against this proposal.

A much stronger argument for, based on usage, is the fact that component-based authoring of web pages, and content management systems, frequently cause problems with the hierarchy of headings due to not knowing in which context the sectioning element will be used. With an <h>-element, this will automatically work itself out; the sectioning element's heading level is agnostic on a component-level. This provides much-needed flexibility.

Implementing <h> will force authors to use the sectioning elements correctly, which should simplify the browsers' job of figuring out the document hierarchy.

It may be radical, but it is also right.

Heydon commented Feb 9, 2017 edited

Again, this is comparing the current reality to a perfect future world. There's nothing to say that browsers wouldn't make the same mistakes with <h> + outline as they have with <h1> + outline.

To be clear, I was talking about author mistakes, not browser/vendor mistakes. We told authors they could use <h1> with sectioning elements and create an outline. Then we told them they couldn't. Now we'd be telling them they can again.

if we're going to talk about a perfect future implementation of <h> + outline, we must compare it to a perfect future implementation of <h1> + outline, unless we can show that isn't possible.

It's necessarily not possible, because <h1> has an identity and legacy, and <h> does not. I'm not sure how one would measure that difference and provide evidence, but that's not to say it isn't there.

The current process of figuring out the appropriate “rank” of a heading is as unnecessary as requiring <li> to be <l1-n>.

It may not be "unnecessary," but optional as the tabindex attribute... In the case of an <h> element, may be something like a level="1-n" attribute can solve it...

<section>
	<h>heading level 1</h>

	<section>
		<h>heading level 2</h>

		<section>
			<h>heading level 3</h>
		</section>
	</section>

	<section>
		<h>heading level 2</h>
	</section>
</section>

<section class="modal">
	<!-- Equivalent to <h3> element -->
	<h level="3">heading level 3</h>
</section>
jakearchibald commented Feb 9, 2017 edited

@nico3333fr

I fear the SEO point of view could be negative for the h tag : search engines will have to implement too the outline algorithm

Yes! I could hug you! This is exactly what I mean when I say "Compare any problems to those of introducing a whole new tag, which will be unknown & without any semantics to current user agents, and carry the same risk of being introduced without a correct implementation of the outline."

Without evidence, it's unreasonable to expect <h> + outline to be better implemented than <h1> + outline.

<h> would face a worse chicken & egg problem. If you use <h1> + outline in a user agent that doesn't support the outline (as in, all browsers) at least it falls back to a heading. <h> would fallback to a <span>. We'd have to recommend against using it until all browsers & search engines adopted it, but why would they adopt it if no one was using it?

@DiegoLopesLima we could map the attribute level="x" to aria-level="x" :)

@Nettsentrisk

Heading element levels stopping at 6 is quite arbitrary, so it seems like the <h>-element should have been there from the beginning, with a level attribute (a proxy for the aria-level attribute). <h1-h6> as a concept should be deprecated, there are no other elements defined with numbers in such an arbitrary manner.

It may be radical, but it is also right.

Stating that something's "right" isn't an argument. We need evidence.

You're right when you say <h> should have been there from the beginning, but we are not at the beginning. But there was already an attempt to change this, which failed, because reinventing the web in backwards-incompatible ways isn't as good as incremental non-breaking changes. HTML5 on the other hand tried to introduce the outline semantics but in a kinda-more compatible way.

@Heydon

I'm not sure how one would measure that difference and provide evidence

Did you see #774 (comment)?

Contributor

The big issue to me would be mixed mode documents, particularly considering JS libraries or components and content brought in from outside the site itself. If a site is mixing h1 used via the outline algorithm and h1 used via the traditional 1-6 how do you display or announce to AT a given header? What about hx elsewhere in that document?

The problem is that the h outline algorithm is not the same as the 1-6 one and a choice would need to be made as to which algorithm should be followed. Do we bring in a new explicit way to opt in to the algorithm, or define heuristics as part of the algorithm to pick which one we use? If the latter then having h explicitly is helpful in saying that there are headers intended to be using the new outlining.

Letting both algorithms exist will make the transition easier.

Part of the reason "h1 everywhere" failed is the completely conflicting information it gave authors. Trying to go back to that again is going to fail as authors will now have heard "Use h1-6 to structure your document", "Now just use h1 everywhere and section elements", "Forget that, back to 1-6", "We're doing h1 again".

I think being able to go "You can use the existing h1-6 or drop the numbers and pick sectioned h" will have more success with developers.

Collaborator
chaals commented Feb 9, 2017

[meta…]
Hey folks,

it might help people who come to read this already long thread if people tried not to repeat comments - instead give thumbs up or down an existing one...

Breaking up multiple comments into rational chunks would also make that easier.

@jakearchibald

reinventing the web in backwards-incompatible ways isn't as good as incremental non-breaking changes

By deprecating (but not removing) <h1-h6> and implementing <h> you would allow previously written documents to work fine, but progressively move on to the new paradigm.

<h1-h6> could be interpreted by browsers as <h level="1"> etc. (depending on context) for backwards compatibility.

@Nettsentrisk see #774 (comment)

@chaals if you agree with #774 (comment), evidence gathering could be split off into a new focused thread.

Alohci commented Feb 9, 2017

Question: If the markup is this:

<body>
   <section>
     <h4>Cats</h4>
     <section>
        <h>Kittens</h>
     </section>
  </section>
</body>

What would the computed level of the h element be?

@jakearchibald, thanks a ton for all of your questions. I’ve created a repository to host tests and help us gather evidence. It may be far from perfect. I’ve invited yourself and @LJWatson as collaborators, but PRs are welcome from anyone.

https://github.com/jonathantneal/outline-tests

And here’s an example of a <h> heading test running on GitHub pages.

https://jonathantneal.github.io/outline-tests/tests/headings/h.html

That repository might also serve as a place for evidence gathering threads.

@Alohci you can use https://gsnedders.html5.org/outliner/ to figure this out, assuming <h> will have identical behaviour to <h1> in terms of outlining.

With your example, the outline would be

  • missing heading
    • Cats
      • Kittens
therealglazou commented Feb 9, 2017 edited

Back in april 2003 (yes 2003), I did comment on xhtml2's h being bad CSS-wise. My comment still stands for the current proposal. The number and complexity of rules targetting h elements in the UA stylesheet will be a bit of something...

Alohci commented Feb 9, 2017

@jakearchibald - But that would mean integrating the h element into the existing outline algorithm. If the browsers won't implement the existing algorithm, how is making it more complicated going to help?

First off, great discussion.

From my perspective, it seems to me that we would be back-tracking. The <h1> through <h6> give us those implied semantics we need. Based on the example I saw at https://jonathantneal.github.io/outline-tests/tests/headings/h.html , using an <h> element would require developers to add their own attributes to tip-off assistive technology. Why forego the ease and effectiveness of using the headings provided to us?

I also find the argument of likening <h1-6> to writing <l1-n> isn't entirely accurate since an <li> has no more priority than the one before or after.

Is your goal to get an<h> in conjunction with <h1-6> elements?

@Nettsentrisk Deprecating <h1-n> and implement <h> using optionally aria-level (as @nico3333fr suggested) to replace <h1-n> and provide more levels or level change (for example), seems to be a better idea than specify level on tag name...

In my opinion, it definitely not a good idea to deprecate and simply use levels. This would cause confusion as in which level should be assigned which CSS class. Moreover, there are could be more than 7 levels and managing it would definitely be a pain. Present designing trends are far away from this approach and the development needs a toolkit of the custom styled heading which could be used wherever they want. Depreciation will just create a ruckus in the present HTML hierarchy.

@stevefaulkner

There is no need for any implicit numbering of levelless heading.

This is incorrect, unless the nesting level of a heading is exposed via acc APIs (as they are now) then it will be a flat outline.

Forget about outline, it’s fictious and unneeded (and probably even harmful by preventing us from thinking open-mindedly). A sectioning element and its levelless heading are unambiguously interconnected and this interconnection has clear semantic meaning (and may be useful for AT in particular) regardless of where the sectioning element is placed and whether other (be it parent or sibling) sectioning elements have their own headings.

@therealglazou

The number and complexity of rules targetting h elements in the UA stylesheet will be a bit of something...

That’s either not a real issue or an issue of CSS and not of HTML.

Contributor
stevefaulkner commented Feb 9, 2017 edited

@Marat-Tanalin

Forget about outline, it’s fictious and unneeded (and probably even harmful by preventing us from thinking open-mindedly). A sectioning element and its levelless heading are unambiguously interconnected and this interconnection has clear semantic meaning (and may be useful for AT in particular) regardless of where the sectioning element is placed and whether other (be it parent or sibling) sectioning elements have their own headings.

Currently using h1-h6 a screen reader user gets information about the role (heading) and the level (number).

A JAWS user, for example can use this information and navigate via the following:

  • List Headings INSERT+F6
  • Next Heading H
  • Prior Heading SHIFT+H
  • First Heading ALT+INSERT+HOME
  • Last Heading ALT+INSERT+END
  • Next Heading at Level - number keys 1 through 6
  • Prior Heading at Level SHIFT+1 through 6
  • First Heading at Level ALT+CTRL+INSERT+1 through 6
  • Last Heading at Level ALT+CTRL+INSERT+ SHIFT+1 through 6

What you appear to be proposing is the the <h> element will not expose a level, which will be unacceptable to many.

This has some serious consequences in digital publishing as a single publication can be split across multiple html pages and viewing any single page alone will not be able to figure out the heading level without first processing all pages before it. If it requires an aria-level to always be associated with this, then this could solve this issue but wanted to bring up this potential issue as the Digital Publishing WG is just getting established.

jonathantneal commented Feb 9, 2017 edited

@Marat-Tanalin, @stevefaulkner, this proposal and hfill are intended to expose information to a11y tools. I would really like to see the test results of <h> (with hfill active). Time permitting, I will test your navigation example today/tonight. Have a screen recorder recommendation so I may share the raw results with everyone?

@Marat-Tanalin this is exactly the argument the XHTML2 WG used. But if the markup cannot be easily rendered or raises issues for copy/paste, pagination or more, then the proposed solution is just not practical as an element of the Web platform. Html does not live isolated.

@clapierre this depends how publications are split. If they're split by "page" it's a problem. But that's a weird split as the concept of a page differs from device to device.

If they're split logically, like by chapter, it isn't a problem. The outline knows the headings are scoped to their body.

Marat-Tanalin commented Feb 9, 2017 edited

@therealglazou We should probably just separate default browser styles from (unfortunately nonexistent) semantic view. Default user styles are rarely used as is, they are almost always reset and overridden according to a custom design. In terms of default browser styles, display: block; font-weight: bold (and optionally some vertical margins) for levelless heading would be enough. With a potential semantic view (not to be confused with default browser styles), we could visualize each sectioning element e.g. with a border and some padding, so that nesting is obvious regardless of styles (e.g. font size) of levelless headings themselves.

Marat-Tanalin commented Feb 9, 2017 edited

@stevefaulkner Thanks for your useful thorough competent information.

What you appear to be proposing is the the <h> element will not expose a level

I see what you mean. Maybe a smart algorithm that exposes just sections that have headings and skips sections that don’t would make sense. I’m not sure why a levelless heading could be different from H1 in this regard though, given that H is basically just an equivalent for H1 (just with no undesired legacy meaning). Btw, do screen readers currently expose sections (not headings) in any way?

viT-1 commented Feb 10, 2017 edited

Nowadeays we can use label instead of nesting H1
<label role="heading">Some heading</label>

Contributor
stevefaulkner commented Feb 10, 2017 edited

@viT-1
note: use of role on the label element is non-conforming: http://w3c.github.io/html-aria/#label

viT-1 commented Feb 10, 2017 edited

@stevefaulkner It is a reason to think about fixing documentation for label ;)

Contributor
viT-1 commented Feb 10, 2017 edited

@stevefaulkner

The label element represents a caption in a user interface

<section>
  Some content
  <label for="content_1">Another caption</label>
  <section id="content_1">Another content</section>
</section>

<section>
  Some content
  <section id="content_1">
    <label for="content_1">Another caption</label>
    Another content
  </section>
</section>

I don't quite understand how the W3C spec is to be used as a document, so forgive my ignorance, but isn't it no longer in the spec to use nested <h1>s and rely on the document outline algorithm? I get that an important step towards either nested <h1> or <h> tags is to get browsers and screen readers to implement the outline algorithm, but why would they implement it if it's no longer part of the spec? Is the spec a recommendation of how HTML should work, or is it a recommendation of what developers should be writing now?

It was bizarre to do course on HTML5 from W3C, which recommended using infinitely many nested <h1> tags everywhere, only to find out later that W3C no longer wants this to be part of the spec. I get that we shouldn't be using things that aren't widely implemented – especially if it will hurt people using screen readers the most – but it's my (probably poor) understanding that W3C has backtracked and no longer intends to have nested <h1>s implemented by anyone. This is frustrating, because if I'm working on a specific <article> partial, I don't want to have to calculate how many levels deep it is in my app, I just want to plop an <h1> (or <h>) in there and have it work correctly. If I'm expected to do the H# calculation manually (as W3C recommends now), I'll probably get it wrong, and it will hurt the people who rely on H levels being correctly implemented. And, as has been mentioned above, the H# of a heading can change depending on where they partial is included in the document, which makes it difficult if you're using a partial in multiple contexts.

Getting nested heading tags working would be a godsend both for devs and for people using screen readers. I have no idea how I can contribute to making this happen. Do we need to start a posse to bully browser and screen reader devs? Sign me up.

dskoziol commented Feb 10, 2017 edited

For anyone concerned about how <h#> tags currently affect (and how incorrectly implemented ones would negatively affect) SEO, I tried doing some research a few months ago, and I feel like the answer is: not much.

Story: one of the guys at my work suggested we use only one <h1> per page for SEO purposes, and I thought "hey, the spec recommends infinitely many if you nest sections correctly!" (or at least it used to), so I decided to do some research. I first looked to see if Google recommends nested <h1>s or using all the H levels, and I really couldn't find anything useful/definitive. Bing seemed to recommend the old H level approach. I then decided to look at how many <h1> tags are used on popular websites, and that's where it got interesting. My results (from a few moths ago):

Nested <H1> Way (using HTML5 <section>s, <article>s, etc.)
Bloomberg: 86 <H1> tags
Pitchfork: 6
Basecamp: 9
The Economist: 41

One H1
Smashing Magazine: 1, but HTML5 with sectioning for lower-level H# tags
Wikipedia: 1, no sectioning elements, layout done with tables (lame)
Mozilla: 2, ok so this actually had a <nav> element with an <h1> in it, but other than that it was strict about using only one <h1>

No H1 (H1's don't matter?)
Youtube: 0
Metacritic: 0
Ars Technica: 0, but there are some HTML5 sectioning elements
Craigslist: 0
Twitter: 0

H1s used seemingly incorrectly (H1's don't matter?)
Reddit: 6, but doesn't use HTML5 sectioning elements
Rotten Tomatoes: 5, no sectioning elements
Yahoo: 2, but not used for headings, no sectioning elements
StackOverflow: 1 on homepage (old non-HTML5 way), but 28 on jobs page without sectioning (incorrect)
Bing: 1, not a heading (used incorrectly)

Sorry if all that seems unrelated to the topic at hand, but my conclusion from that is that if <h#> tags are used at all by Google or other search engines for ranking, then they're probably a very weak ranking factor, because there are a large amount of hugely popular websites that do well on Google Search but implement <h1> tags terribly or not at all.

So if we're discussing the merits of nested <h1> or <h> tags, then SEO should probably not be a concern. Accessibility, on the other hand, is definitely a concern. But I would leave SEO out of the discussion. Does that make sense?

Contributor
stevefaulkner commented Feb 10, 2017 edited

@dskoziol
The outline algorithm is still in the spec in the same place it always has been. There has never been any requirement on browsers to implement the outline algorithm. What has changed in the spec is authoring advice to discourage developers from using <h1> everywhere as this has a negative impact on users who actually get the semantic information conveyed by h1-h6. The advice was based on the premise that software would implement the algorithm, it has proved false and so the spec has moved to removing advice based on this unicorn feature.

Note that the outline algorithm does not and has never relied upon the use of all <h1>'s. The outline can be calculated with any combination of h1-h6. for example:

this would produce exactly the same outline:

<body>
<h6> heading level 1</h6>
<section>
<h4>heading level 2</h4>
</section>
</body>

as this:

<body>
<h1> heading level 1</h1>
<section>
<h1>heading level 2</h1>
</section>
</body>

So if you use h1-h6 correctly, in conjunction with sectioning elements, you end up with a structure that both conveys the correct semantics in reality, right now and something that could convey the correct semantics if the outline algorithm was implemented.
For example:

<body>
<h1> heading level 1</h1>
<section>
<h2>heading level 2</h2>
<section>
<h3>heading level 3</h3>
</section>
</section>
</body>
dskoziol commented Feb 10, 2017 edited

@stevefaulkner : Thank you for the clarification.

There has never been any requirement on browsers to implement the outline algorithm.

Is there eventually going to be a push to get browsers and assistive technology user agents to implement the outline algorithm? How does this adoption typically work? What "made" them implement <header>s, <section>s, or other newer HTML elements in the first place?

Marat-Tanalin commented Feb 10, 2017 edited

@dskoziol

I then decided to look at how many <h1> tags are used on popular websites

I wouldn’t rule out a possibility of that major search engines have some special manually added tweaks for popular sites (thus making indexing less sensitive to wrong semantics specifically on those sites), while such tweaks may not be applied to much less popular sites with their own (unknown in advance) semantics-related errors. So it’s probably not quite correct to draw conclusions based solely on popular sites.

Collaborator
chaals commented Feb 11, 2017

Like @jakearchibald I work for a search engine. I would rule out efforts to reverse-engineer ranking algorithms as a useful way to determine what markup should work. Those algorithms are secret, and change unpredictably, so guesses about them are a very poor basis for sound decision-making.

Focusing on the problems we can clearly describe, and the clearly discernible merits of solutions, is likely to give us better results.

Contributor
stevefaulkner commented Feb 11, 2017 edited

@dskoziol wrote:

Is there eventually going to be a push to get browsers and assistive technology user agents to implement the outline algorithm?

There has been pushes to get browsers to implement the outline algorithm for years (see links in #774 (comment)) this has been unsuccessful so far. 'assistive technology' don't need to implement the outline algorithm, it the browsers that need to and expose the resulting semantics in the browser accessibility tree.

What "made" them implement <header>s, <section>s, or other newer HTML elements in the first place?

bugs were filed. The implementation of these elements does not involve much though, comparatively.

Collaborator
chaals commented Feb 11, 2017

Problem: The outline mechanism as currently written makes mixing messy, so inserting content that uses the h1-everywhere model doesn't work anywhere there is an h[2-6]. This makes transition complicated.

Markup like <h1>one</h1><h2>two</h2><section><h1>what level?</h1></section>

I believe gives an outline of:

level 1: one
  - level 2: two
level 1: what level?

It also looks like that with the CSS-based presentation browsers have today.

Given that using the h1-everywhere model currently doesn't work (giving different results visually and through a screenreader, for example) this seems like a big transition problem - an important use case for "auto-calculated nesting" is to allow "3rd-party" content to fit in with the right heading levels being applied, but that will only work if authors make the unreliable leap to using h1-everywhere.

Making <h> work involves a minor change to the algorithm, where an h element in an implied section has the same rank as the preceding heading, and in an explicit section has a lower rank. This would not break any existing content that relied on the algorithm, but allows for a clean transition to incorporating outlined content using <h> into existing content.

It doesn't deal with incorporating existing content into "new-style" content - that would require a further tweak where <h> gets a slightly more magical ranking that is higher than any subsequent heading, so that

<h1>one</h1>
  <section><h>two</h>
    <section><h1>what level?</h1></section>
  </section>

gives an outline of:

level 1: one
  - level 2: two
  -  - level 3: what level?

Without the extra tweak, that would still give the same result as if the second heading were an h2 in the current version.

Collaborator
chaals commented Feb 11, 2017

@stevefaulkner wrote:

@dskoziol wrote:

Is there eventually going to be a push to get browsers and assistive technology user agents to implement the outline algorithm?

There has been pushes to get browsers to implement the outline algorithm for years (see links in #774 (comment)) this has been unsuccessful so far. 'assistive technology' don't need to implement the outline algorithm, it the browsers that need to and expose the resulting semantics in the browser accessibility tree.

Browsers do implement an outline algorithm, but unfortunately very badly: They have a stylesheet-like mechanism that makes nested h1 elements successively take on the styles of lower ranked headings according to the nesting level.

The result looks right, but it doesn't match the algorithm specified as I understand it, and in any event the semantics don't match the visual presentation, so working with the outline is a mess (automatic reasoning is effectively non-deterministic, to use fancy words).

So it is important that authors avoid triggering the browser implementation.

What "made" them implement

s, s, or other newer HTML elements in the first place?

bugs were filed. The implementation of these elements does not involve much though, comparatively.

In general, bugs need to be filed, but also browsers need to have some interest in implementing things. This means they need to be obviously solving a relevant problem, not introduce problems of compatibility, performance, maintainability, etc.

Even then, as with the existing outline implementation, it can go wrong. Browsers aren't magic, they are products made by companies to meet corporate goals.

Contributor
stevefaulkner commented Feb 11, 2017 edited

Browsers do implement an outline algorithm

I meant one that exposes useful, meaningful semantics, or rather the one described in the spec

axelboc commented Feb 12, 2017 edited

Hi there, I'm just a random developer, so my opinion has little relevance to this whole conversation, but I thought I'd share it nonetheless. To me the ideal h element would simply be a minor heading.

The great thing about HTML is that it's simple (or at least it used to be), but many of the comments in this thread, especially those relating to the outline algorithm, seem to want to make it more complex. Just like, to me, cite is the only logical way to reference the author of a quote inside a blockquote, h1 is the only logical way to tag the main heading of a page... and nothing else. Call me backwards-thinking, but I will never use h1 as a section heading, ever.

As mentioned in other comments, many developers tend to use b or strong to mark up headings in sidebars and listings, when they can't be bothered figuring out which level they're supposed to be or don't want to have to override all the styles that come with h2, h3, etc. on most websites. Like it or not, most developers don't know or care about HTML (or can't because of deadlines or legacy codebases), and often go for the solution that requires the least amount of effort and adds the least amount of complexity to an already-unmaintainable codebase. The great thing about strong is that it never comes with CSS baggage--font-weight: bolder (or bold), that's all it does!

What I'd like to see is an element that comes between strong and hx in terms of semantics: more than emphasized text, but less than a document heading: call it minor heading, local heading, or whatever you want. In terms of styling, I'd see UAs bringing to the table display: block, font-weight: bolder and the same margin as paragraphs--basically an h4 without the semantic complexity or author CSS baggage.

Sure there is always a risk that this new element would be misused, for instance in place of every heading on the page. Without a complex outline algorithm as suggested by some, this would obviously be disastrous for the semantics of a page. However, I think this is very unlikely to happen simply because of how ingrained the concept of h1, h2, h3, etc. is among developers. I don't have any evidence to support this, of course, but I believe that the semantic gain of switching some of those b's and strong's to h's would far outweigh any misuse of the tag.

viT-1 commented Feb 12, 2017 edited

@axelboc I think that the tag "label" less likely to use, and therefore many web-developers had forgotten about it. Tag "label" has more semantic meaning than tag "strong" or "b". Tag "header" in html5 is used as heading container like "div class='header'", therefore not suitable for solving the problem.

I suggest to give more promotion to the tag "label" instead of h-x. This solution is backward compatible with html4.

Contributor
stevefaulkner commented Feb 12, 2017 edited

I understand that people think there is a need for a better method of representing headings than is currently provided. Adding a new element will not change the underlying issue i.e. the outline algorithm is not implemented. I strongly suggest that getting implementations of the algorithm in browsers will resolve the current issues, with or without the addition of a new element, as the algorithm defines the level of a heading (h1-h6) based on it's explicit and implicit nesting level. Having said this, I also believe that as written the outline algorithm incorrectly takes into account sectioning elements without headings as effecting the outline depth of headings nested more deeply:

<body>
<section>
<section>
<section>
<h4>I am a heading with a level of 3</h4>
</section>
</section>
</section>
</body>
SelenIT commented Feb 13, 2017 edited

What about reviving the hgroup element (still existing in WHATWG version of the spec and many old books/articles), with the following additions?

  • allow it to contain just phrasing contents (e.g. <hgroup>This is <em>just</em> a heading</hgroup>);
  • broaden the definition to 'The hgroup element represents the heading of a section, which consists of the content of the hgroup element';
  • make hgroup the explicit switcher of the outline algorithm.

As a result, all h1-h6 elements not wrapped in hgroup would contribute to the old HTML4-style outline (as they do in reality). All existing hgroups with their content (if any) would contribute to the HTML5-style outline as described in the WHATWG spec and pre-2013 HTML5 books and tutorials (i.e. as intended by authors). New documents would be able to use <hgroup> without hn children and still get the advantages of the new outline algoritm. And browsers wouldn't have a dilemma of delaying support of the new algoritm or 'breaking the web' with backwards incompatible changes.

Among other things, this solution would also result in eliminating one of the most annoying and confusing discrepancies between W3C and WHATWG versions of the spec (assuming that WHATWG makes the corresponding changes in their hgroup definition:).

@SelenIT

browsers wouldn't have a dilemma of delaying support of the new algoritm or breaking the web with backwards incompatible changes

We don't know if that's an actual dilemma. We should take the steps that potentially improve the existing web #774 (comment).

@stevefaulkner I guess we have the opportunity to tweak the outline algorithm now.

@stevefaulkner, @jakearchibald, for tweaking the spec’s outline algorithm, I’ve started #794.

@SelenIT, IMHO apart from the fact that it would imply a new use for an element which could break the (incorrect and probably hasty) use of hgroup as originally specced by WHATWG, the name itself of hgroup would result in confusion, as it would no longer group anything.

SelenIT commented Feb 13, 2017

@AndySky21, it would still group a run of phrasing content together as a single heading — the same way as it groups several elements as a single heading per WHATWG spec. But it also could be reinterpreted as something like "heading of a group of semantically related content within a document tree". I agree that it might be not the best idea for the ideal world, but it looked acceptable compromise to me.

@SelenIT what if it contains nothing but text?
However the major issue is that, if I recall correctly, hgroup was not meant to have the semantic meaning of a "heading", nor to take the place of an implied heading. Quite the opposite, it was just a poorly devised way to group h# elements so that their native ranking became irrelevant (apart from the highest one, which determined the correct heading level).
I guess it's not a good choice. At this point we should stick with what you call "html4-style" outline model, and use the number as a relative ranking.

@SelenIT

What about reviving the hgroup element

I don’t see how this would be better than the H element which could be used as a switch (aside from whether the idea of a switch itself is good or bad) to the same extent as HGROUP. Just synchronizing two versions of HTML spec is probably a very minor argument.

In general, I’m strongly opposed to using an element with a confusing 6-characters-long name instead of an element with a clear 1-character-long name.

SelenIT commented Feb 13, 2017 edited

@AndySky21, making the native ranking of heading elements irrelevant and mapping their ranking to the nesting of sections was the idea of HTML5 outline algoritm and the whole "sectioning content" concept. hgroup just allowed to treat several groupped headings as a single heading (yes, it was a poorly designed way to mark up subheadings and taglines).

@Marat-Tanalin, I agree that short name is a big advantage. The only advantage of hgroup I see that it seems to be already understood by browsers (and tools like HTML5 Outliner) and already has a semantics of changing the semantics of heading elements, so at least browsers wouldn't have to modify their HTML parsers.

I have been trying to collect my thoughts and explain them before jumping in here - I've written a post explaining my thoughts. It also links to an (incomplete) codepen illustrating a bit and to an issue I filed on the speculative polyfill to discuss.

@SelenIT the way hgroup is understood by browsers is so distant from this matter, that in comparison one could simply consider header as levelless heading element.

@jonathantneal jonathantneal referenced this issue in jonathantneal/h-element-spec Feb 18, 2017
Open

The State of <H>: February 2017 #1

jonathantneal commented Feb 18, 2017 edited

I hope those of you interested in <h> will take a moment to read my summary: The State of <H>: February 2017.

@jonathantneal jonathantneal referenced this issue in jonathantneal/h-element-spec Feb 20, 2017
Open

How do old-style h1-h6 elements interact here #3

For people joining the thread late, I've tried to sum up a problem, and show why we must take an evidence-based approach to this https://jakearchibald.com/2017/do-we-need-a-new-heading-element/

@Jake Your summary adds a lot to the discussion. I particularly enjoyed your latent political reference.

I've resisted wading in to the discussion so far precisely because I have more opinion than expertise as to what has been attempted previously. I feel a user story based approach may be of help in understanding why we want to 'fix' outlines.

"As a web developer, I want a way to markup headings such that they are hierarchically semantically defined and stylable mixed in a document among conventional headings, so that I can more quickly define large documents with consistent hierarchy of headings."

Being able to enable outline based heading sections, opt out of them and override them are all acceptance criteria.

Collaborator
chaals commented Feb 20, 2017

@jakearchibald nice summary - thanks.

@lukebrowell Can you explain the reason why overriding / opting out of the outline are requirements, and whether there is a critical difference? I'm not suggesting there is no need, I just can't think of one off the top of my head and think it would help the discussion to understand that goal.

Without evidence, it's unreasonable to expect <h> + outline to be better implemented than <h1> + outline.

The only thing that can beleaguer <h1> + outline is evidence.

We need evidence.

This proposal needs to state why it's more likely to succeed than what we already have + implementation of the outline.

@jakearchibald, my chief concern at this moment is that accessible tools (ATs) will misread heading levels, contradicting the implemented outline specification. This would require developers to intermediately correct the ATs interpretation by introducing another contradiction directly into the source which would then lead developers back to the same pain points that instigated my proposal. For those just tuning in, I’ll explain:

ATs have long announced h1-h6 headings appropriately. I do hope we’ll agree to consider “identifying h1-h6 headings” a safe expectation of most HTML/(S)GML vendors over the last 50 years, because it’s actually hard to find proof of this in AT documentation; it’s so self-evident. Here’s a JAWs manual informing one how to navigate headings. The argument here is: real life headings serve a real life purpose in real life ATs.

As for attributes equivalents of headings, like role=heading and aria-level=1, these have become largely supported over the last 7 years, at least according to this [reliability report] by PowerMapper Software testing those attributes against several versions of NVDA, JAWS, WindowEyes and Voiceover, and according to these similar results by Pearson.

If the outline algorithm is implemented today and every developer starts using <h1>s everywhere today, those developers would still need to polyfill existing <h1> elements to support ATs, which would otherwise fail to correctly identify their heading levels. Otherwise, we would need to encourage developers not to use <h1>s everywhere and to keep following the existing advice in the specification; which you’ve read me say in other places brings us back to our original pain point.

Since the current advice (to use h1-h6 as if they respected the document outline) is from 2013 and (according to the aforementioned reports) support for role and aria-level is now much more wide-spread, perhaps the advice here could be changed. Thoughts on that, @stevefaulkner?

Now, polyfill like <h1 aria-level="2"> saves us adding role="heading", but it costs us immediate readability because the declaration is contradictory. It causes AT-sensitive developers to question whether an AT will correctly trust aria-level="2" over h1.

It is my opinion that:

  • Developers will justly question whether any <h1> still impacted subsequent content as an implied section, because of how they have been taught things operate by the current specification.
  • Developers will question whether 1=2 is a bug in the source.
  • Developers will end up postulating an <h> element as I’ve proposed, just as many other developers have done so before me, just as the inventor of HTML himself ended up doing a quarter of a century ago.

I believe these opinions are justified by history, and the reasoning behind them better explained by Brian Kardell as he described the “flat earth” html documents of old.


@lukebrowell, I hope that any latent references to anti-evidence political entities would be bad reading on your part. We can disagree with my citations and the information they provide and how I use them to reach conclusions, but to dismiss them as either missing or invalid would be the kind of “confident assertion without evidence” Jake mentions as being so problematic. Perhaps, unintentionally, <h> advocates are being described unfairly. I’ll let you make that determination... with the evidence. You know, as they say, “We report. You decide.

jakearchibald commented Feb 20, 2017 edited

@jonathantneal

my chief concern at this moment is that accessible tools (ATs) will misread heading levels, contradicting the implemented outline specification.

Right, but like I said in the article, we must compare like-for-like. At the moment ATs will see <h> as a <span>. Given that screen reader users iterate over headings, it seems better to fall back to a heading (even with an incorrect level) than an element with no semantics. But yes, a polyfill would be able to set the correct heading level.

Now, polyfill like <h1 aria-level="2"> saves us adding role="heading", but it costs us immediate readability because the declaration is contradictory

It's not contradictory. With the outline, the number in the heading tag is contextual to its section.

Developers will justly question whether any <h1> still impacted subsequent content as an implied section, because of how they have been taught things operate by the current specification.

Again, we must compare like-for-like. Developers don't know how <h> works currently. Developer relations work is required either way.

Developers will question whether 1=2 is a bug in the source.

Again, we must compare like-for-like. Developers may question if <h> is missing its number. (note that I'm going with 'may', not 'will' - I think qualified uncertainty is more applicable here than confident assertion sans-evidence)

Developers will end up postulating an element as I’ve proposed, just as many other developers have done so before me, just as the inventor of HTML himself ended up doing a quarter of a century ago.

Right, but developers have for years postulated "Just put [whichever framework/library is fashionable right now] in the platform", but does that mean we should? The answer to "Should we put [framework/library no longer in fashion] in the platform?" is almost always no.

Also, comparing your position to Tim's 26 years ago ignores the 26 years bit. If this were 26 years ago, I'd be fighting for <h>, but we have 26 years worth of the other headings to consider.

I tried to express the need for evidence, and the need to compare like-for-like in the article, and I'm a bit gutted that it hasn't really landed.

Another thing to consider: The current HTML outline allows mixing <h1-6> with sections, and it remains contextual. This is pretty valuable. It means I can take a snippet written flat, and include it in markup written in a structured way. For example, I write my blog posts in markdown, which uses a flat heading structure. The HTML outline meaning I can put this flat structure inside a section, and it becomes contextual to the section.

viT-1 commented Feb 20, 2017 edited

@jonathantneal
Because of bad readability of <h1 aria-level="2" I propose to use <label aria-level="2" role="heading">

If you go back to the original abstract concepts, you can use label as caption. Captions and headings are the birds of feather.

The label element represents a caption in a user interface

(cite from html5 spec)

@viT-1 The <label> element has completely different semantics than a heading, does not provide the structure of a heading, is intended for use with discrete controls, already has years of traction as existing solely for use in forms, and would likely be even more confounding from which to generate a document outline. Using a role to completely re-wire its meaning also is a violation of the second rule of ARIA (which is not a hard and fast rule, but a good practice). Nobody is biting because it is not a good fit.

I also am pre-emptively stating that while you equate it to a caption, with which I disagree, I also would be against using <caption>.

Alohci commented Feb 21, 2017

@jakearchibald

Given that screen reader users iterate over headings, it seems better to fall back to a heading (even with an incorrect level) than an element with no semantics.

Is it better? Or worse? That strikes me as a very important question. I could easily be convinced either way, but it's a piece of evidence that can only be gathered by asking real AT users. It would be great if we had a means of doing that.

Let me pose a question that I think needs answering:

Is there is any harm in writing/offering a polyfill which actually uses h1...h6? This has bitten us in the ass a lot of times and W3C TAG recently published a finding which includes advice mentioned earlier about "speculative polyfilling". While "advantaged" the spec is clearly is speculative by both their definition and my own. Once something escapes into the wild in the 'native' space, it's very hard to take it back or redefine it.

However... Given the nature of this very particular problem, one could argue that that is kind of precisely what we are doing if we could "throw the switch" anyway. We're redefining the meaning of the level. In fact, the polyfill could save you in some ways by always overwriting to a known definition according to the polyfill you included when you wrote it. I honestly don't know the "right" answer but I think that deserves at least casual consideration.

Assuming it is "safe" then we really should make a speculative polyfill that does just what the spec says (with existing headers) and discuss as @jakearchibald explains, "like for like" comparisons as much as we can here.

Note - nothing prevents anyone from floating other ideas in the same fashion - Here's a little disclaimer.... https://gist.github.com/bkardell/586b841c85d174b8dcd84dd9bae30ee5

@bkardell

Is there is any harm in writing/offering a polyfill which actually uses h1...h6?

IMO the entire <h> conversation is moot until we can polyfill the outline algorithm logic, and I see no reason why we would not do that with the existing <h#> elements. Once polyfilled (polyfold?) and tested, we see if browsers are willing to implement it and/or we are willing to take the lessons and revisit the algorithm.

Sites that want the algorithm can use the polyfill. Sites that (judgment alert) know how to write templates that adapt to the needed level and (end judgment alert) just rely on traditional <h#> logic can skip it. That will help assess how valuable it is to site owners as well. Sorta.

I think then we can discuss a new element. After all, if we cannot make it work with existing headings how would we make it work with a new one?

@Alohci

Is it better? Or worse? That strikes me as a very important question. I could easily be convinced either way, but it's a piece of evidence that can only be gathered by asking real AT users.

The best evidence I have is http://webaim.org/projects/screenreadersurvey5/#finding - but yes it doesn't quite answer "would you rather be given no headings, or headings with incorrect levels?"

Thank you for understanding the importance of evidence here!

AliceWonderMiscreations commented Feb 21, 2017 edited by chaals

At one point, I just used <h> in my code and at the end, had the DOMDocument class adjust them based upon the article / sectioning hierarchy but it was kind of slow so I stopped doing it.

I want numberless headings, but they should depend upon sectioning depth and not be used when article/section are not in use.

In an aside element is an interesting question - I start every aside with a heading one level lower then the heading in the section it is a child of, but I style all headings in an aside to visually be the same - whether it is an h2 or an h6 or anything between.

I'm not sure what is the correct way to number a heading in an aside, since it is content that is tangential to the section it is in.

Just using <h> and letting the browsers worry about it would be so much easier.

Anyway my two cents, h1..h6 should only be used outside article/section context. Within article/section context, the article/section semantics define the document hierarchy and thus the headings shouldn't need to be numbered.

I don't see any reason to discard the use of numbered headings in articles and sections. Apart from the fact that it would render all pages created as of now non compliant, which is undesirable, it would force authors to a messy structure even when this is not necessary.

Levelless headings would be useful when used in conjunction with sectioning content, at author's discretion. They should serve the very same purpose of other specification elements used in html - similarly to table/caption, fieldset/legend, figure/figcaption, and in some sense details/summary.
Numbered headings can serve the same purpose as far as their use is compatible with the specified number. Otherwise pages interpretation increases in complexity:

  • with the addition of <h> the parser knows it has to only interpret section level and expose its "caption" (the h element itself)
  • if numbered headings are wildly used (i.e. irrespectively of their number) the parser has to first see if the number has any sense, and otherwise expose them as generic heading element. And this inference can be problematic.

Responding to this after seeing it on Twitter. As a screen reader user, I'd rather have incorrect headings than no headings. As a developer, it would be a lot easier to have a levelless heading to use when clients, (trust me, it's not just devs who screw this up), insisting that a particular piece of content has to have a particular look that's sort of like a heading but that would break an already existent heading structure. We can explain semantics to clients all day long, but when clients are married to their design, and going so far as to dictate down to the pixel level, (yes, this happens, I'm dealing with it right now), right now the choice is to pick a heading level at random, assign whatever class, and do all this knowing full well you're breaking things. Having a levelless heading to use in cases like this would ease that a bit.

Contributor

A point I would like to raise in regards to terminology:
levelless headings does not mean the headings have no level property exposed in the accessibility tree, it means that the heading level is not implied by the number in the element token name h1-h6
The level of a heading is calculated by it's sectioning content nesting level. The semantics are not simply this is a "heading", that would be a real backwards step and is not what the outline algorithm defines.

@amandarush what if the number in the tag name, eg <h1>, was contextual to its parent section?

I'm hoping that will give us a way to have a computed heading level but in a somewhat backwards compatible way. A new element, eg <h> will have no semantics to user agents that don't support it, whereas <h1> will still be a heading.

I would agree that a levelless heading would be a welcome addition. I would think of it a little like tab order. If nothing is specified I takes the level of it's context.

patrickdark commented Feb 21, 2017 edited

If y'all are going to fix this issue, I'd propose fixing a related, longstanding issue: an inability to obviously and unambiguously declare the site title and page title in the body of the document.

If there's a sitetitle or pagetitle element in the document, that can be used to cue changes in the outline algorithm such that all h1 through h6 elements behave as h elements. If such elements aren't in the document, then h becomes equivalent to h1, which mitigates the need to fit the new h element into the apparently nonexistent, legacy outline model.

If no one's implemented the existing, nonexistent algorithm, then it's clearly not needed and can be abandoned. Save the effort, leave it to authors and search tools to write their own, and stick with developing a simpler sitetitle, pagetitle, and h outline algorithm.

Contributor

related #806

madbonkey commented Feb 24, 2017 edited

Forgive me for not reading to the very end in this long discussion, but after reading @axelboc's comment I'd like to throw in my 2 cents as well.

There seem to be two issues here, the outline problem and the missing (?) "generic heading" element – I do see that they're closely related in respect to current implementation/use, but I'm confused as to why proposed solutions couple them so tightly when the outline algo isn't even implemented.

Personally, I agree with @axelboc, not having a generic heading element is painful in quite a few ways. Arguably, the mess we're in is in part due to how developers didn't/don't pay respect to sectioning, and the arbitrary 1-6 levels, and of course browser implementations, as always. It always nags me that some reader/browser might choose to attach semantic meaning to my heading elements depending on where they're used, especially since many frontend libraries require additional wrappers or specific markup hierarchy, or employ some kind of component system which makes figuring out exactly what kind of structure you end up with difficult to impossible (since dynamic pages and SPAs are kinda booming right now, this problem might become more prevalent in the future). Other than using other elements like dl/p/span/... for non-structural headings, which doesn't really feel right in terms of semantics, I don't see a way of having heading elements that don't convey structural information.

Having a generic h would help e.g. with the React use case (you don't have to worry about the context the heading/section is used in), and improve readability (for whatever it's worth). A "level" attribute could be utilized for styling and/or outline. So far as I'm concerned, having h1-6 and h both available would be neat, using numbered for structural headings and h for generic headings.

Regarding pagetitle/sitetitle, I'm not a big fan – don't we have title for this already? If the argument here is that there's no control from within the body, I'd say that's a technical issue due to how you're generating your markup, and also ask what the use case for controlling it "after the fact" is (and why you can't do it with title when generating the page).

bkardell commented Feb 28, 2017 edited

For anyone coming to the party late, or who hasn't been able to read through it all, I wrote up kind of a summary last week.

@madbonkey One: We have a title element, but this element doesn't allow rich content and cannot appear in the body of the document. Furthermore, the title element is overloaded; it's used for both page titles (correct) and site titles (incorrect) such that automated tools have no way to discriminate between the two except inference.

Two: As with h, adding new elements would make doing the right thing more intuitive for authors that have no idea what they're doing with respect to encouraging design of a proper outline by accident. Right now adding site titles to the document body are the norm and it's not at all clear that adding an h1 (or future h) element for the site title is wrong.

Three: It'd be nice if I, for example, could bookmark a page and have the site title and page title saved separately and therefore (A) use a command to enable and disable all site titles for all bookmarks and/or tabs in the browser UI or (B) control the page/site title separator to automatically make the appearance of all bookmarks uniform. It'd also be nice for displaying search engine results.

Four: I have no problem with page generation. However, it is annoying that that I (A) have to specify both a plain and rich text version of a title or (B) use a generator to parse the title and strip it of rich markup for display in the document head. It'd be nicer if I didn't have to specify a title element at all and only needed this content once for the document body. Then I could drop the PHP I'm currently using to parse all page titles and code them differently for two different places and just type titles directly into a single location.

Writing as an author of HTML pages… I think that <h> would be immensely useful and that (respectfully) a bit of KISS would help here.

<h1> through <h6> are established; no need to pave the existing gravel road. Don't make these tags contextual within sections. Instead, think of these tags as overrides whereby the author has explicitly chosen to force that level of heading. In terms of the document outline, let the override… override, and reset (or advance) the outline to whatever level was explicitly set, irrespective of nesting. This is how web pages are being written now: the astute developer pays attention to what heading levels appear where. And if an author does it wrong, well, it's their web page (maybe their readers will complain).

The plain <h> when combined with sectioning is a beautiful solution. Not only is it logical and the tag symbolically intuitive (i.e. no number means determined by the browser), it can be added without changing the past. It's the new, paved, glistening black highway built to endure.

Let authors choose the road they want to travel. Introduce <h>. Don't worry about <h1> through <h6> — those tags can work alongside the new <h> as they are.

Being able to use h1-6 in a contextual manner is really useful when working with existing tooling and content. Eg markdown convertors.

@jakearchibald I agree with you that being able to use <h1><h6> scoped to a section would be wonderful, particularly with current CMS (markdown or otherwise) allowing these elements to be added to an existing HTML outline. But these elements are currently scoped to the entire <html>, and changing that means changing the web.

Although improving the existing web is certainly a worthwhile endeavour, that's most likely going to be more difficult than adding to the existing web. If we can get a usable <h> with nested sectioning sooner by foregoing the grander vision (at least for the time being), I propose that this is the wiser approach. Incremental advancement versus wholesale change.

Once us authors have the ability to author flexible document outlines with <h>, I think that's what we'll prefer to do — thus, in practice, eventually relegating <h1><h6> to the sectioned 'flat' content you envision.

bkardell commented Mar 5, 2017 edited

I feel like there are two related, but separate questions raised by what @jakearchibald is asking, but I'm not sure others would agree, so I'm putting it out there. I apologize for the length but it may be a subtle point, I just don't know where we all stand.

  1. can we effectively change the aria-level of headings contextually such that existing tools can do a better job than what they do now" I feel like the answer to this is 'probably yes' and I don't think that this is probably that hard.

  2. If we created a truer sense of a 'document outline' such that new/better ways of understanding the document are possible for all, could we use the HTML generated by existing tools (like markdown without mixing HTML sectioning) to fill that in? On this, I feel like the answer is 'I don't see how that is really plausible, it's very complex in the very least'.

To illustrate what I mean re: point 2 , imagine that we have this, generated by markdown..

<h1>The story of HTML</h1>
<p>This is the story of HTML...</p>
<h2>Before HTML: The 1960s</h2>
<p>In the 1960's...</p>
<p>Goldfarb... Nelson... yadda yadda...</p>
<p>Nearly 30 years later, in the 1980's, hypertext...</p>
<h2>CERN Documentation</h2>
<p>Working at CERN, TimBL...</p>

This is possible because "editor's marks" and their long history (explained in my piece), and that's also why it's possible to create an even simpler thing like markdown (note it's only arguably simpler really because all of these are void tags for the same reason - they're just different editor's marks).

Note that there is no way to reference the 'sections' even to discuss them here - we do that with some mental gymnastics about editor's marks. There's no way to say "indent the Before HTML: The 1960s section by 2 rems" in CSS or "how many paragraphs (or subsections) does the The story of HTML section' have? Likewise, it's impossible to say "read me" that thing. These are things only possible to deduce and when we deduce we are talking about something more like a DocumentFragment. I say "more like" because in practice it is reasonable to want to write the paragraph "Nearly 30 years later" as part of the parent section, between the two sections marked with h2's above, but you can't. Using <h> only for illustrative purposes here, what I mean is that this seems a reasonable thing that cannot be achieved without sectioning.

<section>
  <h>The story of HTML</h>
  <p>This is the story of HTML...</p>
  <section>
    <h>Before HTML: The 1960s</h>
    <p>In the 1960's...</p>
    <p>Goldfarb... Nelson... yadda yadda...</p>
  </section>

  <!-- Continuing 'the story' - not part of the 1960's section , introducing 1980's -->
  <p>Nearly 30 years later, in the 1980's, hypertext...</p>

  <section>
      <h>CERN Documentation</h>
      <p>Working at CERN, TimBL...</p>
  </section>

I guess what I am saying is that I think an outline that allows us to "explain" this in useful ways such that new affordances, patterns and possibilities to make a document really grokable/able to be 'discussed' at all levels seems like something I am very interested in. Am I alone in that? I honestly am not sure.

Assuming I am not - I guess... It seems to go without saying that existing a11y tools need to continue to 'generally work' as they do today and would it be enough compromise to say that these are two separate problems? As in 'we can make existing views better by improving heading 'levels' in terms understandable by existing tools -- but also given better content we can potentially expose a richer outline? ..and that perhaps the latter cannot be effected so much with existing/unmodified markdown generators without mixing HTML sectioning? This is why in my own experiments (http://codepen.io/bkardell/pen/vgbgBp) I have taken to calling these "outline headings" and not simply "headings".

jakearchibald commented Mar 5, 2017 edited

@jourdanritchey

Although improving the existing web is certainly a worthwhile endeavour, that's most likely going to be more difficult than adding to the existing web. If we can get a usable with nested sectioning sooner by foregoing the grander vision (at least for the time being), I propose that this is the wiser approach. Incremental advancement versus wholesale change.

Adding a new tag is the "wholesale change" you refer to, while enhancing what we've got is incremental. Think about the steps involved in doing each - adding a new tag is more work. Not only that, but it carries a huge risk of, as you put it, "foregoing the grander vision", as in not implementing the accessibility parts. This is the only bit that's missing from the html5 proposal currently, and I still don't understand why people think a new tag would get us there.

I tried to explain that in https://jakearchibald.com/2017/do-we-need-a-new-heading-element/, but it seems I'm still missing a way to get the point across.

@bkardell the HTML outline generates implicit sections from h1-6 so I'm not sure what's missing from "read me that thing".

I do think the outline algorithm needs tweaking with regard to section roots though. There's some misunderstanding there, either by the original spec author, or those who have interpreted it since, and I'm not sure which yet.

bkardell commented Mar 5, 2017 edited

@jakearchibald

"the HTML outline generates implicit sections from h1-6"

I think we are just talking past one another with terminology here. "generates sections" means what to you here? What I read in the WHATWG spec at least, and I'd be very happy to be wrong about this, appears to be mostly just doing all that in order to try to figure out better heading levels to expose and perhaps some under-described 'anchoring' to the editor's marks that can be key navigated.

I see nothing in the spec that suggests that that is exposed anywhere, to anything. Is there something to suggest that anyone can do something useful with the thing it calls an 'implicit section' beyond that? It's not clear if/how it is exposed - at least not that I understand.. Please correct me if I am wrong.

Is the browser supposed to create some kind of phantom group role="region" node in the Accessibility Tree? Can you or I, as developers, identify it? If not, how can something else (like AT or a search engine or some AI) read it? Can someone style it (there have been requests)? Can someone build a TOC that reflects it and links to those things? I don't see how. I've tried to explain why.

This is the part I am asking - am I the only one who: a) (mis?)understands the existing specs this way b) thinks that creating/exposing an actual "outline" would be very valuable thing that would enable a lot and is potentially separate from simply "making more realistic heading levels out of h1/h5" c) thinks that "implicit sections" would make this very hard.

NOTE: It's not my intent to dismiss the concerns about md content/etc in any way.

@bkardell I'm talking about sections as in https://html.spec.whatwg.org/multipage/semantics.html#concept-section and all that implies - including generating things like TOC.

These aren't exposed to CSS. If you're wanting to do that, you should use a section element or a div if you don't want the semantics of a section.

Whether these sections are exposed to AT depends on whether it would offer a good experience for AT users, and I don't have enough data to make that call.

bkardell commented Mar 5, 2017 edited

@jakearchibald

including generating things like TOC.

Can you point me to the bit that explains how this this helps you do that without yourself having to know the algorithm? As far as I can see the level isn't exposed to you, nor where the 'implicit sections' are? All I see in relation to exposing it somehow is as I said, an under-defined 'anchoring-like' thing for key navigation https://html.spec.whatwg.org/multipage/semantics.html#exposing-outlines-to-users. I'd genuinely like to understand this because I'm definitely missing it if it is there.

@bkardell depends who the "you" is in your statement, browser vendor or web developer.

The outline is not exposed via the DOM right now. Maybe it should be. However, my primary concern is accessibility. Maybe exposure via the DOM and/or CSS would help encourage browser adoption. Maybe it wouldn't. I cover this as a possible way forward in https://jakearchibald.com/2017/do-we-need-a-new-heading-element/, but we don't yet have the evidence to make that call.

Alohci commented Mar 5, 2017

@jakearchibald - As a web author, I'd say that exposure via the DOM and CSS is very attractive. That will make the outline much more everyday usable. And what that means is that it's far more likely that web authors will use the headings and sections correctly, because they will get good feedback when they go astray, particularly if all elements - not just headings - have their outline level exposed though a pseudo-class like :outline-level(n).

The more likely that authors use the outline correctly, the better that will be for accessibility, because AT users will get the correct level reported to them as they experience the document more often.

bkardell commented Mar 6, 2017

@Alohci I agree with your sentiments, however, this should be provable. We can speculatively polyfill this and offer data, even comparably. @jakearchibald and I are in full agreement there.

The nature of my question was intended to remove noise on this front, not add it. Effectively I want to know whether we agree on what we thought the existing proposals for "document outline" were doing in these respects. As far as I can see it is purely about exposing h1-h6 as 'better numbers' with existing limitations. No change I can see makes new things possible if there are not new things added to DOM or AT or CSS.

If that is indeed what it about - perhaps it is worth being careful in what we are calling things. To me, this isn't much of a useful actual 'outline', but that's just bikeshedding. I'm trying to figure out if we are potentially just talking about two different but related things and perhaps remove some of the confusion.

By writing here I hope to contribute to the direction the conversation around this is taking because, from my (an HTML author's) perspective, it appears that the proposal to add an <h> tag is being conflated with other concerns pertaining to (1) an outline algorithm that was specified but ignored by the industry, and (2) changing the scope and in some cases meaning of one or more of the <h1><h6> to be different from what it's always been. My concern is that if any addition or change to HTML is essentially a sales job to convince the decision makers behind the user agents, everyone concerned is best to make this — or encourage it to be — as simple and straightforward as possible.

@jakearchibald

Adding a new tag is the "wholesale change" you refer to, while enhancing what we've got is incremental.

The proposed addition of an <h> tag is an addition, not a change. Changing the scope of <h1><h6> is a change. What's "wholesale" about this change is that it would effect all <h1><h6> everywhere. As I expressed in my initial post, my thinking is that <h> with an outline algorithm could be added without affecting <h1><h6> at all.

Whether the addition of <h> is more difficult programmatically than changing the scope of <h1><h6> I don't think is as critical a consideration as whether it will affect existing web sites (and thus user satisfaction with their user agent). Because <h> doesn't exist yet, it seems to me that it's possible to make deploying <h> a safe bet for user agents (happier authors with no risk of disappointing users).

as in not implementing the accessibility parts.

From what I've read here, it's my understanding that all of the AT user agents already understand <h1><h6> (irrespective of aria). So nothing needs to be done if the scoping of <h1><h6> is not changed. Obviously these agents would need to add support for a new <h> tag and its associated outline algorithm, but again — that's an addition, not a change.

I still don't understand why people think a new tag would get us there.

From an author's perspective, <h> is a logical complement to <h#> as it unambiguously indicates a heading and that we want its level to be interpreted by how we've nested our sectioning elements. Not as grand as having all headings contextual, but alas… it can be made to work. And maybe having the ability to override the outline by keeping <h1><h6> scoped to the page (and thus unchanged) could be useful… who knows?

Although an assumption on my part, I also think that it'll be easier to get an outline algorithm implemented by user agents when they can do so without any risk of affecting their users' reading of existing web pages. I would wager that the failed-to-be-implemented outline algorithm wasn't implemented because of such concerns. Proposing an outline algorithm that only affects a new element, conversely, could cause no such concern.

I tried to explain that in https://jakearchibald.com/2017/do-we-need-a-new-heading-element/, but it seems I'm still missing a way to get the point across.

I did read your blog post. It encouraged me to post here because I got the feeling that your desire to research and analyze the current use of <h1><h6> all across the web would delay or derail us authors getting usable sectioning with outlines. Maybe I'm wrong and, of course, if you feel you'll be successful with that, great. But it's my opinion that proposing <h> with what would initially be its own outline algorithm now, without conflating its proposal with other issues, won't affect what you want to achieve and, in fact, would probably make what you want to achieve easier in future.

By introducing h we're changing its semantics from nothing to something. Doing that is pretty huge, and user agents will be left behind. Existing headings have a better fallback in that case.

I like the ideas around exposing the outline in CSS and/or DOM, but only if it can be shown that it will get us to accessibility quicker. If not, I'd rather accessibility had priority. With the current outline spec, everything but the accessibility part was implemented, so I'm worried that if we add a load of developer-facing features, we'll end up with the same problem.

Unfortunately this thread is overrun with "just stick a new tag in it", and the evidence points to that resulting in failure, just as when section was a new tag.

I want us to get away from "reckons" and onto "evidence". If finding evidence is tough, that should promote more caution, not a justification for "ahh well just throw a new tag at it".

If it's shown that we can't implement the outline on existing headings, then we should look at an opt-in, as you retain the ability to contextualise preexisting content.

I know that's disappointing to those who are hot for a new tag, but I think we need to look beyond developer excitement and concentrate on user experience.

As far as I can tell, we're still blocked on finding out why things failed last time around, and identifying any flaws in the outline algorithm. I realise that's more boring & hard work than throwing a new tag in, but it's the boring & hard work that gets us to real user benefit.

Collaborator
chaals commented Mar 7, 2017

@patrickdark wrote

If y'all are going to fix this issue, I'd propose fixing a related, longstanding issue: an inability to obviously and unambiguously declare the site title and page title in the body of the document.

Please don't put different issues into the same one - if you want this different feature, either propose it in for incubation e.g. in WICG which would be my suggestion for this case, or raise it as a separate issue.

@chaals chaals added this to the When it's ready milestone Mar 7, 2017

@jakearchibald wrote

With the current outline spec, everything but the accessibility part was implemented

Would you please expand upon this assertion? It seems vague. Genuinely, evidence of implementation would help resolve interpretation of the current outline spec, which is an open issue (see #806 and #794). I’m not sure if you meant to, but you’ve not qualified what "implementation" means — is it exposure of the whole document outline as written in some kind of developer tool or something else? How many browsers are doing this?

Earlier, you wrote:

For example, I write my blog posts in markdown, which uses a flat heading structure...

Markdown seems presently limited to flat documents, much like GML of old, and devoid of any sectioning containers, so I’d encourage you to limit this discussion to more two-dimensional works like HTML itself, but as Markdown compiles to HTML, I do not want to disregard your point.

... The HTML outline meaning I can put this flat structure inside a section, and it becomes contextual to the section.

This is really important. As you mentioned the outline being implemented, please do show us how this is working. I’m personally unaware of how to get exposure of this in any way through the browser or its developer tools. I would be doubly delighted to see Firefox or Safari or Edge also having this functionality.

Unfortunately this thread is overrun with "just stick a new tag in it"...

This issue has served as both a pulse and a triage for developers. It’s doing its job. You and I have both forked the discussion as we see fit.

... and the evidence points to that resulting in failure, just as when section was a new tag.

I hope you will not disregard the available information we have provided to you in this issue and also on your blog post. The gist of the arguments for a new element as opposed to redefining existing elements are namely that the HTML≤4 heading definitions are too potent to redefine rather than introduce a new element, which I have asserted is why new their sectioning redefinitions were not implemented (that I know of) even while new section-related elements gained adoption and accessibility exposure (see earlier citations), except in the case of hgroup which failed for reasons related to redefining headings. There is a secondary argument that the semantic sugar of <h> as a general heading is simply easier to grok, leaving its leveling business to its context. I provide citations to such claims as I initially make them or amend them specifically so that anyone may refute them.

AmeliaBR commented Mar 7, 2017

Hi all,

I wrote a (somewhat rambling) summary of this debate for CSS-Tricks, ending with a call to action asking people to start looking at the outlines generated for their websites (with and without the HTML 5 algorithm), and to identify where the problems are. It remains to be seen if that results in any new clarity, or only more noise.

jakearchibald commented Mar 7, 2017 edited

@jonathantneal

With the current outline spec, everything but the accessibility part was implemented

Would you please expand upon this assertion? It seems vague.

It's vague because I already covered it here and at https://jakearchibald.com/2017/do-we-need-a-new-heading-element/, but I'll go through it again. The last attempt at fixing this problem involved adding the following to the platform:

  1. New tags (and all the DOM interfaces & parsing rules that go with them)
  2. New default CSS to recognise contextual headings
  3. Correct heading levels in the AT

1 & 2 were completed. 3, which in my opinion is the most important bit, was not. Your proposal requires the same three steps, but assumes (with no basis) that 3 will be done correctly this time. This was one of the key points in my article: If you're proposing something almost identical to something that failed, you better know why your proposal will succeed where the other didn't.

I’d encourage you to limit this discussion to more two-dimensional works like HTML itself, but as Markdown compiles to HTML, I do not want to disregard your point

We need to consider legacy agents & content here. Markdown-generated content is an example of that, but there's a whole web of other existing content out there. Being able to mix this old content with a sectioned approach seems like a great feature - allowing sites to transition to a sectioned model without a rewrite of the whole site. Eg, news sites will have a ton of flat-heading markup in their CMSs - should they have to rewrite everything to make use of sections? I'd much rather they didn't.

... The HTML outline meaning I can put this flat structure inside a section, and it becomes contextual to the section.

This is really important. As you mentioned the outline being implemented, please do show us how this is working

Yes! Hugely important, and the <h> proposal misses it. I'm happy to demo it, but I think you misinterpreted what "working" looks like in current browsers.

I hope you will not disregard the available information we have provided to you in this issue and also on your blog post. The gist of the arguments for a new element as opposed to redefining existing elements are namely that the HTML≤4 heading definitions are too potent to redefine rather than introduce a new element, which I have asserted is why new their sectioning redefinitions were not implemented

The above is really sad-making, but very succinctly demonstrates the root of my frustration with your approach. To break it down:

  • "the HTML≤4 heading definitions are too potent" - What's the unit of potency here? If there's no evidence for this, it's pure opinion. But you then go on to use this opinion:
  • "which I have asserted" - Yes, I see you asserting, again and again, but I see no evidence behind those assertions.
  • "is why new their sectioning redefinitions were not implemented" - C'mon, you must see the problem here by now. You're presenting a "guess" as "fact".

You might assert that gravity pulls things towards the Earth, but what if I super-double-assert that it in fact pushes things away from the Earth? Which argument wins here? Is it me, because my assertion was stronger? No, it's the third person who wins, the one that demonstrates how gravity works. Note, that although my assertion in this example is stronger, it shouldn't be assumed fact until disproven. The burden of proof is on the claimant. So going back to:

the HTML≤4 heading definitions are too potent to redefine rather than introduce a new element, which I have asserted is why new their sectioning redefinitions were not implemented

Do you have any proof?

Seeing you "thumbs down" an appeal for an evidence based approach is kinda sad. Are you against evidence-based approaches in general, or just in this case?

Check this out: https://twitter.com/realDonaldTrump/status/837989835818287106. Here he's making an assertion, without evidence, and expecting everyone to treat it as fact until it's disproved. Please, don't be that guy.

The burden of proof is on the claimant.

My assertion is built on previous citations around heading semantics remaining as they were and being exposed to users as much that consume them, which is mentioned countlessly.

Seeing you "thumbs down" an appeal for an evidence based approach is kinda sad.

You wrongly asserted that I “thumbs down”-ed it for that. No, I merely reacted to your tone. I appreciate the sparing because I like to learn from you, and I’ve learned a lot and what I’ve learned has challenged my own perceptions of how I interpret spec authors, but when you said the thread was overrun, I felt like that was dismissive to the people who came here from various blogs and newsletters and twitter who found this a safe place to engage in debate and express their opinion on a matter they thought will convenience them or make more sense to them. Being told they are overrunning the thread is kinda sad to me. If you feel it was still in line, okay, I disagree, but I’m still sorry for making you sad — I don’t want to make you sad — so I’ve undone it.

Do you have any proof [for claims that old heading definitions are too potent to have been replaced with the new outline heading definitions]?

Yes. Admittedly, it’s hard to prove this negative, because how do I prove browsers didn‘t implement something that I can’t get a clear definition of (see other issues)? The specs poorly defined guidance on how the new outline algorithm should have been implemented in regards to headings (see previous citations, other issues #s, examples in the spec, higher headings levels in subsections, sectioning roots, sections without headings). Browsers ultimately rejected (see other blog posts) this part of the outline; which was one of the most important parts (see your own comments). The one AT which did implement this part of the outline (see JAWS) ultimately rejected it as well.

I can understand how you don’t consider this pattern of rejection full-proof evidence. I’d prefer if a browser vendor just told us “we didn’t implement this part of the outline algorithm because of X”. I can’t seem to get such an answer. You’d have a better shot at getting this info from (at least) Chrome than me, I’d think.

I’m only trying to provide new information and new perspectives as they come to me in the hopes of advancing the conversation. I also plan to write another State of H and to celebrate the conversation to encourage people to look into it, because I still believe it’s a good conversation to have, even if people chime in with opinions or you criticize me for being too self-congratulating (see your 1st comment on my last state of h).

jakearchibald commented Mar 8, 2017 edited

@jonathantneal

it’s hard to prove this negative, because how do I prove browsers didn‘t implement something that I can’t get a clear definition of

That isn't what "proving a negative" means (see wikipedia). The HTML spec defines an outline level for headings that isn't exposed in the AT in Safari, Firefox, Chrome or Edge - that much can be proved.

You make assertions around why this happened, and present it as fact. That needs to stop. For example:

Browsers ultimately rejected this part of the outline

We could be in the same situation if they simply forgot to implement it, which isnt a rejection - this could also happen with your proposal. Maybe it was rejected, but because the outline comes at performance cost - which would also be an issue for your proposal. Maybe the spec is buggy / too complicated. Or maybe it's something else, or some combination of things (I covered this in my post).

Why do you think it's wise to pick the reason you like best and assert that it's "the fact"? Especially when the other possibilities would come with their own approach to fixing the problem.

Also "see other blog posts" is not providing evidence. That's just pretending you have evidence, but avoiding presenting it so it can't be reviewed. "I got evidence. I got the best evidence. I got the best evidence you've ever seen" etc etc.

You’d have a better shot at getting this info from (at least) Chrome than me

Yes, I've been putting effort into this. I'll report actual data when I have it.

That isn't what "proving a negative" means.

I must have been mistaken in the phrasing choice. My apologies, Jake.

You make assertions around why [browsers ultimately rejected this part of the outline algorithm] happened, and present it as fact. That needs to stop.

I said “Browsers ultimately rejected (see other blog posts) this part of the outline; which was one of the most important parts (see your own comments)”.

I said this because @domenic wrote:

At some point we cannot claim that user agents are broken. They are instead rejecting our change request.

And because you wrote:

Correct heading levels in the AT ... which in my opinion is the most important bit.

And because Marco Zehe wrote:

... in addition to evangelizing this monster to web developers, which would be hard enough in itself, we'd have to explain a possible situation where the same code gives totally different results in screen readers. An h2 within a section is in scenario 1 turned into a heading 4711 correctly, whereas in scenario 2, due to lack of implementation, it is still an h2.

And later:

The "correct implementation" bit was the problem. Due to either a bug or misunderstanding of the spec or whatever, it was very easy to get to ridiculously high heading levels by just nesting an h6 into 5 levels of sections, for example. Anyway this was so screwed up that Freedom Scientific pulled it in JAWS 15 and went back to using h1 through h6 as they always were, ignoring section nesting. And thus far, that was the only "implementation" of the accessibility side of that outline algorithm in existence.

And later:

... so I proposed a stand-alone new element instead of an attribute.

A new element ... hey ... there’s an idea ;)

Contributor

@jakearchibald

  1. New tags (and all the DOM interfaces & parsing rules that go with them)
  2. New default CSS to recognise contextual headings
  3. Correct heading levels in the AT
    1 & 2 were completed

I suggest that 2 is far from complete as it only takes into account styling of nested h1's (h2-h6 are ignored) in sectioning content and does not take into account the styling of headings in sectioning roots at all.

jakearchibald commented Mar 8, 2017 edited

@jonathantneal Now you're getting it! Point to actual evidence!

Yes, failure to implement can be seen as a rejection. But maybe the reason was "can't be arsed", in which case your proposal also fails, or "bad for performance", in which case your proposal also fails etc etc. Knowing the reason is so important.

As you can see, I participated in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25003 back in the day. And we're still short of proper reasons and failure cases. I do think the outline spec needs tweaked or at the very least clarified, but this is true regardless of whether or not we just throw a new tag at the problem.

bkardell commented Mar 8, 2017

After having several conversations, and seeing lots of circling and frustration, I'd like to make a proposal...

I propose that we:

Either close this issue or at least agree to a "cease-fire" among the active participants until we have data collected. In other words, let's not just argue the same points here. Let's save this thread (or create a new one) for a definitive-ish answer to "why was it never implemented by browsers" and potentially looping in data once we have actually collected it. This will not be soon.

Agree on a repo dedicated toward:

  • collecting markup use cases,
  • collecting the various ideas around how this should work
  • requiring that each 'idea' answer all of the same questions.
  • Work together on getting good polyfills for any of these proposals, even the ideas you maybe don't particularly like/support.

"Debates of quality" also shouldn't happen there. No "better or worse" arguments - that's not the point of the repo. The point of the repo is to collect data -- same inputs/situations and like for like "answers" that can be evaluated. You can open an issue there if there is a question you'd like all 'proposals' to answer for that like-for-like comparison purpose.

Once we have 2 or 3, let's share them and let some people use them and ask questions and begin to collect that feedback and let's figure out then how we can best qualitatively evaluate all of the data.

I've just sort of vaguely sketched something out here - https://github.com/bkardell/outline .. We're free to use that, or create another, I don't really care as long as there is a place.

@stevefaulkner yeah, there's work still to be done there. Although I fear that changing styles may be tougher on compatibility than changing the AT level.

@bkardell that's pretty much the conclusion I came to https://jakearchibald.com/2017/do-we-need-a-new-heading-element/#moving-forward - so yeah, I agree!

jakearchibald commented Mar 8, 2017 edited

@stevefaulkner back in the day (https://www.w3.org/Bugs/Public/show_bug.cgi?id=25003), there were suggestions that simple markup could land you at heading levels in the 1000s. I asked for examples but never got any, are you aware of any? That'd be a perfect example of something to get in @bkardell's repo.

I’m thankful for this conversation and agree with @jakearchibald & @bkardell on next steps. I’ll continue efforts into outline and h-element-spec. Since I opened it, I think I can close this issue based on the tags needs implementations and needs incubation. For future reference: I’d encourage someone else to either re-open this or start a new issue once there’s significantly more evidence to discuss.

Oh, and one more thing, @bkardell.

Work together on getting good polyfills for any of these proposals, even the ideas you maybe don't particularly like/support.

You have my sword.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment