Do we need a new heading element in HTML?
jakearchibald.com
jakearchibald.com
> 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.
This feels like a fallacy worthy of a name. Does it have one?
If no name yet let's call it _Archibald's Rule_. I met Jake at a conf and he is a solid yet approachable guy (and funny too).
[1] https://en.wikipedia.org/wiki/Matthew_effect#Sociology_of_sc...
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.
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!
/* user agent stylesheet */
:-webkit-any(article,aside,nav,section) h1 {
font-size: 1.5em;
-webkit-margin-before: 0.83em;
-webkit-margin-after: 0.83em;
}
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.)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)
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... http://html5doctor.com/computer-says-no-to-html5-document-ou...
What makes you think they will implement the new one correctly ?
Plus they are wrong in the first place.
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=...
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.
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.
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.
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.
Can I ask why not? IP seems like a really useful signal.
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. <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/
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.
> 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.
No.
In this case, it's the author's (me) intention to leave the reader thinking the answer is "maybe" or "probably not".
An alternative approach to 100% trusting the browser to calculate the level. You can calculate and adjust as needed.
Or is it because it might have a named closing tag and you have to update both?
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.
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.
Source: http://html5doctor.com/the-header-element/ (quoted from the actual spec)
> 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>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
I think you're confusing the head and header elements.
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.
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.
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 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.
You can use this tag in articles, figcaptions, et al
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.
<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.