homepage Welcome to WebmasterWorld Guest from 54.161.240.10
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / WebmasterWorld / Accessibility and Usability
Forum Library, Charter, Moderators: ergophobe

Accessibility and Usability Forum

    
Fragment Identifiers aka Named Anchors
pageoneresults




msg:3996221
 3:41 pm on Sep 26, 2009 (gmt 0)

Using named anchors to identify sections on your pages
2009-09-25 - [GoogleWebmasterCentral.BlogSpot.com...]

Jump to the information you want right from the search snippets
2009-09-25 - [googleblog.blogspot.com...]

We generate these deep links completely algorithmically, based on page structure, so they could be displayed for any site (and of course money isn't involved in any way, so you can't pay to get these links). There are a few things you can do to increase the chances that they might appear on your pages. First, ensure that long, multi-topic pages on your site are well-structured and broken into distinct logical sections. Second, ensure that each section has an associated anchor with a descriptive name (i.e., not just "Section 2.1"), and that your page includes a "table of contents" which links to the individual anchors.

Anyone remember all those topics I started about Fragment IDs that just went in one ear and out the other? Well, some of you were on board but the general audience just didn't quite grasp the concept of targeting at this level. Here are some historical topics discussing Fragment IDs...

Be Specific, Use Fragment Identifiers
On page targeting for users.
2008-04-25 - [WebmasterWorld.com...]

Fragment Identifiers
Axioms of Web Architecture
2007-03-02 - [WebmasterWorld.com...]

Anchor Naming Conventions
2004-03-08 - [WebmasterWorld.com...]

I could probably dig up a few more that go back to the late 90s but I don't think there is a need to. The message is quite clear. Google have, and will continue to look at document structure and the use of semantic markup to further refine their relevancy algorithms. Named anchors have been part of the HTML Specification at least as far back as HTML 2.0...

Anchor: A
[W3.org...]

NAME - gives the name of the anchor, and makes it available as a head of a hyperlink.

So, what say ye now? Time to go back and start adding all those Fragment IDs? Don't you wish you would have done it way back then? Ya, I'm rubbing it in a little, you know me. ;)

 

johnnie




msg:3997063
 2:07 pm on Sep 28, 2009 (gmt 0)

Giving our users new entry points also means revising ad placement?

eltercerhombre




msg:3997126
 4:13 pm on Sep 28, 2009 (gmt 0)

Johnnie, that's a good point. If this gets widely extended across results, people must have to monitor SERPS and revisit where their ads are placed.

The biggest problem, afaik, is that you can't see in you analytics if they entered directly to a section or not. So, when having multiple anchored sections in a page, how would you know what's the best place to put your ads?

RonPK




msg:3997143
 4:53 pm on Sep 28, 2009 (gmt 0)

Named anchors... Many moons since I last used them. People who've moved beyond HTML 3 use IDs:
<h2 id="redWidgets">Red widgets</h2>
AlexK




msg:3997233
 7:56 pm on Sep 28, 2009 (gmt 0)

RonPK:
People who've moved beyond HTML 3 use IDs:
<h2 id="redWidgets">Red widgets</h2>

Even cleverer people than that use both:

<h2 name="blueWidgets" id="blueWidgets">Blue widgets</h2>

willybfriendly




msg:3997285
 9:02 pm on Sep 28, 2009 (gmt 0)

<h2 name="blueWidgets" id="blueWidgets">Blue widgets</h2>

Code bloat. that is a 5:1 code to content ratio!

Conflicting priorities I suppose. I still like lean and mean...

henry0




msg:3997310
 9:27 pm on Sep 28, 2009 (gmt 0)

Don't forget to include in your page a content table
dedicated to those anchors or G will disregard them and not ref to.

Future




msg:3997330
 9:55 pm on Sep 28, 2009 (gmt 0)

If money is not involved anyway, I am unsure except adding a few listings its gonna be productive ?

nice gauges pageoneresults :D

pageoneresults




msg:3998555
 2:36 pm on Sep 30, 2009 (gmt 0)

Even cleverer people than that use both: <h2 name="blueWidgets" id="blueWidgets">Blue widgets</h2>

No, one or the other. If I were a Search Engineer and detected stuff like that and there were other signals, I'm going to ding you for it.

Did you know that one of the most common HTML/XHTML validation errors has to do with Fragment IDs?

W3C: "An "id" is a unique identifier. Each time this attribute is used in a document it must have a different value. If you are using this attribute as a hook for style sheets it may be more appropriate to use classes (which group elements) than id (which are used to identify exactly one element)." [Validator.W3.org...]

I'm currently monitoring 628 websites as of 2009-09-30. There are 1,767 "ID Already Defined" errors amongst those website documents. If I were to look closely at those, which I have, many of them are user generated errors via cut and paste routines. They may have downloaded some sort of plugin and decided that they wanted it here, here and there, 3 instances. And of course since they don't know much about HTML, and don't realize what they just did with that cut and paste routine. :(

If you run your site through the validator and then choose the option to "Group Error Messages by Type", scroll towards the last group of errors and you may find the "ID X Already Defined" group.

W3C Markup Validation Service
[Validator.W3.org...]

ID X already defined
An "id" is a unique identifier. Each time this attribute is used in a document it must have a different value. If you are using this attribute as a hook for style sheets it may be more appropriate to use classes (which group elements) than id (which are used to identify exactly one element).

An example I used in a recent article...

Here's a working example of how multiple IDs can disrupt document functionality...

* Choose Option 1 - This Radio Button 1 has a label and Unique ID associated with it. Click this list item for testing.

Code Example Unique ID 1
<label for="Radio1"><strong>Choose Option 1</strong><br />
<input type="radio" value="Selected" name="Radio" id="Radio1" /> This Radio Button 1 has a label and Unique ID associated with it. Click this list item for testing.</label>

* Choose Option 2
This Radio Button 2 has a label and Unique ID associated with it. Click this list item for testing.

Code Example Unique ID 2
<label for="Radio2"><strong>Choose Option 2</strong><br />
<input type="radio" value="Selected" name="Radio" id="Radio2" /> This Radio Button 2 has a label and Unique ID associated with it. Click this list item for testing.</label>

If the above two Radio Buttons had the same ID assigned to them (id="Radio1") they would not function. In this example, the first Radio Button 1 (id="Radio1") would be permanently selected and the user could not select Radio Button 2 (id="Radio2"). This is just a very basic example of how having IDs that are not unique can break your documents.

I wonder how Google would handle multiple instances of the same Fragment ID in a document? Is it going to use the first or last reference?

Also, protocol states that Fragment IDs are client side functionality and dereferenced by User-Agents. Does this new feature from Google mean that the protocol needs to be revised to reflect the fact that UAs do reference Fragment IDs? Or at least Googlebot does?

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Accessibility and Usability
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved