Every title can be <h1> in HTML5. Well, sort of.

I'm trying to look into this. When I read the Jeremy Keith book (pg 73 & 76) he talks about the outline algorithm, but when it comes to styling I think he's saying there are practical issues with scoping multiple h1's. Of course you can target the site's first h1 with an ID or a class so I'm not sure it matters.

I'll think about it, I guess, but I think I'm inclined to use a pervasive H1. Should we be using H1's to start every node, I wonder?

I've been watching the videos in this course: http://courses.sitepoint.com/html5-live

In John Allsopp's examples, the site name is marked up with an h1, inside an hgroup which excludes it from the outline algorithm. He also does the slogan in an h2.

http://www.youtube.com/watch?v=TJDcpVUiLYM (starts at 0:50, outline stuff at ~2:00)

He also shows marking up a blog teaser and article... http://www.youtube.com/watch?v=u5ypCJCLAbc

It really depends on how much we care about older systems interpreting our DOM. As far as I know, the only two things we'll really confuse will be search engines and screen readers.
If we're going the HTML5-or-bust route, we should definitely use H1s everywhere.

I do want this to be a usable theme, so I'm not super inclined to break SEO or screen readers for this. AFAIK using a new H1 in SECTIONs and ARTICLEs is a suggestion, and I'm starting to think this might something that should wait until there's a little more browser implementation.

Yeah, I think accessibility and search engines are important. I wouldn't want to break them either, so I don't think we can or should use h1's everywhere right now. We could use h1 for node titles (for full nodes, not teasers) & site name, but we would need to use hgroup to hide the site name from the outline.

@bganicky I would hope to use this theme as soon as it is done.
I'm all for embracing new specs, but writing off SEO and accessibility for the ability to have multiple H1s isn't a fair trade off.

The majority of the changes in HTML5 provide an avenue of graceful degradation, but not in this specific case.

What's the point of working on this now if no one is going to use it anytime soon? I would use it, as long as it works and stays inline with the current recommendations.

We're using a lot of new markup, and working closely with the html5_tools module development to support things like new form element types. It would be faster to just start swapping out tags based on the spec, but I don't want to ignore the practical issues that arise. Let's implement stuff where there's some benefit to it and not just "because". I have no problem waiting on this technique until the benefits outweigh the problems.

Is there a gain for multiple H1s? I'd say we should not do this unless there's a compelling reason, e.g., it's the only way the page will validate in HTML5.

I'm changing the title of this discussion, 'cause it seems to be about all the titles (node titles, etc) not just the site name.

My understanding is that yes — in HTML5, you can have lots of [h1]s. That the best practice might be to make everything that's a title of any kind an [h1], and use [h2]s for true subtitles (not titles in a secondary area). This will mean that the site title would be H1, the page title: H1, the node titles for a listing of nodes on a view page of nodes: H1…

BUT

This doesn't really work now. It will work in HTML5 because of sectioning and outlining. Browsers will understand that one H1 is at the top of an aside, while another is nested four levels deep inside an article inside a section inside an article, and it will know which H1 is most important or more prominent than another.

Browsers will. But they don't now. Safari doesn't do this yet. Opera doesn't do this yet. Best I can tell, only FF4 beta implements sectioning / outlining now, and not well. Plus, most importantly, none of the screenreaders understand this new idea about H1 yet. Doing this now, making everything an [h1], is a total effing disaster for accessibility.

I agree with tim.plunkett in #9:

I'm all for embracing new specs, but writing off SEO and accessibility for the ability to have multiple H1s isn't a fair trade off.

To me, it's too much early to use all H1s. It's not required. Not needed for validation. HTML5 is all about being practical, and not breaking things. Even when it means dissatisfactory levels of code/spec/geek purity.

Let's not do this now. Let's markup things as h1, h2, h3 like before. Let's make a few tweaks.... but not switch everything to an H1.

--
http://itpastorn.blogspot.com/2010/07/no-browser-supports-html5-yet-part...
https://developer.mozilla.org/en/Sections_and_Outlines_of_an_HTML5_document
http://html5doctor.com/the-section-element/

Yeah, also I realized that it will be a lot easier to find and replace all the h2 and h3s to make them into h1s, then it is to take a bunch of h1s and figure out what should be an h2 and what should be an h3. So if we assume no matter which choice we make, there will be some people who want to change it... it's easier for the all-h1 crowd to be the ones to have to change it themselves.