> 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.
Backwards compatibility is often a reason not to fix things. So, there can be reasons to introduce a new standard. The other option is an element that means, yes I want you to do this the correct way, which IMO is a better solution and arguably already part of HTML.
"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.
The closest thing I can think of is "version 2 syndrome" or what Mythical Man Month described as "second-system effect". But it's not quite that. This cognitive problem tends be a cause of second-system effect.
These really don't get to the meat of the matter for me as these seem to be about giving credit. I think Nirvana Fallacy, mentioned in another comment is the right one.
The strategy I take now when confronted with something like this (in internal codebases, since I don't work on standards) is to refactor the interior implementation to include a new module with a "now and later" view: it does not hinder existing behavior, and it decouples enough of the internals that a rewrite or a new system with similar behavior can reuse the module as-is with a modest amount of integration effort; sometimes a facade module is included to make highly abstracted internals easier to consume in the 80% case. For example, an audio API that has nitty-gritty details about formats and buffers, but also has a "load and play this sound file" easing facade.
Starting at the rewrite tends to obscure the actual dependencies and enable second system effects: factoring out the module gives you an anchor to hang things off of, either in the form of a general-purpose abstraction or an implementation detail surfaced as an API. Subsequently, maintenance will tend towards accepting the module as-is, and the "rewrite" turns into a refactor that uses the same module in a new context.
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!
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.
That might be a problem, but looking for better tools or waiting for them to adopt the standard seems an easier solution than inventing another standard.
I agree that we should just let the computer keep track of heading levels. TFA suggests, convincingly to me, that "<h1>" would serve this purpose as well as "<h>". This wouldn't even run afoul of CSS single-pass concerns the way that lots of reasonable styling requests do. The first time the browser sees "<h1>", the immediate parent is the top level. Any child with an "<h1>" is the next level, any sibling with one is the same level, and so on.
And <h1> keeps shrinking as you nest <section>s. So yes, someone has actually implemented it. (I personally don't like the <article> part, but well -- whatever.)
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?"
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.
Often twice. Once for when a post shows up on example.blog/ and again for example.blog/2017/post/. It's nice to not have to rewrite the headers inside my blog entries depending on where the post shows up. I really like the newfangled outline algorithm for that.
Potentially very often, if you're using Angular 2/React components or Angular 1 directives in various locations on a page.
On the other hand, if that's what you're doing, using heading tags is arguably the wrong thing in any case, since their semantic meaning is not likely to be preserved.
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.
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.
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.
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.
We just had "Every discrete page must have an h1 tag with the page title". Even though that isn't appropriate for this site, and the head meta already has page titles and description. So now we implement customizable h1 tags on each page that are all then hidden using `display:none` (which I think is penalised by Google, not that it matters much). Multiple H1 tags as well, Seo guys did not like that, so we had to fork the off the shelf modules in the CMS to make them non-spec compliant. I love Seo consultants and their fantastic suggestions
You work at Google? IP address isn't used at all in the ranking algorithm? Not even to identify "voting rings" (sites passing link-juice that normally wouldn't, eg a site made only for that purpose)?
Can I ask why not? IP seems like a really useful signal.
Not a Google employee, but I reckon ranking down sites with shared IP addresses would disproportionately impact sites on shared servers regardless of the reason. Plenty of websites out there rely on cheap/free hosting providers that shove everything behind an Apache or nginx instance with a single address. This is especially common/useful now that SNI is mainstream and widely supported.
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.
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.
> 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.)
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.
The app I used to read this article relies on well formed markup like this. There is significant value in using descriptive markup compared to the cost.
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.
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.
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".
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)?
Because you can manipulate attributes without destroying and recreating elements. Changing <h level=1> to <h level=2> is a much simpler and different thing to changing <h1> to <h2>.
An alternative approach to 100% trusting the browser to calculate the level. You can calculate and adjust as needed.
Can you explain in what ways it is simpler to change 1 to 2 in the first case? Is it that you are mutating them via script and it seems more "normal" to mutate a property of a tag instead of the tagname?
Or is it because it might have a named closing tag and you have to update both?
You can't change a tag name with a script. You have to destroy it and create a new one, being sure to copy attributes and the inner html, then, inserting the new one in the right spot. That's not only more work at a script level, I assume it's much more disruptive at a browser internals perspective regarding reflow, etc.
Using an attribute would also allow you to programmatically get the nested level from the dom if the browser had "levelled" the <h> tags on it's own. Lacking that, I don't think you could tell what the browser ended up doing.
Edit: It basically comes down to whether you're okay with the browser auto calculating the level of <h>, and then not having any programmatic access to what it decided. If you don't care, then <h> without an attribute works fine.
> A heading is a line of text providing a title for a section.
Which is exactly what <header> is trying to be.
> …introductory content for its nearest ancestor sectioning content or sectioning root element. A header typically contains a group of introductory or navigational aids.
> When the nearest ancestor sectioning content or sectioning root element is the body element, then it applies to the whole page.
> > A heading is a line of text providing a title for a section.
> Which is exactly what <header> is trying to be.
Not at all:
> > A header typically contains a group of introductory or navigational aids.
Key word here is group. A header is a block containing other elements. A heading is a line of text. Often the header contains a heading, but header element itself is not a heading.
A realistic example might be something like:
<header>
<h1>New York Times</h1>
<time>Monday, February 20, 2017</time>
</header>
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
The H tag would replace the H1 tags in all your SECTIONs. You're not using H2-6 in there at all, so what do we need the "1" on the end of H1 tags for? That seemed to be the crux of this article, we don't need numbered headings like that anymore because we have semantic block-level elements like SECTION, HEADER, etc. These elements can be used by the browser to deduce a structured outline from the page, and it's also easier to use said elements when you can think of them as portable components (without resorting to setting CSS classes on everything).
The truth is, H1-H6 were useful to screen readers when the web was a lot less complicated. With the component-driven philosophy of today's web development, it's harder to maintain that structure and stay within the confines of 6 possible headings, especially for single-page designs (the ones that scroll, not "single-page apps" made entirely with JS).
> The H tag would replace the H1 tags in all your SECTIONs. You're not using H2-6 in there at all, so what do we need the "1" on the end of H1 tags for?
the N after the H can be seen as the priority
where 1 is the highest and 6 the lowest
> we don't need numbered headings like that anymore because we have semantic block-level elements like SECTION, HEADER
how do you express
HEADING > SUBHEADING > SUB SUBHEADING?
using classes? nesting tags?
> The truth is, H1-H6 were useful to screen readers when the web was a lot less complicated.
So in your opinion since the web is more complex now, we should drop perfectly reasonable tags?
> it's harder to maintain that structure and stay within the confines of 6 possible headings
I can't remember the last time this has been a problem.
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.
The <h> proposal is different to the <header> proposal. <header> isn't involved in outline production. The <h> proposal is more like <h1> + sectioning.
<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.
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.
If a new element is proposed I think it should be trialed as a custom element. And of course, once something is decided, we should have a polyfill to set the correct heading level (via aria-level) for older browsers.
> 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.