
Do we need a new heading element in HTML? - jaffathecake
https://jakearchibald.com/2017/do-we-need-a-new-heading-element/
======
TazeTSchnitzel
> The suggestion is that <h> would solve this, as browsers would implement it
> & do the right thing in terms of the accessibility tree.

> This is a common mistake in standards discussion - a mistake I've made many
> times before. You cannot compare the current state of things, beholden to
> reality, with a utopian implementation of some currently non-existent thing.

Ugh, yes, this happens so often: something is implemented badly, so we propose
to add the same thing again under a different name and with subtle
differences, assuming it'll be implemented right this time.

If possible, it's better to try and get the implementations fixed. That may
not even require changes to the standard.

~~~
sjwright
> > You cannot compare the current state of things, beholden to reality, with
> a utopian implementation of some currently non-existent thing.

This feels like a fallacy worthy of a name. Does it have one?

~~~
jaffathecake
Maybe
[https://en.wikipedia.org/wiki/Nirvana_fallacy](https://en.wikipedia.org/wiki/Nirvana_fallacy)
is closest?

~~~
huskyr
"A choice between one realistic achievable possibility and another unrealistic
solution that could in some way be better" is the definition on Wikipedia.
Sounds pretty much spot-on.

------
crazygringo
Heading styles (whether in HTML or word processors) have long been a source of
annoyance for me, because they constantly have to be redone.

Current models all follow the top-down approach -- assume you know your top
sections when you start (H1), then drill down into H2, H3, etc.

But just as often you want to do bottom-up -- start with a short article with
a single heading (H1), then add a sibling section (turn both H1's into H2's,
add the "real" H1), then put those both under a larger section (H2's become
H3's, H1's turn into H2's, new H1), and so on.

 _Any_ manual choice of heading levels is just dumb, frankly. <h> is a great
solution -- I just want to see something similar for word processors as well!

~~~
nkkollaw
You won't have that problem if you use HTML5 sections.

The outline is defined using sections, and you can use all h1s (or at least
h1s are scoped to the section, so more easily managed)

~~~
afloatboat
I would be careful with that approach. I've followed it for a couple of years,
but noticed that browser vendors and other tools have not embraced this
change.

While it's technically still correct, it might backfire in reality. So maybe
this <h>-element would be a welcome addition to the spec.

[https://www.w3.org/wiki/HTML/Usage/Headings/h1only#Heading_s...](https://www.w3.org/wiki/HTML/Usage/Headings/h1only#Heading_semantics_exposed_by_browsers)
[http://html5doctor.com/computer-says-no-to-html5-document-
ou...](http://html5doctor.com/computer-says-no-to-html5-document-outline/)

~~~
corny
It looks like that method is now deprecated in HTML 5.1.
[https://bitsofco.de/document-outlines-in-
html-5-1/](https://bitsofco.de/document-outlines-in-html-5-1/)

------
jasonpeacock
A good editor can automatically fix <hN> values if needed. But if you're
writing an html page, you should already know what you're writing (outline,
editing, review, etc). How often are you re-scoping everything?

Any discussion like this needs a Tufte reference:

 _It is also notable that the Feynman lectures (3 volumes) write about all of
physics in 1800 pages, using only 2 levels of hierarchical headings: chapters
and A-level heads in the text. It also uses the methodology of sentences which
then cumulate sequentially into paragraphs, rather than the grunts of bullet
points. Undergraduate Caltech physics is very complicated material, but it
didn 't require an elaborate hierarchy to organize. A useful decision rule in
thinking and showing is "What would Feynman do?"_

[https://www.edwardtufte.com/bboard/q-and-a-fetch-
msg?msg_id=...](https://www.edwardtufte.com/bboard/q-and-a-fetch-
msg?msg_id=0000hB)

~~~
combatentropy
Indeed. Several times I tried to style the tags h1 through h6 so that they
were distinguished while not getting too extreme. So I used a combination of
font size, weight, underline, and color. When at last I thought I succeeded, I
began to ask myself if it mattered. For what reader could really keep track of
six levels of headings in single page anyway?

Several levels of headings, along with bullet points and numbered lists,
benefit the writer, while you plan your work. But they are not ideal for the
reader. I think the best form for the reader is ironically the well-told yarn:
a series of well-composed "sentences which then cumulate sequentially into
paragraphs," as the venerable Mr. Tufte says.

------
andybak
I _still_ get SEO 'experts' giving reports on sites I've worked on that claim
that skipping from a h1 to a h3 without an intervening h2 will cause lower
Google rankings. If this is actually true then I truly despair of this life.
But I strongly suspect it's the fact that the SEO community seems to only
learn new factoids and never discards old ones.

~~~
jaffathecake
I have no insight, but I'm pretty confident this is nonsense. A lot of sites
have broken heading structures - it'd be a mistake to downrank otherwise good
results because of this.

~~~
duskwuff
Remember -- these are the same "SEO experts" that will happily tell you that
you need to host every web site on its own IP address, even though a Google
employee has said unequivocally (over 10 years ago!) that this has no impact
on ranking.

~~~
pbhjpbhj
I think you'll find the SEO community to be pretty scientific.

Presumably it's Matt Cutts you're referring too - I'm pretty sure he's lied
before about optimisations; Google after all don't want people to know all the
details to avoid gaming the algos. If shared IP is a strong signal for low
quality sites then it's to Google's benefit to avoid confirming that.

------
xg15
Maybe I'm mistaken, but weren't the <h1>, <h2>, etc elements defined to be
essentially equivalent in HTML5, with the number being there for legacy agents
only?

I.e., non-legacy browsers should _already_ ignore the number and only take
nested <section> elements into account when building the tree and calculating
the heading level.

So the following:

    
    
      <h1>Heading</h1>
      <section>
       <h1>Sub heading</h1>
       ...
      </section>
    

would be perfectly valid.

~~~
adiabatty
Not quite. You can do things like this, and the `section > h2` will properly
be a subheading of the `section > h1`, which will be a subheading of `article
> h1`:

    
    
        <article>
          <h1>Why Fancy Keyboards Are Great</h1>
          <section>
            <p>Fancy keyboards are wonderful. Here's why:</p>
            <h1>Ergonomics</h1>
            <p>Not contorting your body into a pretzel is wonderful.</p>
            <h2>Low-force keys</h2>
            <p>You can get fancy keyboards with Gateron Clears to make typing easier.</p>
            ...
          </section>
        </article>
    

This sort of thing is handy if your blog software (Jekyll, Hugo, etc.)
mechanically pastes the output of a Markdown processor into a space reserved
for blog posts. Particularly if you want to use h1 elements in your Markdown
source and have things turn out right without rewriting header levels.

Like with a lot of document-markup doodads, there's an automated checker for
this sort of thing:
[https://gsnedders.html5.org/outliner/](https://gsnedders.html5.org/outliner/)

------
SCdF
Wait. I'm not a HTML/CSS wiz by anyone's stretch of anyone's imagination, but
isn't H1 the semantically correct thing to use here?

So using his first example, instead of using <h2> just use <h1>, and then
style it differently (if you want) with .promo>h1?

/me braces for thunderous scorn

edit: oh, I see, that breaks accessibility readers. Well that's unfortunate.

------
jt2190
> Unfortunately, no browser implements the outline when it comes to the
> accessibility tree, meaning screen readers still see an <h1> as a level 1
> heading no matter how many sections it's within.

> This sucks. The outline was kinda the whole point.

But is the point still _relevant_? Most of the world has essentially ignored
semantic markup for decades. How is improving the semantics helping anything
if most people don't use it?

(aside: Semantics crusaders remind me of Douglas Adams' character
Slartibartfast in "The Restaurant at the End of the Universe". In the book,
travel through time to change the outcome of historical events has become so
rampant that Slartibartfast joins what is called The Capmain for Real Time in
order to preserve the "original" historical record. Nobody pays any attention
to him of course, and they just keep on changing history as benefits them.)

~~~
wtbob
Sometimes virtue is its own reward.

Its funny that you bring up Slartibartfast's Campaign for Real Time, which was
based on the real life Campaign for Real Ale. Sure, CAMRA didn't put an end to
awful mass-market lagers: but they _were_ able to keep real ale available, and
continue to do so today.

Perhaps those of us who appreciate semantic markup can do the same.

------
aphextron
>Do we need a new heading element in HTML?

No.

------
amelius
This would be a huge improvement. Still it remains somewhat ugly that you can
specify a heading anywhere inside a section (not just at the top).

------
dubin
Something cool you can do with React is create an intelligent `Heading`
component that wires into context to determine where it is at in the tree. It
could then adjust it's actual HTML heading element accordingly. So for
example, when you have a `Heading` inside another `Heading`, they render to
`h2` and `h1` respectively.

------
jpttsn
I like to use <h1> in exactly this (proposed <h>) fashion, and just pretend
<h2> etc. don't exist. Always have been curious if there are non-obvious
drawbacks.

~~~
jaffathecake
This is covered in the article - it isn't represented in the accessibility
tree.

------
return0
... that thing about the answer to titles ending in question marks.

~~~
jaffathecake
What's the general issue with this? I've heard it before in relation to
[https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines](https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines),
but that doesn't seem to apply here.

~~~
return0
Just my opinion, but why do we need an <h> element since we already have 6 of
them?

~~~
jaffathecake
Check out the article, it essentially claims we might not.

~~~
7Z7
Isn't that the point? Betteridge's Law worked again.

~~~
jaffathecake
Hah, kinda. I think in Betteridge's Law the author intends to suggest the
answer is "yes", but uses a question to avoid making a claim, so the real
answer is usually "no".

In this case, it's the author's (me) intention to leave the reader thinking
the answer is "maybe" or "probably not".

------
tyingq
Surprised it wouldn't come with a new attribute, like level, in case you don't
trust the browser to autocalc... <h level=1>

~~~
jaffathecake
This kinda already exists [https://www.w3.org/TR/wai-
aria/states_and_properties#aria-le...](https://www.w3.org/TR/wai-
aria/states_and_properties#aria-level)

~~~
tyingq
That's mentioned in the github thread. Would it be, though, the first time
changing an aria-whatever attribute would have a visual effect on the page
(without specific css)?

~~~
jaffathecake
Huh, good point. I can't find any pseudo-class that's affected by aria.

------
boredpudding
There is <header> already. What would be the difference between <h> and
<header> ?

~~~
weego
header is metadata about the page and other related resources.

This is dealing with the semantic issue of, for example, web components not
knowing enough about the context they are in to be able to declare the correct
heading tag (h1, h2, h3... etc) as a static tag

~~~
walterstucco
Nope.

It's already been solved by HTML spec.

Having an H tag it's the same of having the header tag. It doesn't solve any
of the problems.

see [http://imgur.com/a/FnLVb](http://imgur.com/a/FnLVb)

~~~
Jaruzel
Doing it like that means:

a) All headers are H1, and styled the same, unless you then start classing up
the section and h1 tags accordingly = more complex css than need be.

b) not-so-clever page crawlers won't be able to extract the real H1 header
that should title the page content.

~~~
walterstucco
I was just showing how the DEAFAULT browser's CSS take care of nesting and
different importance of H1 tags depending on the context. H1 is already the H
you're looking for.

------
oever
In OpenDocument Format it's <text:h text:outline-level="1"> etc.

------
phragg
Correct me if I'm wrong but that's what <header> is for.

You can use this tag in articles, figcaptions, et al

------
Raphmedia
Simply use <strong> or <em> to let the browser know that your heading is
important.

~~~
Ajedi32
I'm not sure if this is supposed to be a joke, or...?

~~~
Raphmedia
Not a joke at all.

It should look like:

<header>

    
    
        <h1>My page title</h1>
    
        <strong>My page is the best page on this website.</strong>
    

<header>

If your heading is a paragraph you should use a <p> instead.

That's what we have been doing for ages. I don't see the need for a new tag.
HTML5 already add semantic tags. Before, it would have been the same as this
snipped I posted but without the <header> tag. Now that this tag exists there
is no confusion at all. Web crawlers should be smart enough to know that the
<strong> that that is in a header right next to a title is a heading.

Hell, even <hgroup> has been deprecated because we don't need those tags.

~~~
Ajedi32
But what does that have to do with the original article? The problem it's
discussing is the lack of a context-dependent outline algorithm for h1-6
elements in modern browsers.

~~~
Raphmedia
It already does that. If you do :

<body>

<h1>My website</h1>

<section>

    
    
        <h1>My section</h1>
    

</section

</body>

The second <h1> will act as a <h2>.

Edit: I think I'm missing the point here. Ignore those posts.

------
Kinnard
No, we need to be able to create our own custom elements as needed and share
them in an ecosystem of components.

~~~
chopin
I think that's what Javascript is for...

~~~
gkya
I thought that's what XSLT was for (All I know about XSLT is that it's a
fearsome thing, so maybe I'm wrong).

------
sparkling
Been writing HTML for 10+ years and never encountered <h>, really makes you
question your understanding haha

~~~
Ajedi32
That's because it's effectively never existed, as it was never implemented in
any popular browsers.

