Pick A Heading
Published 20 years, 5 months pastThomas Jogin recently posted an interesting entry that asks about HTML headings. He starts out this way:
For some time now, something has been bothering me about the common way of marking up a document structure. First of all, it doesn’t seem like there is a consensus on wether or not to use multiple H1 tags, or any at all.
I agree: there isn’t a consensus on that point. There is also a lack of consensus on his second question:
Secondly, since H1-H6 are supposed to denote the structure of a document, do they really have a place in the side column as section headlines?
In fact, there’s very little consensus on heading use in general, except that you should use them instead of font size="+3" and that sort of thing. Headings make for more visibility in Google than does presentational markup, after all.
In considering Thomas’ question, Andy Budd goes to the specification, which is always a good place to start. As he points out, HTML 4.01, section 7.5.5 states:
A heading element briefly describes the topic of the section it introduces. Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.
There are six levels of headings in HTML with H1 as the most important and H6 as the least. Visual browsers usually render more important headings in larger fonts than less important ones.
So as far as a semantic definition of the heading elements goes, all we have is that heading levels indicate degrees of importance. Nothing about what order they have to be in, or whether you can skip levels, or anything else besides the creation of a spectrum of importance, as it were. Because that’s all we have, there is plenty of room for people to fill in their own interpretation of what’s best. I approach headings as merely indicating a level of importance, and don’t bind myself to a decreasing numeric order. That’s my take on it; others feel differently. Let’s take a look at two cases where my approach led to very different results.
The first case is Netscape DevEdge. Here’s the markup skeleton for the first part of the home page as I set it up (the actual markup as of your reading this may be different):
<h1> <a href="/" target="_top"><span>Netscape</span> DevEdge</a> </h1> <form action="/search/app/" id="srch" method="get"> <h4><label for="search-input">Search</label></h4> (...inputs...) </form> <h2>Netscape 7.1 is now available</h2> (...paragraph text...) <h2>The DevEdge RSS-News Ticker Toolbar</h2> (...paragraph text...) <h3>Recent News</h3> (...list of links...)
Here, the order is h1-h4-h2-h2-h3. I guarantee you that some readers are feeling a deep outrage right now, because we got more than one piece of feedback berating us for putting the headings ‘out of order’. The h4 was clearly out of place, we were told, and needed to be fixed.
The placement of the search markup in the document was dictated by our preferred document linearization, however. In an unstyled view (a really old browser, say, or a cellphone text browser) we wanted the masthead to be immediately followed by the search feature, and that to be followed by the main content. The main content was in turn followed by the sidebars, which was followed by the navigation and configuration links, and finally the footer. So we weren’t about to move the search markup just to make its heading level fit into a descending-number hierarchy.
We could have elevated the heading to an h2, but that struck me as being a poor choice. Is the “Search” title really as important than the top headlines on the site? I certainly didn’t think so. My only other option was to change the h4 to some non-heading element and style it that same as I had the h4 That’s certainly easy to do, since with CSS you can make any non-replaced element look like any other element, but that would mean the search area had no heading at all. That also struck me as a poor choice.
So I took the route I did. I suppose I could have, as Richard Rutter suggests, put in some extra headings to increase the structure and then “switched off” their display with CSS. That would mean inserting an extra h2 and h3 between the masthead and the search. What would they say? Personally, I’m not thrilled with that idea either, at least for the DevEdge case.
The second case I’d like to consider is meyerweb.com itself. Here’s the basic structure of the home page, at least as of this writing:
<div id="sitemast"> <h1><a href="/"><span>meyerweb</span>.com</a></h1> </div> <div id="thoughts"> <h3 id="thtitle"><span>Thoughts From Eric</span></h3> <div class="entry"> <h4 class="title"><a href="..." title="...">entry title</a></h4> <h5 class="meta"><b>entry date</b></h5> </div> <div class="entry"> <h4 class="title"><a href="..." title="...">entry title</a></h4> <h5 class="meta"><b>entry date</b></h5> </div> </div>
Here, I skipped the h2, but other than that everything’s in a descending-order hierarchy. In this case, such an approach was a fairly natural fit to the information being presented. I don’t have an h2 on the home page because it’s reserved for page titles, such as the “Eric A. Meyer” at the top of my personal page. The page title of the home page would be “Home Page” or “Main Page” or something equally silly, so I left it off. (And yes, there are b elements in my markup, and I’m doing that on purpose. I’ll talk about it some other time.)
Meanwhile, in the sidebar, the section headings (such as “Distractions”) are enclosed in h4 elements. That makes them as important as entry headings, and I’m okay with that. I might have chosen h5 instead, but probably not h3. The one exception is “Blog Watch”, which is an h5 element. I don’t have any rigorous logical explanation for this; it’s all based on gut feelings.
In the end, I don’t think there will ever be a heading consensus. XHTML 2.0 attempts to bridge the gap by adding the generic h (heading) element, which helps create a descending-order hierarchy when combined with nested section elements. What bothers me is that the Working Group hasn’t decided whether or not h1 through h6 should be deprecated; to do so would in effect attempt to force a consensus in favor of a descending-order hierarchy. That would mean that headings were no longer as much about importance as they were about having a document that’s structured like a specification, or maybe an e-book.
In the here and now, though, we’re left to ponder these questions and arrive at our own conclusions. Each answer will depend on the temperament of the ponderer, and the project upon which the pondering is predicated.
Comments (65)
Pingback ::
at the 404 ! » Great minds think alike
[…] like Filed under: General — Root @ 4:36 pm WordPress blogger and CSS guru Eric Meyer has just published an article on the proper semantic method of employ […]
Pingback ::
at the 404 ! » Eric Meyer for Gemini
[…] t through the menu. At smaller text sizes it gets worse I have *cough* pointed it out on Eric’s blog. I am not expecting any thanks. […]
Pingback ::
MIME types matter; DOCTYPEs don't <Anne's Weblog about Markup & Style>
[…] arted with XHTML is invalid HTML and followed up with some weblog comments and other posts some people just couldn’t agree with. I don’t think there is anythin […]
Very good, indeed. I like this balanced post. Sometimes too much of linearization can lead to tunnel vision…
I’ve commented in nearly every blog about this topic, and even written my own entry.
My feeling is that H tags work pretty well for conveying the level of importance of a heading, but they stumble on the task of creating a hierarchy. The numbering issue is ridiculous with dynamic content, it’s like line numbers in BASIC but worse. The level should be implicit from the nesting, which is why section tags are really the way to go. I know we’re talking 10 years out, but I really don’t see the need to create all this extra markup and classes to hide headings. For me it boils down to practical benefits. Use visual headings tend to coincide with what I want to optimize for the search engine and I end up with a simpler stylesheet to boot. Sure, we can create nice outlines for our fellow geek, or the occasional screen reader, but to me those niceties just don’t add up to the loss of search engine optimization and the default styles non-css browsers.
Now, let the flames begin.
I think that that’s the most important sentence from this entire entry. It completely justifies you (people in general) to break away from a descending-order hierarchy, and thus makes for a great argument against the need for descending-order hierarchy.
I personally think that a descending-order hierarchy is not a bad thing at all, but lacking elements such as
sectionfor the time being, they impose too many restrictions and get in the way of sensible document linearization.There are people on all sides of the octangular-shaped fence here, which makes it abundantly clear that there is a severe lack of usable guidelines for us to follow on the topic of headings. Which in turn means that of all the various suggestions people have made for guidelines, none have been sufficiently acceptable by a large enough group of people. Is this issue, then, really that complex? Oh, the mind is boggling…
My main two comments would be:
a) I agree with pretty much all of your comments Eric.
b) I think that like the old adage I’m about to make up “the truth is always best and will out”, I feel that while we must for good reason follow the various beams of light:
#<font>=naughty, css=good
#h1 – h6 good for SEO and screen readers (and EVen humans :)
#keep h1 before h6(!) etc,
I do still however feel that we must take a short pause to look at the hair and the wood. Hair and wood? When we stand back we can see that the one is a horse and the other a cart and hence see the order of precedence, but I’m not talking about h1’s gotta go before h2 type-order (tho’ h1 is a pretty ‘special’ for SEO folks, tho’ I digress) or that you mustn’t skip h-levels; in my painfully weak analogy I see the horse as the content and the cart as the lovely css and other nice tools to allow us to display the content.
If I were using a quill and parchment to publish a paper page, then I would emphasise my content based on what the content was and that would mean that I would invariably use the boldest heading first and then other headings interspersed through the content as the content demanded (as you did with your search box [I think]).
So I guess this is a whaffly way to say that to me, h3 can follow h1 w/o an h2 coming before it, if the content suggests this (I know we can re-define hN to make the page look right and still keep strict order, but I think this approach is invariably ‘wrong’). No, to me, though an h1 or h2 will invariably go first, thereafter other h’s can be used and mixed and missed, as the content dictates. I know I am contradicting myself slightly by saying that I would always have h1 or h2 1st [why Alan, don’t you slave-ishly follow what the document suggests..?], but I just can’t think of a page where you’d want h3 first then h1 – I think if I did find a bunch of content that demanded this, I would still follow my main rule and hence I would apply h3 first then h1 after etc.
Ok, now I’m worrying that there’s a .org somewhere committed to defending the order and inclusivity of h1-h6 on the web [like that grouping who defended the burial ground in “The Mummy”] and I’m gonna get flamed for my comments =:-|
I always liked the idea of an outline-like structure with h1-h6. I’ve never come across a situation where it didn’t work, though I don’t know what I would do about the Netscape situation above.
Perhaps XHTML 2.0 should have something to the effect of
<h level="1">, allowing developers to choose between a descending structure and a more organic structure. I don’t know.Trackback ::
box of chocolates
Headings, Hierarchy and Document Structure
Summary: More thoughts on the current debate surrounding headings, hierarchy and document structure.
In forms you should use FIELDSET and LEGEND. That they are hard to style is a problem from the W3C that still isn’t solved. But using a H4 is clearly incorrect, no matter what.
My feeling is that the headings are initially meant for structure. It’s the same way a book or magazine layout and from the headings you should be able to derive the index. From that point I think that things like navigation, search and all that stuff should not go in the index and therefore should not go in headings. It’s more like a sidebar thingy and therefore will probably be contained in divs. Ok, but what about sidebar headings — yes you caught me on that one? Hhhmmm, maybe it’s allowed then after all to have out-of-place headings like h4… Looking at my own site I’ve just found out that my side bar doesn’t use headings at all and completely handled by divs. It may be visually quite important but not for the document structure. That’s why most sites choose to hide the sidebar-navigation for printing.
There isn’t anything wrong with using an H4 in this context – it is perfectly valid HTML and enhances universal accessibility. This form is very simple, and doesn’t necessarily require a FIELDSET and LEGEND — what is critical, however, is that the form field has a proper label. Marking up that label as a heading is a bonus. Why do you say it is “incorrect”?
Generally, I’m in the camp that doesn’t like to put headings out of order. I don’t like to put a lower level heading out of order just because the content seems less important, because in most cases, I find that the section either doesn’t quite fit there anyway, or doesn’t require its own heading. For the search, personally, I would have left it without a heading. The label provides enough semantics, and doesn’t require a heading.
And, seriously, what’s with the <b> element on the h5? <sarcasm>Have you not heard that CSS applies to h5 as well?</sarcasm> Also, I noticed in your stylesheet (new-thoughts.css) you’ve got this style rule:
#thoughts h5 b {font-weight: normal; ... }That kind of defeats the purpose doesn’t it? Why don’t you just use a span instead, or just apply style directly to h5?
It’s all about hierarchy.
I’m not at-all sure this came across on the other thread, but I’m not so against using headings out-of-order, as long as, when drawn as a tree, different logical sections of the document are on different branches e.g.:
h1 Content Title
– h2 Section
– h2 Section
– – h4 Blogmarks
is bad, whereas:
h1 Content Title
– h2 Section
– h2 Section
h1 Navigation
– h4 Blogmarks
Is much better because, although not a perfect heirachy, the document structure will be parsed correctly by any assistive technology.
I’m also opposed to people splitting up a single heading into two different headings with say:
h2 – title
h3 – date
There’s no way to parse the html without regarding the h3 as a subsection of the h2, which isn’t what’s intended. Instead, I suggest using a single heading and a span or div in order to seperate out the date from the actual title.
Because Anne is of a particularly purist school of thought, where unless you’re doing everything to the strict letter of the law, you’re not allowed to play, I’m afraid.
Some more of his thoughts (see comments).
I hope I’m not being inflammatory. I just want to point out that AvK has a certain view of the world which informs his rather pointed comments on various blogs around the sphere. It’s all or nothing: essentially “if you’re not sending XHTML as application/xml+xhtml, then don’t bother.”
That is exactly the reason I asked the question of Anne about why he sees it as incorrect — because according to the “law”, there is absolutely nothing incorrect about putting that label inside an h4. It validates, it is practical and useful, and it “briefly describes the topic of the section it introduces”. I don’t see the problem, even for a purist ;) And if there is a legitimate reason Anne believes it is incorrect, then that is fine with me. I just want to hear his reasoning, that’s all…
Exactly the problem we are struggling with at the moment. As I said in my post on the subject, that we’re having this discussion at all is due to the origins of HTML. It was originally conceived as a way of marking up scientific documents with a conventional heading, sub-heading, sub-sub-heading structure. Nowadays we are trying to apply the same methodology to more mature, hypertextually complex Web pages which, visually and functionally are somewhat different to academic papers. Forcing Web sites into a hierarchical document structure is akin to a square peg/round hole scenario; they are just not going to fit.
Eric said:
Not completely true. There’s a web standard who explicitly assign to headers the funcion of conveying document semantic structure, and not textual elements importance:
HTML Techniques for Web Content Accessibility Guidelines 1.0
Consequently, “content developers should not “skip” levels (e.g., H1 directly to H3)”.
Personally, i do not agree with this rule, ‘cos often i face the need of use some “optional” level of label inside the document structure, i.e. a label for grouping blocks of news: so, if in a page is needed the grouping label, the news title should be H4, if not necessary instead in another page it should be H3?? The CMS should in this case calculate the header level of that chunk of “templated” code before render the page, according to the presence or less of intermediate level of labels? That sounds absurd to me.
But, so far as the rule exists, the web standard devoted coder is required to apply it, even if personally considered not effective.
So, welcome to the generic H tag in XHTML 2, that would solve the problem! But, as somebody suggests, there should also be an additional method to mark a level of importance of an element in the page.
Andrea – I hear what you are saying. However – define “skip”. Do they mean that an h3 shouldn’t be used immediately following an h1 because of the linear structure? or do they mean that we shouldn’t have an h1 and an h3 in a document without also having an h2? Eric’s example would only be seen to be “skipping” levels if we literally interpret the document structure in a linear, tree like fashion. If we look at it the other way, his sample provides h1, h2, h3 and h4. Maybe he hasn’t skipped anything?
I still think that while the search functionality in his example is part of the rendered web page, one could easily make the case that it isn’t part of the main “document”, so it should be “removed from the flow”. That is what lead me to this statement in my post:
It seems like everyone is trying to force things into a nice tree even where it doesn’t necessarily make sense to do so for outline purposes.
Forgive my cluelessness (I’m relatively an amateur at this stuff), but I was under the impression that the W3C’s HTML validator would report your page as invalid if you used the wrong order of header tags. If that’s not the case, then I would probably argue that it’s not a bad thing to have header tags out of order.
After all, as a perfect example: you can have multiple UL/LI tags out of order, as in jump/tab in two indents rather than just one. Of course, the list markup is different because it uses enclosing tags, but I don’t think that the principle is all that different. Does anyone know of any screen readers or summary generators that would actually choke on out-of-order headings, anyway?
I said I’d talk about that some other time.
In that case, shouldn’t we all be using definition terms?
Derek Featherstone said:
Obviously the first interpretation, authorized by the clear use of the word “directly” in the W3C recommendation. The word would otherwise have no sense in this context. In similar cases, i’m used to say “italian is NOT an opinion!”. Is it in english? ;-)
The rule is clear, and is a web standard.
Well said. I definitively agree, under a theoretical point of view. This means that a form label should NOT be marked with a linear structuring tag as an numbered header, because such markup is dedicated just to content structure, not to the entire web page.
But this issue should involve a higher level of discussion, at least covering topics as the “paratextual” nature of navigational and search objects in a web GUI: if content is a separated flow having some specific features, and the rest of the elements are out-of-the-flow objects, we cannot use the same markup for the two. It would than be worthwhile to promote as a future standard a few tags
sorry, some tag cut by the last line of my previous message. It was:
It would than be worthwhile to promote as a future standard a few tags NAV, SS (Site Search), HOME?
Trackback ::
no2.org.uk
Nesting headings
Eric Meyer has a post up today about headings and whether or not they should be nested in order.
Only old, useless information seems to stick in my head and I recall I used to use ISO HTML before XHTML.
I started using it as I thought it was a s…
Andrea:
Its only “obvious” because that is the way that everyone is interpreting it, and because that is the way that these outline generators currently work.
I guess what I am saying is it isn’t the only way to view things. Certainly as we move forward into XHTML 2 with nested sections, there is much more room for smarter user agents/scripts/programs to create a document structure not by nesting level alone, but also because of explicitly declared structures.
On MeyerWeb example, why this div:
<div id=”sitemast”>
<h1><a href=”/”><span>meyerweb</span>.com</a></h1>
</div>
<div id=”thoughts”>
<h3 id=”thtitle”><span>Thoughts From Eric</span></h3>
<div class=”entry”>
ecc ecc
For presentation only or for clearly structuring markup? or?
Livio
argh. this div … i try …
<div id="sitemast">
<h1><a href="/"><span>meyerweb</span>.com</a></h1>
</div>
<div id="thoughts">
<h3 id="thtitle"><span>Thoughts From Eric</span></h3>
<div class="entry">
<h4 class="title"><a href="…” title="…">entry title</a></h4>
<h5 class="meta"><b>entry date</b></h5>
</div>
<div class="entry">
Valid doesn’t mean it is correct, but I think you are aware of that, right? My point was that you don’t have to use document header inside a form. A form has it’s own kind of headers, called LEGEND. And since you have to use a block level element within FORM anyway (strict dtd requires that), why not use FIELDSET? Using H4 just isn’t appropriate, since it isn’t a document header.
Note that I distinguish the document, which is the content of the website and the rest of the website, which may be a sidebar, form et cetera. See also: about the hierarchy thing.
Correct. Until someone can convince me of the contrary of course. But I doubt it.
I’ve always been of the opinion that headings should be used to create a proper outline structure on a page, that is, no skipped or out-of-order layers.
This is easy to do with blogs, where the pages tend to break down into a clear hierarchy. But there are plenty of other types of pages out there where the hierarchy is unclear, the ordering of major sections is arbitrary and mostly determined by what looks good, etc. I’d go so far as to say the content on these pages, even reduced to some sort of Platonic ideal, simply doesn’t fit tidily into an outline form. So what to do? Go back to tag soup? No. Force everything, Procrustes-like, into an outline, with multiple hidden levels and whacky positioning tricks? I’d be hard-pressed to do this. I’d probably go with a “what works” approach.
If you aren’t open to the possibility of being fallible, nobody could ever convince you of course. :)
So what most of the comments seem to say is, “modern” documents don’t have hierarchal heading structures like “academic” documents do, but we modern document authors will use the same H1,…,H6 elements as academics use because it’s SEO. If it weren’t for SEO you’d be using DIV elements, right?
And how does it help SEO? Not really I think. Using DIV elements is more semantic I would say, or using other kind of heading elements like LEGEND, CAPTION. Nested lists are sometimes used for the sidebar to give some kind of outline for that.
Using
Hxonly for the “real” content, like the post or the most important information on the page, would make the most sense to me.Anne — I think we agree on a lot of this stuff, despite the fact that I still think it is quite reasonable to use the <h4> tag to provide prominence to the form’s label in Eric’s example. It isn’t incorrect to do so (perhaps less than perfect, yes), but given our current user agents and the markup available to us, I still think it is a workable solution. Would I mark it up that way? I don’t think so. My issue on this has always been your labelling of the technique as incorrect, not whether or not I believed it was the correct way to mark up that code sample.
Like you, I believe that the document proper is distinct from the site wrapped around it. I state as much directly in my post as well. The problem is that we can’t separate the two right now – they are inextricably linked based on current technologies.
I also believe that these document outline creators (whether W3C or otherwise) are too simplistic in nature. Creating a full document outline simply from the linear flow of the entire rendered page is not productive or representative of the document proper. All it is leading to is people adding extra markup to force the entire rendered page into a linear tree structure. If these tools created a full outline from the linear content found within <div id=”content”> or the appropriate <section> in XHTML 2 for example, and supplemented it with the other components of the final rendered “page” it would be much more sensible and logical.
Well, Derek, if you can suggest a specific algorithm for producing a document outline that is likely to produce better results for the majority of pages than extracting the headings as-marked into the tree structure suggested by their relative importance or position, then I’ll certianly try and implement it in my Firefox outliner extension. However, you seem to be suggesting some sort of hack based on an implied semantic for the ‘div’ element, which I can’t imagine working at-all well.
Yes, we need a <navigation> element with some urgency. Hopefully the WHAT working group’s Web Apps 1 specification will include this. However, I dispute that most documents on the web lack a clear structure. If anyone can show me an example of a document that requires headings but does not have a structure that can be represented as an outline, I would be very interested.
I think it’s worth noting that the current XHTML 2 draft now explicitly mentions at the end of section 8.5 that it is bad practice to put numbered headings out of order. Though, I still think it’s strange that numbered headings are still in XHTML 2, and the note about whether or not they should be deprecated is now gone.
Eric said
So Eric and a lot of other bloggers seem to takes a site-wide viewpoint on structure while others think heading level markup is about the document. From the document viewpoint, the second-level heading can’t be “reserved” for anything but it makes perfect sense at the site level to do so. Eric is using a rigorous downward hierarchy that never omits levels, one that he calls “importance” in his penultimate paragraph. This is only opposed to structure, as he claims, if one applies hierarchy in one context (site) and then analyses it at another (document). It seems to me that the document context fits the apparent intent of the XHTML spec and the apparent future direction of the web better; we’ll have to wait for Google to start ranking purely semantic, descendent hierarchies higher than gappy, presentational markup heading hierarchies. Then the sounds of panicked scampering and hierarchy-applying would be heard throughout the land.
Lachlan Hunt said:
I think it’s very interesting to point out that the W3C is calling it bad practice, but they are very obviously not going as far as to make it invalid markup. I think they realize just as much as some people here that it’s necessary under certain circumstances. Especially as how, just a few lines above that quote, they state that the h# elements are ordered by importance.
The simple fact is that most web pages don’t necessarily follow a precise linear structure because presentational elements may be moved around, thanks to positioning or float styles. My own web page is a perfect example of that. (Right now I’m just using p tags for the individual sections in the sidebar, but I plan to change that soon to use h4 tags instead.)
The only alternative that I can think of, really, is to still include the h2 and h3 elements, but to cause them to disappear with CSS. But now that I think about it, that might actually be a good idea, simply because it would help visitors who are not using the style sheets realize that the sidebar is a section all its own.
On my site, h1 is for the page title, h2 is section titles, and h3 is subsection titles. I could actually make the sidebar into an extra section without stretching the definition of header too much. And it would be useful for non-visual browsers, I’m guessing.
Okay, so I may be able to re-arrange the sidebar on my site to make use of properly-ordered header tags. But I still think that it’s okay to have them used out of order in certain circumstances.
jgraham, there aren’t any better alternatives. It’s just that you shouldn’t rely on them. They can show you some things, nothing more. Until we get elements like SIDEBAR, NAVIGATION et cetera with nested header elements that are not equal to Hx there is no way to create a good outline.
derek, you are right. It isn’t incorrect, it’s just not the best solution.
lachlan, we need Hx. SECTION and H don’t solve everything. See how easy is XHTML2? and the comments. Especially the comments I think.
Anne: I know it won’t work all the time, but when documents are written with a nice outline, displaying that outline is a huge usability win (at least, I find it very helpful). A lot of the time the problem is that people are using headings in a ‘semantic’ way where the semantics are ambiguous and difficult to extract.
Regarding “how easy is XHTML2?”
* I wish I’d seen that in October.
* Have you seen http://jogin.com/weblog/archives/2004/07/19/hierarchy#2489 ?
* I’m not sure I understand Jacques’ example. Is ‘Subheader’ supposed to be like a sub-title (as in >h1<Lord Of The Rings</h1>>h2<Return of the King</h2> or is it supposed to be a real subheading with content following it? If it’s the first, they should be part of the same heading (or, at the very least, the same section with 2 ‘h’ elements). A deemphasis element (like a better-named &l;small>) would help distinguish the two.I’m not sure what the relationship between ‘title’ and ‘content header’ is supposed to be. Is one the site title and another the content title? Why is the structure in comment 13 so bad (except for the fact that it’s verbose)? It has a different ‘logical structure’ but how do we know the first structure was better?
jgraham said:
A few quick responses — I know your outline extension doesn’t support XHTML2 – I guess I was thinking more along the lines of a mental exercise… The algorithm I was suggesting was something along the lines of this:
Create a default outline based on source order and nesting of <section> elements, with specific sections removed from that linear flow if they provided another attribute that indicated it was to be seen at a certain level instead of the default place in the linear tree.
That was the crux of my post, and the comments I made over at Thomas Jogin’s site where I asked you about that specific example.
Of course, a lot of this really good discussion happened before the release of the new working draft of XHTML 2.0 on July 22, 2004, so I had presumed that the only way to signify different heading levels was to nest them within sections. Now it appears that heading levels are back in, so I’ll have to reconsider my thinking.
Having said that, would it be conceivable at all to produce an outline from <section> elements and <hn> that used the heading level to construct the outline instead of the linear flow/stucture of the document? That is really what I’m getting at…
The point of headers, in ancient times was to organize data in a logical matter.. now, how you organized it was up to you. I mean, if I wanted to, I could place my most important thing in a h6 element, and my least in a h1, and I doubt any validator would challenge the design issue..
Trackback ::
digibliss dot com
The Header Debate
I was reading about the debate over the use of the headers in valid HTML. The arguement is that there are 6 levels of headers, h1, h2, h3, h4, h4, and finally h6. These are supposed to be used to…
As others have said: it’s all about the hierarchy. I use heading tags to help describe the hierarchical relationships of sections on a page.
Whether to use more than one
h1on a page depends on the importance of each heading. For example, on my homepage, I use<h1>for the title of each post. To me, each title is equally important.Personally, I’m not a big fan of skipping headers (i.e. using an h1 then an h3 with no h2). Each header is in relation to other headers on the page. Theoretically, leaving one out ruins that relationship. But in practice (say, as with dynamic, templated pages), I can see why you would skip a header.
I think introducing markup like <sidebar>, <navigation>, etc. would not fully address the issue of how to handle a web page that consists of multiple subdocuments, each potentially with a separate hierarchy. For example, imagine a web page with one or more sections whose content is streamed from another server. Ads would be an obvious example, but you could have RSS feeds, stock tickers, animation, news stories, or sports scores, to name a few. A general approach for representing subdocuments would be desirable.
OK, so we’re all agreed that headings are used to structure the content of a page. H1 is nearly always used for the page title, H2 is nearly always used for section titles or paragraph Headings. The others are then dished out to other places that become less important to the content, e.g. Navigation, Breadcrumbs, dates etc. This theory is fine, H1 tags are usually rendered in a large font, H2 might be slightly smaller, H3 is smaller again, and H6 is the smallest.
It suddenly came to me that, what if all H* tags were rendered the same? Each H tag doesn’t represent importance, more it tells you were it should exist in the document. An H3 tag will be before the H4 tag and after the H2 tag. This does of cause mean that only one of each tag can be used per document. here’s my idea
...
First Chapter
...
Second Chapter
...
Third Chapter
...
Here i have based the document on a standard story book. All H2 tag are rendered the same. Using this structure, the second chapter is easily found by knowing it has a H2 tag at the start of it. It might not make sense for designers, but in terms of programaitcally extracting the data, it makes more sense! to me anyway? And No, before you all point it out, yes this does limit you to only 6 chapters. Maybe some one from the w3c is reading, Can we please have H* (* being any number, even H4567 !)
I’ve never seen Headings marked up like this before, or even if its standards complient? but it does open a whole new can of fish for accesible structured markup
OK, something went wronng there, here’s the HTML for post above
<html>
<head>
<title>Document Title</title>
</head>
<body>
<h1>Chapter One</h1>
<p>...</p>
<h2>Chapter Two</h2>
<p>...</p>
<h3>Chapter Three</h3>
<p>...</p>
<h4>Chapter Four</h4>
<p>...</p>
</body>
</html>
Hope this works!
Lachlan, good job of sleuthing the style sheet.
Eric’s rationale for this markup has me wondering, too. Perhaps we should get a betting pool together and reward the pot to the person who can guess correctly ;)
on my site, after much re arranging I decide to separate the content from the menus and make my layout as generic as possible. h1=content h1=menu then go down from there. I doubt anybody else does this but I think it makes alot of sense since most web site are half menu.
I also have another question : what should I call the home link? index/main/what. I noticed that in french or whatever language it gets translated to “domestico” or something like that, so I’ve changed it to main.
I am an advocate for deprecating h1-h6. This would solve the crisis we are currently facing with coming to terms with the role of heading tags, document structure and the very nature of HTML itself.
The confusion over whether or not to skip heading levels perhaps is rooted in our misunderstanding of the basic aims of HTML which I feel should be to only show hierarchy rather than to try to make HTML also show “importance”.
Here are some further thoughts with a diagram:
http://www.ryznardesign.com/web_coding/elements/2004/headings/headings.html
The W3C’s HTML Techniques for WCAG 2.0 (Working Draft 30 July 2004) states in its section on headings:
Interesting (and long discussion). My apologies for any repetition of what has gone before.
My feelings are that accessible markup should take priority over the (x)html markup of your choice.
My weapon of choice when performing accessibility checks is the http://bobby.watchfire.com service.
To achieve a grade 2 (out of 3) level of accessibility headings need to be sequential (h1 is followed by h2, and not h3), which agrees with the W3C.
The reasons for this seem to be different, however. As already mentioned in other comments W3C specifies that headings should be ordered according to importance. Accessibility standards generally state that headings are for defining the flow of a document.
The styling of the headings is irrelevant. It would be valid to assign values of importance to each header:
h1.importance1 { font-size: 2em; } h1.importance2 { font-size: 1.8em; }etc.
This level of complexity is something I am not prepared to even contemplate using, and the assigning of classes to header tags is a step back towards merging design and content.
In this situation possibly W3C is wrong in its definition of headings. Accessible design should come first, and this means that the flow of documents should make sense without additional styling.
I know it has already been said but I will add my voice. I believe that H1 is the document title and therefore <h1>meyerweb.com</h1> is not an appropriate title for the document – what distinguishes this document from any other on your site? Well, I suppose one could argue that each article is a chapter (and therefore deserves a h2 element). My editor strictly states that I cannot have a heading out of place – I can’t jump. It makes a lot of sense to me. You can’t have a <td> without a <table> and <tr> to wrap around it – why would you argue that h1, h4 is logical. Hierarchical use of the headings for the author makes him/her think about the organization of the content and how it relates with other items and how it is different from other items.
Hear, hear to hierarchical, non-skipping headings.
go to extended validator (http://validator.w3.org/detailed.html), check Show Outline and see.
“If this does not look like a real outline, it is likely that the heading tags are not being used properly. ”
Markup is invalid, accessility lost.
ciao
Livio
Pingback ::
Lachy’s Log » Blog Archive » CSS Guru Explains A<b>use
[…] Guru Explains A<b>use A while back,Eric Meyer wrote an article regarding heading levels in which he me […]
Pingback ::
Semantics, do we really need’em? | ara pehlivanian—Web Standards, Web Culture, Web Everything.™
[…] As a strong advocate for web standards and semantics, I’ve been actively pursuing perfection in this area for a while now and have recently begun to feel disillusioned. After covering all the bases (read: <b>ed and <br>eakfast), and performing all the fancy tricks, it seems I’ve run headlong into the outer edges of what HTML and CSS are capable of doing. Oh sure, I still try and make the technology do more than it’s deemed able. But it’s in this territory that the “rules” get vague. For example, how well do you think HTML is able to add meaning to your content? Don’t give me simple examples of using paragraphs and headings, or emphasis and strong tags. I mean really, what’s the better choice to mark up a breadcrumb navigation menu? A nested unordered list? A comma delimited paragraph with spans around each element for styling purposes? And what of the delimiter? What denotes “a child of”? Then there’s the infamous heading debate. Which interpretation of the vague spec is best? […]
Surely if you want the search box at the top of your page under the h1 then it is arguably important enough to be h2?
Alternatively if you really wanted the search to be h4 it could be put at the end of the document in the correct nesting level and then moved up to the top with css? This would be the most semantically correct way to go in my opinion.
Pingback ::
Headings and Hierarchy: is More Than One H1 a Crowd? | MT-Soft Website Development
[…] Pick A Heading Incoming Links (via Tecnorati):Nothing Reported […]
Pingback ::
Headings and Hierarchy: is More Than One H1 a Crowd? | Digiladee
[…] Pick A Heading […]
Livio, tone it down a bit. Just because a page doesn’t validate doesn’t mean it is completely lost.
I am totally uncomfortable with skipping header tags (i.e. h1, h3, h4, . . .), but I think Eric’s reasoning is sound.
These issues are often mitigated by good pre-planning. Therein lies most confusion. Amateur designers dive into their work without thinking through the entire project. Then, when their headers, paragraphs, titles, etc. don’t play nicely together, they struggle to fix a design that wasn’t right to begin with!
All of the point below to be considered if you care about accessible headings:
1- First of all, it doesn”t seem like there is a consensus on wether or not to use multiple H1 tags, or any at all.
Pages should only have one main heading, H1, which is the main title of the page and should be positioned at the start of unique page content.
2- In the example you mentioned, you set an H before the form field.
Search
(…inputs…)
Upon the accessible headings:
Headings should not be coded around form labels i.e. the text label “Search” that comes before an input field.
3- Here, the order is h1-h4-h2-h2-h3.
Heading levels can”t be skipped i.e. you can”t jump from H1 to H3.
Reference: http://www.rnib.org.uk/wacblog/headings/quick-tips-for-accessible-headings/
Pingback ::
Header Tags.. Oi!! » Free Xenon Consulting
[…] Eric Meyer: Pick a Heading […]
I am struggling with headings in a site I am building right now. On deeper pages, where 99% of the content will live my H tags are structured logically, no skipping at all. However, I find myself struggling with what to do on the homepage.
You see, the function of the H2 and H3 tags doesn’t exist on the home page (category and page title, respectively). So if I choose to stay structured with my headings, then I have to restyle H2 and H3 to look appropriate on the home page. However, I could skip straight to H4, which is the visual style I need, but things will then be out of order.
The former is semantically correct. The latter would seem to be easier to maintain.
Although the topic is quite dated now, generally the consensus is to only use between H1 and H3. Rightly or wrongly, on my website I have the homepage H1 as the site name, with H2 for the post and then H1 for the title post name on the post name. Would any of you disagree with my usage? If so I would be interested to know why? Thanks, Rich.