Add <h> element #774

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

Comments

Projects
None yet
@jonathantneal

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

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

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

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

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

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

@bkardell

This comment has been minimized.

Show comment
Hide comment
@bkardell

bkardell Jan 17, 2017

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.

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

@Marat-Tanalin

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Jan 17, 2017

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

Exactly.

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

Exactly.

@jonathantneal

This comment has been minimized.

Show comment
Hide comment
@jonathantneal

jonathantneal Jan 18, 2017

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

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

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

consider aria roles for sections

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

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

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Feb 6, 2017

Collaborator

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?

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

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Feb 6, 2017

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.

Marat-Tanalin commented Feb 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jonathantneal

jonathantneal Feb 7, 2017

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

jonathantneal commented Feb 7, 2017

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

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

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

https://github.com/jonathantneal/hfill

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

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

@rubencodes

This comment has been minimized.

Show comment
Hide comment
@rubencodes

rubencodes Feb 7, 2017

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.

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

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

@pxsmith

This comment has been minimized.

Show comment
Hide comment
@pxsmith

pxsmith Feb 7, 2017

This is quite sensible. 👍

pxsmith commented Feb 7, 2017

This is quite sensible. 👍

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Feb 7, 2017

Collaborator

Thanks for the proposal and polyfill @jonathantneal

Collaborator

LJWatson commented Feb 7, 2017

Thanks for the proposal and polyfill @jonathantneal

@domjtalbot

This comment has been minimized.

Show comment
Hide comment
@domjtalbot

domjtalbot Feb 7, 2017

Awesome idea @jonathantneal, seems quite logical!

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

Awesome idea @jonathantneal, seems quite logical!

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

@pepelsbey

This comment has been minimized.

Show comment
Hide comment
@pepelsbey

pepelsbey Feb 7, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@pxsmith

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

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.

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Feb 8, 2017

Collaborator

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

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?

@pepelsbey

This comment has been minimized.

Show comment
Hide comment
@pepelsbey

pepelsbey Feb 8, 2017

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

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

@stevefaulkner

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Feb 8, 2017

Contributor

@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

stevefaulkner commented Feb 8, 2017

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

for example

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

results in
h1
h3

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

@stevefaulkner

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Feb 8, 2017

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

Contributor

stevefaulkner commented Feb 8, 2017

252 HTML5 pages using the section element

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

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Feb 8, 2017

Collaborator

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

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.

@nico3333fr

This comment has been minimized.

Show comment
Hide comment
@nico3333fr

nico3333fr Feb 8, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@SebastianZ

SebastianZ Feb 8, 2017

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

SebastianZ commented Feb 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Heydon

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

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

This comment has been minimized.

Show comment
Hide comment
@AndySky21

AndySky21 Feb 8, 2017

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

AndySky21 commented Feb 8, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@Heydon

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

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

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Feb 8, 2017

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

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

@Heydon

This comment has been minimized.

Show comment
Hide comment
@Heydon

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

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Feb 8, 2017

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

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

@AndySky21

This comment has been minimized.

Show comment
Hide comment
@AndySky21

AndySky21 Feb 8, 2017

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

@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

This comment has been minimized.

Show comment
Hide comment
@Heydon

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

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

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Feb 8, 2017

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

Marat-Tanalin commented Feb 8, 2017

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

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

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

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Feb 8, 2017

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.

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

@Heydon

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

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

@stevefaulkner

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Feb 8, 2017

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.

Contributor

stevefaulkner commented Feb 8, 2017

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

@nico3333fr

This comment has been minimized.

Show comment
Hide comment
@nico3333fr

nico3333fr Feb 8, 2017

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

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

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

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

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

@Marat-Tanalin

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Feb 8, 2017

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.

SEO arguments seem really tenuous to me.

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

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

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

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Feb 8, 2017

Collaborator

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

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

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Feb 8, 2017

@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

@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

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Feb 8, 2017

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

Marat-Tanalin commented Feb 8, 2017

@stevefaulkner

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

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

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

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

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Feb 8, 2017

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

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

@amandarush

This comment has been minimized.

Show comment
Hide comment
@amandarush

amandarush Feb 21, 2017

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.

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.

@stevefaulkner

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Feb 21, 2017

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.

Contributor

stevefaulkner commented Feb 21, 2017

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.

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Feb 21, 2017

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

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

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Feb 21, 2017

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.

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

This comment has been minimized.

Show comment
Hide comment
@patrickdark

patrickdark Feb 21, 2017

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.

patrickdark commented Feb 21, 2017

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.

@stevefaulkner

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Feb 22, 2017

Contributor

related #806

Contributor

stevefaulkner commented Feb 22, 2017

related #806

@madbonkey

This comment has been minimized.

Show comment
Hide comment
@madbonkey

madbonkey Feb 24, 2017

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

madbonkey commented Feb 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bkardell

bkardell Feb 28, 2017

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.

bkardell commented Feb 28, 2017

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.

@patrickdark

This comment has been minimized.

Show comment
Hide comment
@patrickdark

patrickdark Feb 28, 2017

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

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

@jourdanritchey

This comment has been minimized.

Show comment
Hide comment
@jourdanritchey

jourdanritchey Mar 5, 2017

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.

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.

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Mar 5, 2017

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

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

@jourdanritchey

This comment has been minimized.

Show comment
Hide comment
@jourdanritchey

jourdanritchey Mar 5, 2017

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

@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

This comment has been minimized.

Show comment
Hide comment
@bkardell

bkardell Mar 5, 2017

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

bkardell commented Mar 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Mar 5, 2017

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

jakearchibald commented Mar 5, 2017

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

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Mar 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bkardell

bkardell Mar 5, 2017

@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 commented Mar 5, 2017

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

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Mar 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bkardell

bkardell Mar 5, 2017

@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 commented Mar 5, 2017

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

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Mar 5, 2017

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

@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

This comment has been minimized.

Show comment
Hide comment
@Alohci

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

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

This comment has been minimized.

Show comment
Hide comment
@bkardell

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

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.

@jourdanritchey

This comment has been minimized.

Show comment
Hide comment
@jourdanritchey

jourdanritchey Mar 6, 2017

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

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Mar 6, 2017

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.

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.

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Mar 7, 2017

Collaborator

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

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

@jonathantneal

This comment has been minimized.

Show comment
Hide comment
@jonathantneal

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

@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

This comment has been minimized.

Show comment
Hide comment
@AmeliaBR

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

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

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Mar 7, 2017

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

jakearchibald commented Mar 7, 2017

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

@jonathantneal

This comment has been minimized.

Show comment
Hide comment
@jonathantneal

jonathantneal Mar 7, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Mar 8, 2017

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

jakearchibald commented Mar 8, 2017

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

@jonathantneal

This comment has been minimized.

Show comment
Hide comment
@jonathantneal

jonathantneal Mar 8, 2017

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

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

@stevefaulkner

This comment has been minimized.

Show comment
Hide comment
@stevefaulkner

stevefaulkner Mar 8, 2017

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.

Contributor

stevefaulkner commented Mar 8, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Mar 8, 2017

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

jakearchibald commented Mar 8, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@bkardell

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

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.

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Mar 8, 2017

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

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

@jakearchibald

This comment has been minimized.

Show comment
Hide comment

@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

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Mar 8, 2017

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

jakearchibald commented Mar 8, 2017

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

@jonathantneal

This comment has been minimized.

Show comment
Hide comment
@jonathantneal

jonathantneal Mar 8, 2017

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.

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.

@danieltj27

This comment has been minimized.

Show comment
Hide comment
@danieltj27

danieltj27 Apr 26, 2018

What's the progress on this thus far? I've checked out the h-element-spec repository but looks like there's not been any movement since early February. Is this any particular path we need to take now or a way to keep things moving? I'm curious on how we can keep this going and on the road to making it 'official'.

What's the progress on this thus far? I've checked out the h-element-spec repository but looks like there's not been any movement since early February. Is this any particular path we need to take now or a way to keep things moving? I'm curious on how we can keep this going and on the road to making it 'official'.

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