jjshell — 2011-04-23T06:23:40-04:00 — #1
I've seen a lot of websites using the <h1> tag to display their logo / name. Is it a good practice?
If not, could <h1> tags be used for posts title (in the case of a blog), which means that it could be used more than once?
stickycarrots — 2011-04-23T18:04:13-04:00 — #2
I always just do one h1 and it's always the title of the page. You can see what I'm talking about at my site /snip. This is good for SEO and will help generate some quality targeted traffic to your site's content
picnictutorials — 2011-04-23T08:59:23-04:00 — #3
Each do it dif. But I think that each page should have a unique h1. If you wrap it around your logo then each h1 is the same. Bad seo. Basically, each h1 should match your title.
ralphm — 2011-04-23T09:31:17-04:00 — #4
Yeah, probably better to wrap your logo in something like a <p> element or even just a div. As Erik says, the H1 should be reserved as the title that best describes the content of the page, which should be unique.
stevie_d — 2011-04-23T09:37:04-04:00 — #5
I wouldn't necessarily say that an <h1> should match the <title> ... sometimes that will work, but not always. The <title> has to make sense out of context, eg in SERPs or bookmark list, whereas the <h1> will only ever be seen in the context of the page ... so doesn't need to convey the same breadth of information.
FWIW, I do use <h1> for my site branding, and it doesn't seem to have hurt my SERP ranking. I recognise that it isn't ideal, and if a stable and widely deployable HTML5 comes to pass in my lifetime, I'll be using the <header> construction for site branding rather than <h1>. But for the moment, it seems wrong for the first, biggest, boldest title <i>not</i> to even be marked up as a heading.
picnictutorials — 2011-04-23T13:27:57-04:00 — #6
Ok the same general idea as your title then. Although my titles are short and to the point like my h1s so they have always matched. But I would imagine there are times when they would not.
system — 2011-04-23T13:40:44-04:00 — #7
You have to look at the reason we have multiple level headings BEFORE you answer that question.
By defintion, lower order (higher numbered) headings are SUPPOSED to be the start of a subsection of the higher order (lower numbered) heading preceeding it.
H2 is the start of a subsection of the section started by an h1, h3 is the start of a subsection of the section started by an h2, etc, etc. They should 'fan out' like a tree and it's why as a rule of thumb you should only have a single h1 on a page.
Given the layout of 99.99% of pages, it then makes no sense to have the h1 be anything other than the heading for the ENTIRE page... which typically is the site name/logo.
Think of it like a newspaper -- what's on EVERY page as a heading? The name of the paper. Sure it's bigger on the front page but it's there on every page -- presentation being unrelated to structure.
Take the headline on the main page of the newspaper -- it may be being presented as the largest heading on the page, but does that make it the heading under which all other articles on that page are subsections? They're ALL H2 even if one of them is presented larger than the other. Again, presentation has nothing to do with semantics or logical structure.
Ask youself, are Grades K-9 get new building, Officer arrested in barroom brawl or Weather subsections of MAYOR CAUGHT TAKING MILLION DOLLAR BRIBE!
You hope not... (though with politics today). They're all structurally H2, regardless of their presentation!
Which is why for me on most pages, it only makes sense for the h1 to be the site title/logo; especially since I often have headings in sidebars unrelated to the main article. Everything else on the page being a subsection of it... multiple subsections that aren't related, they all get H2.
picnictutorials — 2011-04-23T14:02:56-04:00 — #8
Reading around the web you'll find a good 50/50 mix of thoughts on this. Half saying what I did half saying what deathshadow did. There is a argument for each but I gave this a considerable amount of thought just recently when redesigning my site and I think wraping the logo in the h1 is a waste of an h1 and would instead have a greater impact as the pages reason for being. All said, either probably has the same impact, or lack there of, on seo. So as long as your only using one h1 per you really can't go wrong.
faridhadi — 2011-05-11T04:11:13-04:00 — #9
ralphm — 2011-05-11T06:19:00-04:00 — #10
It would be more attractive option if rotten WebKit would display the alt text when images are disabled. :mad:
faridhadi — 2011-05-12T09:35:00-04:00 — #11
Now what fun would our lives as developers be if everything worked the way it was supposed to? Pulling your own hair out every now and then is fun, ain't it?
Jokes aside, that's a good point you bring up. I guess Matt's talking about it the context of SEO.
system — 2011-05-12T14:16:29-04:00 — #12
You'll notice Matt mentions a monstrous negative text-indent as bad -- So I'd assume he's talking about broken methods of handling it; You'll notice that it isn't even TALKING about using a h1, just "should I use IMG or CSS"
But that's not the whole picture as you have to ask HOW are you using CSS; and CSS without the markup it's applied to is meaningless. Just saying "IMG or CSS" doesn't even come close to the whole picture, and begs for more questions not answers.
Personally, I'd never put a IMG tag inside a H1, structurally to me the element IS a H1... so that means text + gilder-levin or some similar technique.
Which at least allows you to style the text that actually appears on screen when images are off... and gives you REAL text to behave as a structural heading, since an image is not text; it can be a presentational affectation applied to text, but it is NO substitute for actual content.
Thought the bit about webkit is fun -- but then the specification doesn't actually say browsers HAVE to use alt text in the manner we've become accustomed to in the mosaic legacy world (trident/gecko). The HTML specification makes people who write technical specifications shudder since it's filled with hordes of "may", "might", "can", "often", and not a whole lot of "should" or JHVH forbid "must".
... and when the specification is needlessly vague, the browsers makers do what they do best and all go their own direction to blazes with what anyone else is doing. Just look at form elements for proof enough of that.
stomme_poes — 2011-05-12T15:59:22-04:00 — #13
Thought the bit about webkit is fun -- but then the specification doesn't actually say browsers HAVE to use alt text in the manner we've become accustomed to in the mosaic legacy world (trident/gecko).
If the browser can't bother to show the alternate text when the image cannot or is not displayed, then why the hell should I bother to type it in the first place. Sometimes everyone else does things a certain way because it's so obviously the right way. Showing alternate text? Good lord, who'da thunk??
Browser fail is browser fail. There ain't no sign that says I HAVE to look both ways before crossing the street, but frankly, if I don't, I deserve to get hit by a bus, so my Stupid genome doesn't accidentally spread through the population.
(yes, genome: stupid ain't just one gene)
system — 2011-05-13T00:28:46-04:00 — #14
Notice that in those cases it's usually where webkit goes off and does it's own thing... it really is the worst of the browsers for it; I mean at least IE has the excuse of being the first browser to even TRY to do CSS2 and now having to backwards support the billions of pages that use it's draft interpretation... Webkit has no such excuses but insists on doing things "their way" no matter how anyone else is interpreting the spec.
See form elements, alt text, width of caption relating to a table with padding, bizzare interpretations of percentage width, invalidating @import because @charset preceeds it, (in the spec both say they should be first), default paddings around elements, and the dozen other things all the browser makers have gone their own directions with.
All because the specification is too vague and allows too much freedom of interpretation... Why a tech buddy of mine says "that's not a specification, it's a loose guide. where's the actual spec?" since again: "might","may", and "could" are NOT how you write a specification. Then we wonder why the W3C is toothless.
stomme_poes — 2011-05-13T01:08:50-04:00 — #15
Then we wonder why the W3C is toothless.
Also Design By Committee.
Wh00ps I went off topic.
For I while I really was trying to use the logo/sitename (and the logo often ISN'T and image, just some stylised site/company name) as the h1 on the main page, since the meaning of the h1 and that text matched (the page is about the comapany, name of company counts as page title). On other pages, logo got relegated to a p or whatever and the h1 switched places to where appropriate.
However when doing this latter bit, if there's a header earlier in the document (say there's a header block with navigation and whatsits that come before the "main content"... site chrome) then you get issues with, if that navigation menu header is an h2, you have an h2 before the h1. And switching positions makes no sense: let's say you did move the navigation and its header under the h1, on the About page, that "Main navigation" h2 (so yeah I'm talking about when people add accessibility headers above menus, but this could be anything) still doesn't count as being "under" about Us. It's "under" Joe's Company. Yet the page is about About Us and that should be its h1.
This gets worse if the site is created with a floated sidebar that comes before the main content in source order (say, just to have unfloated main section able to site side-by-side with sidebar). There may be a heap of headers in that sidebar, and they'd all be coming before the h1 in source.
if browsers understood the new document outline designed in HTML5 (and they don't), then this could be solved: the About Us could have its h1 wherever in the document it is, as About Us is the whole point of the page and that content is the reason the page exists... but the sidebar (esp if it doesn't change from page to page) becomes an <aside> (which is vaguely-related content that can stand on its own) and site chrome can be separated from Main content.
Sometimes it's way too much dancing around to have site chrome (headers, sidebars, footers, site-wide navigation lists, and social BS icons) always somehow come after the Main Content while look however you need it to look.
In any case I stopped with the h1 position switching, not because that might confuse people (tho maybe it did), but because the back-end templating system always got it wrong, and I'm a front-ender so I have little control over back-end screwups.
glasspoole — 2011-05-17T03:57:55-04:00 — #16
I allways make the sitename h1 and it was working good with google. There was a research somewhere that was clear that google looks more at the h2 headings. Its like said above like a newspaper.
The company name as h1 makes also sense if you want google maps to associate your website with your company.