Add <h> element #774
Comments
|
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 |
Exactly. |
That’s fair. Here is a speculative polyfill: http://codepen.io/jonneal/details/wgombw/
I expect to rely on existing expectations; following what browsers and a11y tools already interpret when, say, a Relevant: https://www.w3.org/TR/html5/sections.html#outlines |
|
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? |
|
Fwiw, when I need a levelless heading, I currently use either or a bare 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/ Also, considering the forever-weird magic behind the existing |
|
Okay, let’s make this happen. I’ve written a specification proposal for a contextual heading https://rawgit.com/jonathantneal/h-element-spec/gh-pages/ I’ve written a speculative polyfill that gives the appropriate 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 |
|
I haven't had my morning coffee so this took me a minute to grok. I think when most people think about |
|
This is quite sensible. 👍 |
|
Thanks for the proposal and polyfill @jonathantneal |
|
Awesome idea @jonathantneal, seems quite logical! How about |
|
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. |
|
@domjtalbot first of all, |
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/ So I don't understand your conclusion, which seems to be the opposite - if you have the nesting calculated for you, something will go wrong. Or did I just misunderstand? |
|
@chaals, you're coming from optimistic conclusion that outline is always correct and everyone knows what they are doing. But since outline is just and idea existing only in the spec, but not in browsers, developers’ minds or real-life code, I'm inclined to think that it's wrong by default and as an author of a module you can't control the proper nesting level. I wouldn't rely on outline when |
|
@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 results in 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. |
|
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). |
|
@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 |
|
Even if the idea is really not bad, I see a lot of cases where it will fail. Consider this code : How do the browser will know that it means : or 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. |
|
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 Sebastian |
|
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. |
|
@nico3333fr, 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 |
|
Some thoughts regarding the CSS part: Obviously, nobody wants to write section section section h { font-size: x }for an h4. Also, it becomes highly complex when you have to consider all the combinations of sectioning element, like section article section h,
article section article h,
article article section h,
section article article h,
article article article h,
etc {
font-size: x;
}In which case, I would propose that heading element selectors acted as aliases for nesting depth. So h2 {
font-size: x;
}would effectively be h2,
section h,
article h,
aside h,
nav h {
font-size: x;
} |
|
Why is this proposal better than the current |
|
@jakearchibald My first thought is that the " Yeah, |
|
@Heydon I get that the outline isn't implemented, but neither is |
|
@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. |
|
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'. |
|
There seems to be a bit of a misconception of what introducing the It's not a case of either using The Reading the spec on <article>
<h>Article title</h>
<p>Lorem ipsum</p>
<h2>A secondary heading</h2>
<p>Lorem ipsum</p>
<h3>A tertiary heading</h3>
<p>Lorem ipsum</p>
<section>
<h>heading</h>
<p>Lorem ipsum</p>
<section>
</article>That is equivalent to writing this: <article>
<h>Article title</h>
<p>Lorem ipsum</p>
<section>
<h>A secondary heading</h>
<p>Lorem ipsum</p>
<section>
<h>A tertiary heading</h>
<p>Lorem ipsum</p>
</section>
</section>
<section>
<h>heading</h>
<p>Lorem ipsum</p>
<section>
</article> |
|
What would happen if the document did contain both ```<h>``` and
```<h1/6>``` elements?
|
|
I think the instant the browser detects a So |
|
...actually this is starting to sound silly. The For that all we really need is an No changes need to be made to the document outline spec other than mentioning this new attribute. So there is less work involved in adding an attribute over adding a I also like the idea someone brought up that it is better for a non-supporting browser to fall back to a heading than to fall back to a |
|
A |
Do you mean |
|
For backward compatibility: or Old label is a sort of heading with additional accessability feature - changing the cursor focus! ;) |
When I wrote that comment, I meant what I said. But in writing that comment, I realised how silly the If you replace the |
|
@viT-1 would you really prefer to write a gazillion ID's that all need to be unique in every different context that they are used than nest heading elements inside sectioning elements?!? |
|
@Dan503 If "label" haven't attribute "for" it can be matched by "sections" nesting, but how can it be matched if h/label not on a first nesting level of DOM? Calculate h-level only by "section" elements? |
|
@danieltj27, I stopped working on the proposal for a number of selfish reasons. First, I can be very unfocused and easily discouraged. Second, Google and Bing correctly displayed headings with @Dan503, yea using I’m just getting back from vacation this morning, so I hope y’all will forgive me for not including citations. @viT-1, definitely look at |
Yes, it is called the document outline algorithm. It is the whole reason for this issue because we want browsers to implement it. You can learn more about it here: |
|
@jonathantneal : I'm not sold on having an That all depends on if What do you think? |
|
Additionally, as you've written, we could use the polyfill to swap out h1s with h2s and such, but I think relying on |
|
From the screen reader testing I have done in NVDA, Eg. |
|
By the way, I love the idea of hfill just being a drop in polyfill for the document outline algorithm powered by real heading elements 😊 |
|
Totally! If there are no issues with it, I'd start using it everywhere right away. |
|
Note that browser makers have not implemented the document outline algorithm as proposed generally because it requires too much complexity when faced with real content. That is part of the reason the document outline algorithm never made it into the final W3C specification. Part of the challenge is dealing with highly-nested sections, thanks to tooling that treats Before proposing a new element, the document outline algorithm needs to be mapped and defined in a way that browsers will implement. A polyfill can do that. Create the proof of concept in a polyfill and then elevate that as a proposed rule-set to W3C. Whether it is encoded as an Definitely do not use |
|
Here’s a link to a comparison of 3 different document outline solutions as they would apply to a dozen different content patterns: https://bkardell.com/outline/ |
|
https://bkardell.com/outline/compare.html Use case 1, Outline proposal polyfill <h1>Some articles</h1>
<article>
<h3>This is an old legacy article</h3>
<p>It's stored in a CMS and assumes headings start at h3.</p>
<h4>But then the template changed!</h4>
<p>The site wanted to make use of nested sections, but this content should still work.</p>
</article>
The polyfill makes that out as a <article>
<h1>heading one</h1>
<p>lorem ipsum</p>
<h2>heading two</h2>
<p>lorem ipsum</p>
</article>The outline algorithm says that the above is the equivalent of writing this: <article>
<h1>heading one</h1>
<p>lorem ipsum</p>
<section>
<h1>heading two</h1>
<p>lorem ipsum</p>
</section>
</article>Currently the polyfill seems to be doing this instead: <article>
<h1>heading one</h1>
<p>lorem ipsum</p>
<h1>heading two</h1>
<p>lorem ipsum</p>
</article>That is incorrect. In other words, "But then the template changed!" heading should be turned into a (Is there a better place for issues like this to be logged?) |
|
In my opinion, it's probably time to admit that the concept of "HTML5 document outline" based on the "sectioning content" nesting level has failed, and further discussing of hypothetical ways to "fix" it is quite pointless. Especially in the W3C HTML repo, given that, AFAIK, HTML5.3 is not going to become W3C Rec. It has been years since W3C and most HTML evangelists started to discourage relying on this "fictional" outline. Let's face the cruel reality: the "HTML5 document outline" is effectively dead. Instead, I suggest to open an issue against the WHATWG HTML repo about retiring the "document outline" concept (as effectively irrelevant to any practical application) and redefining the current "Sectioning content" elements solely in terms of ARIA Landmark roles mapping. (Upd.: it has already been discussed there). This is way more practical (since the corresponding mappings are widely supported by virtually all modern browsers) and it would simplify the mental model of these elements for the authors a lot, making these element follow the single responsibility principle and eliminating the confusion about After that, we would be free to investigate the possibilities to create better – more flexible and descriptive – outlines for future documents only, without any backwards compatibility concerns. We could account for @AmeliaBR's note that heading levels in the same context can be used to express the relative importance of the same-rank sections. It could be a completely new element with a single functionality of creating separate contexts in the outline, or an attribute for existing grouping elements – whatever would be easier for implementation... |
|
You are entitled to your opinion |
|
The outline algorithm is too good and has had too much work go into it to just give up on it and with how modular focused the web has become it's more important than ever that it get implemented by browsers. |
|
The latest work on a simplified algorithm is at whatwg/html#3499 |
|
@Dan503, exactly because the outline algorithm itself is good and too important for the modular web, I suggest to try more realistic options to make it real than persuading browser vendors who have been rejecting the requests to implement it for years to change their mind by continuing a discussion in a closed issue to a (de facto) discontinued spec:( @jakearchibald, thanks a lot for a link to the latest work! |
and others
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.The text was updated successfully, but these errors were encountered: