An interesting question to answer on Sunday and perhaps the days after. May a webpage use H1 multiple times within the same page? Some (or most) people think a document is about one subject and that therefore the H1 should cover that. Other people think TITLE is more appropriate for that (see also my nice test case for that; this does not imply I like my test case, it is a test case after all).
Of course one can use multiple H1's, I also think your weblog does it perfectly right.
Btw, "contacteer"? Use something like "contact opnemen"...
Nicely done Anne. Btw, "contacteer" is correct. It's a Belgian word.
Okay, but I think it sounds like "gedragingen" (as in "de gedragingen van de AI"). It is correct, but still... ah well, what does it matter. :)
I think you cannot always use a title element for a image-header or a logo. They are just not the same.
The title element should be appropriate, but it has some cons:
The element is part of the head element.
<!ELEMENT head (%head.misc;,
((title, %head.misc;, (base, %head.misc;)?) |
(base, %head.misc;, (title, %head.misc;))))>It's not clear if the title element may be used on the viewport or not.
<!-- The title element is not considered part of the flow of text.
It should be displayed, for example as the page header or
window title. Exactly one title is required per document.
-->
<!ELEMENT title (#PCDATA)>
<!ATTLIST title
%i18n;
id ID #IMPLIED
>You cannot use some handy attributes.
<!ELEMENT title (#PCDATA)> <!ATTLIST title %i18n; id ID #IMPLIED >
<!ENTITY % i18n "lang %LanguageCode; #IMPLIED xml:lang %LanguageCode; #IMPLIED dir (ltr|rtl) #IMPLIED" >
The codes are from the XHTML 1.0 Strict DTD and I'm sorry for my bad English.
Some (or most) people think a document is about one subject and that therefore the H1 should cover that.
I think the first H1 should be the same text as the <title> element. Howewer you do it, keep it consistent. There is no standard that says something about how many section you must have in a document.
A heading element briefly describes the topic of the section it introduces
From the specs: 7.5.5 Headings: The H1, H2, H3, H4, H5, H6 elements
There isn't a single specifications which can define semantics or does, thus this is more an issue of interpretation and thought.
Tonico, read Tags versus elements, since you are currently not using it consistent and correctly ;-).
Jerome, maybe you should have read the test case
part a bit better. I was just showing what was possible, not what is desired. That part was also enclosed in brackets and not really relevant for the topic, although some interpreted it that way.
More important are your personal opinions about the subject and the reason. Why do you think it is incorrect or appropriate?
Personally I'm against it. I think that a document should only cover a single topic and that H1 should be the same as the TITLE in a general way (this is not the fact on this weblog by the way; here I combine both H1 and H2 in the TITLE element).
Anne, thanks for the english lesson, and yes it's all personal opinion.
I'm not for or against using multiple <h1> elements, as said before, I think it is more important to keep it consistent. You should ask who benefits from one or multiple <h1> elements, then prove your theory with real persons. Everything else is just hot air, IMO.
It really depends all on your usecase and overall markup (concepts). IMO using it for the page title (not document title) and the document title and the two combined like <title>Page title: Document title</title> is the nicest solution.
note: i was talking bullsh*t :)
one level 1 heading for the page and a level 2 heading for the document is what i'd do.
the document is part of the page and above the page there should be a skip link to several parts of the website (for accessibility).
and my reason (which i forgot tell you) for two level 1 headings was accessibility (switching between heading levels and reading just the headings) so this is already solved by the skip link anyway.
regards, michael
I was alway wondering on that too, but use it the, way, that there's only one h1 in every document, which contains the main-lable of the document, as headings are used as labels. And since the title element is only part of the header and not in the body, I personally would compose it of the name of the site, and the content of the h1 element
By the way, Anne, is the masking of emails with unicode-entities an efficent way to protect onesself from spam?
Going offtopic here; ben, it perfectly works on our company site. I placed my Google e-mail account on the frontpage of this web one time and I didn't get a single spam message in it, but maybe that is because gmail is new?
Maybe I was a little offtopic. I just wanted to project the cons of the title element.
I will keep my opinions for myself at the moment, because I've the feeling that they will change soon. :p
On Watchzine I used entities and it seemed successful as I did not receive spam messages...
But anyway, are you in the opinion that you should use H2 for subsections which are entirely different then?
Didn't ISO HTML specifically limit it to a single h1? Not that that standard is wide spread, but just worth mentioning.
I could see using multiple H1's in a few, rare circumstances.
For example, say you have a web based presentation. To save a little bit of bandwidth, or just to be cool, you put every section on a single (html) page. You then hide sections based on what step you're at. Thus each section might have a separate H1 element as the sections title.
Of course, you could say "Well why isn't there a "presentation title here" H1 at the top? Well there could be - then logically the sections would all be H2's.
Except this:
H1 is technically just a heading - with a technical definition of where it can be placed. The semantic of it however, is implied importance. A H1 is more important than a H2.
Thus if those sections I was talking about are signifigantly important, I would probably still use H1's on them.
(As a side note, not a single one of my sites has ever used multiple H1's.)
I use the heading elements as if they form an outline of the content. Since most outlines have multiple root sections, then multiple h1 elements should be allowed. I usually precede the main content, subliminal content, navigation, and copyright info with separate h1 elements describing those sections. That way older browsers and disabled people have a context to understand those parts without lengthy and repetitive introductions.
The "Show an outline of this document" option from the W3C's HTML Validator inspired this style of markup.
P.S. You should remind commenters if they haven't posted all the required info after a preview. I originally didn't post my email with this message and then got into an annoying infinite loop between my browser (Firefox) and your CGI script. :-/
I'm a 'one h1 per page' kinda guy. It holds the overall topic, with sections broken down in h2's then h3's and h4's as needed. I posted some ideas about semantics and headings in an html document on my blog a while back, though now that I re-read it it may need some clarification...
On my personal site, I use two h1 elements per page, but their collective contents match the title of the respective page.
ACJ'son it -- this is an
h1. The logo is followed by a list of chapters, and then a second h1 element that is the title of the chapter -- in this case Portfolio.The contents of these two
h1 elements match the contents of the title element, which is ACJ's Portfolio.
So yeah, I agree that (in most cases) the contents of h1 and title should describe the same thing, which is the title of page. However, even with such usage, there doesn't necessarily have to be one h1.
If one sets a rule stating 'only use one H1' then one is using mark-up to dictate writing style. This is wrong, wrong, wrong. Writing should dictate mark-up not the other way around.
However, if one sets a rule stating 'good writing should contain only one primary heading' then one can mark up the page according to writing style.
As a sidenote, I don't think I ever used multiple H1's either. But is there any rule which forces us to split documents into multiple pages? No. ;)
As far as I know the h1 element is allowed to appear more than once in a ISO-HTML document, though the levels must not be skipped and if you use a h2 it should be preceded by a h1 element.
The W3C Validator however is more lax with 15445:2000, so is probably inaccurate. The encoding of e-mail works well and I've been spam free for above two years.
Generally I'd use just one h1 element but it depends upon the page content and structure.
Think of this semantically: A heading introduces a new section of content. If you page has 2 H1's that means your document has 2 (semantically speaking) starting points. That can't be right can it?
When you introduce the second H1, are you saying "Ignore the first H1, this one is the real staring point" or are you saying "These two sections are equally important" ?
If they are 'equally important', and we can't have two starting points to the document, then they have to be H2's under a H1 that describes the content of the total document.
@ Richard
The problem with having one <h1> is that the <h1> must always be the site name, because you will probably end up with a wrong document structure, if you have more then two sections.
<h1> Site Name <h2> Actual object (e.g an article) <h2> Navigation <h2> Related <h2> Other sections ... The following structure looks wrong to me, scince the different sections does not belong to the acutal object:
<h1> Actual object (e.g an article) <h2> Navigation <h2> Related <h2> Other sections ... Because I don't see the sitename/logo as a heading, this is my favorite:
<h1> Actual object (e.g an article) <h1> Navigation <h1> Related <h1> Other sections ... Again, I think the question is, who benefits from having only one or multiple <h1> elements?
YMMW.
FYI: Semantic data extractor, and from the WCAG HTML techniques: 1.2.1 Section headings.
In my opinion only one h1 element should be used on a page. Also, I don't believe it should be used for the site's name. I believe it must be used for the heading of the actual document whenever possible. It would probably be nice if we could have a separate element for the site's title in a future specification, because I believe this is a common problem amoungst web designers.
Now I must point you to this: Use <h1> for top-level heading
I realize that the above is not a specification, but it does make some sense (to me). This is only what the W3C says, and as we all know they don't allways even follow their own guidelines & specifications. But still...
Also, on that page if you go and look at the source code you will see that inside their actual h1 element on the page the
text is not inside a <h1>code element or something. Like I said, they don't allways practice semantic markup themselves. But we all know that by now anyway.
Oh yes, and sorry for my poor English, I am Afrikaans. But then it seems like most of the people who post here aren't English. :-)
P.S.: Anne, why is the span element not allowed in comments? I needed it to markup the language with xml:lang there.
Sorry, I left something out in my previous comment. This is in reply to Tonico:
What you say makes some sense, but I don't completely agree. The navigation could be seen as part of the document, since it typically links to other documents related to the current one. It is basically like link elements in the head. This is of course IMHO.
For this to make complete sense, we still have to wait for XHTML 2.0 to come out. I'm talking about the nl element here. That would probably fix things, because technically (again IMHO) I guess then you could put the nl elements above the h1 element in the actual source code and everything inside of the nl could be seen as seperate from the document. It would still be nicer to leave the navigation out of the document.
@tonico
This is all a matter of opinion, but I think you have things one level off.
The site name should not be the h1, unless that is the topic of the page.
In 'your favorite' that you outline above, change those h1's for h2's and put the main topic of the site in an h1 and have a look:
<h1>Tonico's Widgets</h1> <h2>Navigation</h2> <p>Lorum ipsum hereis my navigation</p> <h2>Content</h2> <p>Lorum ipsum hereis my contentum</p> <h2>Othe Stuff</h2> <p>Lorum ipsum hereis some propoganda</p>
What I am getting at, and I said this in that blog post I linked to above, is that a web page is an html document. Therefore, the main topic of that document should be held in an h1, while sub-components of that document should be held in lesser heading tags.
So in my workup, the navigation here is a subsection of the document about 'Tonico's Widgets'. I think that is a fair assessment.
Good point Charl, I'm missing the distinction between the user interface and the actual document or object.
Everytime I read the term document
in a spec I'm not sure if this also includes UI elements?
For me, a site navigation is clearly an UI element, not part of the actual HTML representation of a document or an object (e.g. a file, link, news item, picture, etc.).
Consider your document stored in some special XML format an then transformed to HTML, would you include the navigation in your native XML format? I wouldn't.
We need an UI language!
Maybe I'm just too brainwashed from object oriented thinking ;-)
I didn't read every comment (bad weblog author, bad!) but I did read comment 27 and I can tell you that HTML is ineed only meant for documents like you talk about them.
HTML is nice to use for documents, but not so nice for building user interfaces. But it's not meant for that anyway. That's where CSS and XSL comes in.
I have come to believe that CSS alone is definitely not enough. Thank goodness for XSL!
I did some experiments with XSLT a while ago. My XML files only contained the actual documents and the navigation was only added in later by the XSLT stylesheet. This would maybe be a very nice client-side alternative to server-side includes once every browser supports XSLT or even XSL 1.1 (propperly).
My only question is: Is this really more adequate and semantic? Is the navigation not maybe part of the document? I feel that it is not, but I don't know. Some other people might say it is. Like Anne said, markup is all about personal opinions.
But then I can't help thinking: aren't we going a little overboard with this semantic markup thing? Does this in particular really matter that much? Should we (as designers) not rather focus more on our users than on the perfect markup
? Just a thought...
A lot of the things the W3C recommends are not 100% semantic either. But I can't back that up right now.
For me the semantic web
is anyway more about functionality, accessibility, and usability, rather than having the perfect markup
. The only way navigation will really be accessible (from my viewpoint) is when we get the nl element in XHTML 2.0
And sorry for not providing my abbreviations with title tags, but it is getting too much for me now. :-)
In my opinion, a H1 tag should only be used once on a page. "Sub-titles" can be H2's or H3's and so on.
Er folks...surely heading level (and any other structural element) depends on context? This is markup; it comes afterwards! Forbidding multiple <h1> tags is too prescriptive by half (why not forbid multiple <h2>s? <h3>s?). I'm with comment 23 on this.
The markup describes the page, whatever the content. It seems pretty clear -- and the spec agrees -- that a page can have only one <title>. That might be "My opinions on <h1> use" for one type of page or "My blogposts from 2004" for another. The headings describe the arrangement of the content, which might be your thoughts on only one issue (first example, definitely only one <h1>) or your collected thoughts on many issues. In this second case, you'll have lots of sections with headings of equal weight as "My opinions" and I'd argue that (certain layout choices notwithstanding) those could all be <h1>s. It's a heading. If it was a title, it would be called 'title'.
So a document or a page will have only one title (surely that's not controversial?). It gets murky here because the paradigm for the client software that most of us use doesn't make this title as prominient as <h1> thanks to the window/viewport design and the default stylesheet. Using a single <h1> (maybe even with the same content as <title>) is a purely practical consideration mired in the quirks of getting information via a windowy browser. (Using <title> to give your domain name is a similar workaround for an OS- or browser-mandated display issue.) If the <title> tag was more prominent, would anybody be seriously proposing that <h1> should replace or duplicate it? Would anybody be asking whether or not we can put more than one heading of a particular level in a document (note the word: not title, heading)?
If anyone sees any speck of use in semantic markup, they should happily arrange the pages on their site that require hierarchical structure under as many headings as they like; if the page discusses two topics of equal weight under a given title, there would be two <h1>s.
Anyone who wants to make their subject, meaning the <title> of the post/article/page, the most eye-catching thing on the UI can compromise their semanticity (real word?) and use <h1> for that purpose; they'll use multiple <h2>s instead. These people may also have pages easier to code and maybe easier to read using extant browsers. Maybe one day Google will declare that they index single-<h1> pages higher and all those who care will follow that--good for them but, as a hobbyist rather than a layout artist, I reserve the right to cry "Lousy semantics" and sprinkle the <h1>s where I feel they belong.
The different status of <h1> also arises from writing and marking up at the same time. If you markup as <hugeheading> and <lesserheading> and so on (under a 'title' of course) and then go back over to use the smallest numbers and make sure you don't miss any heading levels you'll (a) find yourself using <h1> more than once and (b) never get anything done. But you will have rigorously applied the principle of semantic markup, and that might give you a warm feeling.
It's just one more example of the browsers compromising our lofty ideals. Cf. box models, partial CSS support, float errors, etc. Reality bites, sucks, and chews all at once.