jonathantneal commented 7 years ago

The State of <H>

February 2017

It’s been 162 likes, 143 comments, 16 dislikes, 7 hoorays, and 1 month since I proposed that the W3C add an <h> element to HTML.

<h> is intended to be a new heading element and the successor to <h1> through <h6>. The concept remains simple; they all represent the heading for a section.

The <h1> through <h6> heading elements we all know come to HTML from 1969’s excellent Generalized_Markup_Language (GML), where flat structures were used to communicate simple rich text.

:h1.This is GML
:p.GML supported hierarchical containers, such as
:ol.
:li.Ordered lists (like this one),
:li.Unordered lists, and
:li.Definition lists
:eol.
as well as simple structures.

From 1989 to 1991, Tim Berners-Lee developed HTML from that GML predecessor, and by 1993, developers realized the flat h1-h6 concepts were problematic. The issue would continue to rise up from time to time, as it has now.

What makes this attempt unique is the attention we now have and whom we have attention from. I see interest coming from;

Charles "Chaals" McCathieNevile, a W3C Board Member;
Amelia Bellamy-Royds, a W3C Invited Expert developing SVG and ARIA specifications;
Brian Kardell, Co-Founder/Chair, W3C Extensible Web CG;
Jake Archibald, developer advocate for Google Chrome;
Léonie Watson, Communications Director & Principal Engineer for The Paciello Group;

And, seriously, many other web heroes. Following this interest, it was the top story on FrontEnd Focus last week.

Now, we don’t all yet agree with how to move on from the “flat”-ness of <h1> through <h6>, but the consensus is that we need contextual headings, and that we’ll be much better off once we get them.

How can there be consensus and disagreement? Well, if you want to understand the consensus for contextual headings, I’d recommend reading Brian Kardell’s “Headings and the Seinfeld Pitch", and if you want to understand the disagreement, read any comment discussing the document outline from my original proposal. The main concern is how to implement the document outline.

Here’s one prompt; should we implement the outline to redefine existing <h1> through <h6> elements to be contextual headings regardless of when they use 1-6?

<body>
    <h6>i am contextually h1</h6>
    <section><h1>i am contextually h2</h1></section>
</body>

Do we (developers, browsers, search engines) want that? If we don’t, then do we want to leave the existing definitions as-is and recommend <h> instead?

Another example; should we ignore outline depth for sections without headings? (and it’s worth remembering that sectioning elements were supposed to have headings, but developers never really followed this rule)

<body>
    <main>
        <section>
            <article>
                <h>as the first heading, am i contextually like an h1?</h>
            </article>
        </section>
    </main>
</body>

Do we (developers, browsers, search engines, screen readers) want that? If we don’t, do we leave the sections untitled and and recommend <h> usage once again? What even is the document outline? These are good, fair questions that help us solve the problem.

I hope the helps you understand where things are at. I couldn’t be happier with the interest and energy being put into moving contextual headings forward. My biggest concern is that we’ll lose interest in discussing these deeper issues, because we also have day-jobs, and web standards take time.

Please don’t forget <h>. Don’t forget that we can almost always solve problems, but we can’t always solve problems right away.

Cheers,
Jonathan

jakearchibald commented 7 years ago

The self-congratulatory nature of this issue is a little unsettling.

I think what we "want" is the ability to define a section with headings in a way that can be put anywhere in a document without breaking the outline. But from then, it's less about "wants" and more about evidence, and that's the hard work.

We already have an outline algorithm. If implementing it improves the existing web, that's the priority.

If implementing the outline as-is presents problems, we need to compare the impact of a new element to enhancing the existing headings, via some form of opt-in to the currently defined outline spec. That way you wouldn't be giving a new non-semantic element to old user agents.

If that isn't viable, maybe we can start looking at a new element.

Evidence should be what drives this, not GitHub likes & hoorays.

verlok commented 7 years ago

I'd like to have the h element, I think it would solve many issues and would cleanse the mess a bit. But what @jakearchibald wrote is to be considered: there are legacy issues

Marat-Tanalin commented 7 years ago

Sometimes I think we should just start using the H element and put up with it being invalid and not accessible for some time until it’s used so widely that decision makers just couldn’t ignore it.

Marat-Tanalin commented 7 years ago

@jakearchibald

Evidence should be what drives this.

For practicing web developers, the need for a levelless heading element is evident.

jakearchibald commented 7 years ago

I'm a practicing web developer and I'm unaware of good evidence in relation to the options above.

This is my frustration with this whole thing. We really need to do better than "we need a new element because I said so".

jonathantneal commented 7 years ago

@jakearchibald, thanks for reading. These technical concerns are being chewed on. What advice might you offer to help us collect more useful data? The accessible results provided by Paciello Group members is very useful. Are you looking for something more like @dskoziol's results?

It's also been my experience with any open source project I've been a part of that no good idea becomes very useful to others without a few hoorays, likes, and comments. The energy and time being put into this by all of us is valid and valuable to celebrate, because people can forget quickly. I don't see how leading with insulting my optimism was terribly helpful, but I'll do my best to sober these updates and take that feedback into account as well.

bkardell commented 7 years ago

I'm not sure what more we can do in that area to convince implementers - there are open browser bugs by @stevefaulkner, @jakearchibald and probably others that I am unaware of (apologies if I have excluded you) going back years. Along the way we also changed advice because "until everyone has it by default" created problematic conditions that were worse than just not having it at all.

At the same time, I am personally somewhat ambivalent about that fact. I'm unsure where @jakearchibald and I agree or disagree here because I also want data. I don't think that what we argued about and ultimately got written down years ago but 0 people implemented is in any way holy. There's no proof that it yields something much better. If we had a "pact" tomorrow that this would get some kind of prioritization in all browsers. We're a years from getting that done, deployed and used to see how the masses did with it. In the meantime devs are stuck with nada, and it's entirely possible in the end we could go from "largely messed up traditional html 'outline'" to "largely messed up not quite html5 outlines". This is not a great cycle when it happens.

That's why I'm personally really interested in experimentation with speculative polyfills/preprocessors with solutions to this problem and why I care less about whether they actually match the proposal. We can float ideas, they can even compete - we can see what works, and then worry about the rest when we've proven something. If the HTML5 document outline is really good "as is" experiments should be able to prove that in fairly short order by comparison. It should "win out" over other ideas... and I'd like to see the variant ideas too.

Marat-Tanalin commented 7 years ago

@jakearchibald

We really need to do better than "we need a new element because I said so".

Given that hundreds of people explicitly agree, and just a few disagree, it’s those who disagree should (try to) prove they are right, not those who agree.

Spec editors should just do what web developers want, like they did e.g. with restoring the TIME element. For the H element, this should probably be as simple as borrowing the corresponding part of XHTML2.

The only potential issue here is that AFAICT decisions are currently actually made by WHATWG, not by W3C.

jakearchibald commented 7 years ago

Please don't make me explain the burden of proof here. We really need to be better than this. Can we do this with evidence? As in, evidence of user impact?

Marat-Tanalin commented 7 years ago

@jakearchibald You probably ask too many questions without providing answers.

bkardell commented 7 years ago

fwiw, again, I would like to see proof myself... of anything, including the document outline as written. It is in our power to attempt to prove any of these pretty well IMO and I don't place a lot of trust in "we agree in speculative words". Frequently when you get down to tacks we don't understand the words and ultimately if devs don't use them well, it's for nothing. The proof is in the pudding and it seems there are enough people who should be able to participate in the proving to provide a really compelling case through actual use of speculative solutions.

jakearchibald commented 7 years ago

@Marat-Tanalin your decent into personal insults and assumptions speak to your attitude about evidence.

I hope others involved in this issue don't condone this behaviour, else I'm out.

Marat-Tanalin commented 7 years ago

@jakearchibald No insults intended at all, just some observations as for nature of your contributions so far. Please don’t substitute notions. Just please try to be more specific, substantive and helpful.

jakearchibald commented 7 years ago

You have made a claim, that we need this new element rather than fix what we've got. The burden of proof sits with you.

Let's do this with evidence, not insults and baseless suggestions.

bkardell commented 7 years ago

The only potential issue here is that AFAICT decisions are currently actually made by WHATWG, not by W3C.

Meh, that's just not so - the truth is that regardless of body, nobody writing text has the power, influence or authority to ultimately get anyone to implement anything. Getting something to cross the finish line is hard, period. Even if you are a browser vendor, it's not easy to convince others to follow. It's not "where it was speced" as much as "can you get vendors to agree and prioritize" Both fiddle with their processes/work modes to try to improve the success rate/communication model.

stevefaulkner commented 7 years ago

@jakearchibald is not the enemy here, he is actually trying to engage productively. One of the things that needs to be done when getting a feature implemented is to get implementers interested. You do so by providing evidence that the feature is useful for users and developers and its implementation is not an undue burden.

stevefaulkner commented 7 years ago

The only potential issue here is that AFAICT decisions are currently actually made by WHATWG, not by W3C.

Agree with @bkardell, whatwg and w3c are just venues where features are discussed, vendors participate in both and decisions are made in both, but not by the whatwg or w3c, but by the vendors.

A few years back i developed the <main> element, did research, provided a spec and debated in various fora, both whatwg and w3c included. I also worked with implementers directly via mailing lists and bugs. It was not an easy ride, but by persevering and backing up the feature with data, it got implemented, despite vehement opposition from hixie. Things get decided by people not standards orgs.

Marat-Tanalin commented 7 years ago

@jakearchibald / Looks like “evidence” is a new buzzword of web standards. /

I’m fortunately not the proposal author, so the “burden of proof” doesn’t sit with me, but please see my previous comment. The fact that there are ten times more people who support the idea than those who don’t speaks for itself.

Other than that, as I said, according to my experience, search engines don’t account for sectioning elements when interpreting headings’ levels, but only an official representative of Google or Yandex could confirm or disprove that. For me, the inevitable legacy meaning of numbered headings is the main disadvantage of them compared with a new levelless-heading element free of any unwanted legacy.

Marat-Tanalin commented 7 years ago

@stevefaulkner Thanks for your useful clarification about WHATWG and W3C. I’d be glad if W3C was still responsible for making decisions as for what to add to specs.

Marat-Tanalin commented 7 years ago

@bkardell

I'm not sure what more we can do in that area to convince implementers - there are open browser bugs by @stevefaulkner, @jakearchibald

Could you provide links to those bugs? Thanks.

jakearchibald commented 7 years ago

You've already been given them https://github.com/w3c/html/issues/774#issuecomment-278305120. C'mon, we really need a higher quality of discourse here.

Marat-Tanalin commented 7 years ago

@jakearchibald Ah, thanks, those are about outline while I thought @bkardell means bugs specifically about a levelless heading.

stevefaulkner commented 7 years ago

Do we (developers, browsers, search engines) want that? If we don’t, then do we want to leave the existing >definitions as-is and recommend instead?

Having both will lead (i think) to the worst of both worlds. The current outline algorithm deals with h1-h6 and their use, with or without sectioning elements (as h1-h6 themselves create implicit sections). the <h> element would be an additional heading element that is part of the document outline.

verlok commented 7 years ago

Let's imagine for a second we have of h element in specs. At day zero, browsers won't have the ability to read it in the outline algorithms, and so search engines. They would have to rely on the sectioning content the h element is in. So what's the difference with using the h1 tag for every heading starting today?

jakearchibald commented 7 years ago

That's what the spec says already.

stevefaulkner commented 7 years ago

That's what the spec says already.

the WHATWG spec may be, the W3C HTML spec does not, for obvious reasons.

These elements have a rank given by the number in their name. The h1 element has the highest rank, the h6 element has the lowest rank, and two elements with the same name have equal rank.

Use the rank of heading elements to create the document outline. https://w3c.github.io/html/sections.html#the-h1-h2-h3-h4-h5-and-h6-elements

bkardell commented 7 years ago

Actually, from what I understand that advice is largely rescinded for this reason. "day 0" is misleadingly simple though - until everyone can just assume it is commonly understood this is a problem. In standards land, that is probably many years. Even if everyone prioritized this tomorrow, we would still be years from being able to safely assume everyone had it. Thus, a polyfill would be necessary anyway. Thus a speculative polyfill that allows us to test that before hand is even better.

Also, it's "even better" because a polyfill does its work by adding aria attributes for role="heading" and aria-level which mean the same thing and have for a considerable amount of time, so like... browsers, search engines, AT, etc -- they already do in fact "understand" as near as I can tell.

stevefaulkner commented 7 years ago

@bkardell There have been polyfills of this nature available for years, If people want to use them they can already.

jakearchibald commented 7 years ago

Gosh we're really going round in circles. I've said what I think the next steps should be in the main thread, along with the evidence we need & ways we might be able to get it.

Unsubscribing from this thread. It seems entirely redundant.

Marat-Tanalin commented 7 years ago

@verlok

Let's imagine for a second we have of h element in specs. At day zero, browsers won't have the ability to read it in the outline algorithms, and so search engines.

Please see my comment in the main thread.

@bkardell

a polyfill does its work by adding aria attributes for role="heading" and aria-level

And inevitably has negative performance impact (while not even adding anything useful for, let’s face it, majority of users) since it’s pure JS.

bkardell commented 7 years ago

@stevefaulkner I know about yours, but that was also a polymer element which isn't quite a custom element, the burden/cost is more to use. Do you have links to others?

jonathantneal commented 7 years ago

Getting the < 1kb polyfill (or the pre-compiled editions) into production sites might be a valuable next step - and from there measuring the SEO impact. I'll see what I can do, but I'm open to other advice here.

Marat-Tanalin commented 7 years ago

The simplest and most performant polyfill would probably be just to set the role="heading" attribute for all levelless headings:

Array.from(document.getElementsByTagName('h')).forEach(function(element) {
    element.setAttribute('role', 'heading');
});

But I’m not sure whether this makes much sense without calculating and setting heading’s level while such calculations may be slow.

jonathantneal commented 7 years ago

@Marat-Tanalin:

[the polyfill] has negative performance impact (while not even adding anything useful for, let’s face it, majority of users) since it’s pure JS.

I understand where you might be coming from, but please consider:

Defining a majority of users is subjective.
majority of users !== significant users.
Non-JS versions are available through PostCSS, PostHTML, and Reshape.

The simplest and most performant polyfill would probably be just to set the role="heading" attribute for all levelless headings ... But I’m not sure whether this makes much sense without calculating and setting heading’s level while such calculations may be slow.

The level is valuable. In a 2012 WebAIM Screen Reader User Survey, 47% of assistive technology (AT) respondents found heading levels to be very useful, and another 35% of respondents found heading levels at least useful (totaling 82%).

alexmorris commented 7 years ago

If this is considered a legitimately interesting addition then try to frame the proposal around something tangible. Explain the problem you trying to solve using actual real world examples (not arbitrary snippets) and maybe describe the benefits you hope for as user stories?

alexmorris commented 7 years ago

FWIW having spent last 18 months working very closely with users of assistive technologies, reliance on ARIA isn't realistic or desirable due to terrible implementation in JAWS et al. You'd need a very compelling argument to lose the hierarchical nature of existing headings or risk alienating the kinds of users that need these semantics more than anyone else

stevefaulkner commented 7 years ago

reliance on ARIA isn't realistic or desirable due to terrible implementation in JAWS et al.

a little more detail is needed in this statement, for it to be useful, data suggests ARIA is well supported for many of its features, but some are still problematic. I don't believe role=heading and aria-level are problematic features as what is presented in the accessibility tree is no different than what h1-h6 present.

SelenIT commented 7 years ago

Most discussions regarding HTML5 outlining algoritm I've seen are about sectioning content and its interaction with native heading rank. But in HTML5 there are also sectoining roots that, by definition, should just make the headings inside them "not contribute to the outlines of their ancestors". I'd like to know what is the implementation status of these? How do browsers and ATs currently treat headings inside table cells, block quotes, figures, fieldsets etc.?

stevefaulkner commented 7 years ago

How do browsers and ATs currently treat headings inside table cells, block quotes, figures, fieldsets etc.?

as the outline is not implemented they have no effect, h1-h6 are exposed the same way as they are in any other part of the document.

Marat-Tanalin commented 7 years ago

@jonathantneal

Defining a majority of users is subjective.

Yes, but not in this case. Your percentages are relative to total number of AT users which are obviously a minority relative to total number of all users. (Fwiw, I didn’t mean anything bad, just some sensible performance-related thoughts.)

In this regard, it would probably be useful to be able to detect whether AT is used, so that non-AT-users wouldn’t unreasonably suffer from negative performance impact of something they don’t need/use. Something like:

if (window.screenReaderUsed) {
    // Apply a potentially slow accessibility-related polyfill.
}

verlok commented 4 years ago

I think this issue could be closeuby now.

jonathantneal commented 4 years ago

I concur. 😄

Marat-Tanalin commented 4 years ago

I would still love to have the generic-heading H element in HTML.

jonathantneal / h-element-spec

The State of <H>: February 2017 #1

The State of <H>