Google Chrome doesn't follow hash (#) pointers in the URL?

In browser-testing a new website design I came across the following off behavior from Google Chrome. I understand that to navigate directly to a specific element on a page on uses a hash sign after the URL with the id of the element to be found after, like this: http://website.com/page.php#element.

Now this is not on-page navigation, this is page-to-age navigation but with the new page loading scrolled down to the element in question so that it’s at the top of the browser window.

Firefox does what I expect perfectly (load the new page with the element named in the hash aligned with the top of the browser), IE does it perfectly, Opera does it perfectly… but Chrome does not… it seems to try to scroll the page down but doesn’t quite get there, and gives an impression that it just stops randomly, somewhere between the top of the page and the element.

Is this wrong of Chrome? Or am I abusing something that isn’t meant to be used this way? Another thing I’m thinking is that Chrome just cares that the hash element is visible in the window and not necessarily at the top (a pretty bad decision IMHO, if that is so).

Maybe you are doing something wrong.

This anchor is within the viewable area from the main page:
http://en.wikipedia.org/wiki/Mirek_Topolánek#Biography
And Chrome scrolls down to put it at the top.

This anchor is outside the viewable area:
http://en.wikipedia.org/wiki/Mirek_Topolánek#Involvement_in_the_Anti-Missile_Defence_System
and it behaves the same.

Is there ‘enough’ content following the target link? A browser won’t scroll so far that the bottom of the document isn’t at the bottom of the window.

A.C., yes there is enough content below the id… it was only on doing a routine cross-browser comparison of the website that I noticed it, since all the other browsers did scroll down correctly, while Chrome did not.

However, looking at that wikipedia page that was linked, I noticed they went to the trouble of making an empty <a> tag just to establish the id there… as opposed to putting the id directly in the <h1> tag, which is what I’m doing, therefore that’s probably what I’m doing wrong.

So would I be correct in concluding that id’s for the purposes of page navigation are only valid in <a> tags then? And that every browser except for Chrome leniently allows you to put them in other tags (I use them in h1, h2, and form tags on my page)?

Still though, I already know my page will be used exclusively on Firefox and IE so it’s not really a problem, I was just curious :slight_smile:

An id for the purpose of navigation can go in ANY tag in modern browsers. Only Netscape 4 and earlier browsers worked with a name in an <a> tag instead. If GoogleChrome isn’t recognising the ids in whatever tag they might be in then the browser has a bug in it.

Surely google will fix this

i had the same problème, i saw the wiki source, and i just add a tag <p> or tag <div> and put in my <a> with my hash name, and it work fine.

Its look like Chrome does recognize your anchor without tag outside.

Why are you using an <a> tag - that is for links out of the page. For anchors into a page you use

<div id=“here”>
<p id=“here”>
<span id=“here”>

or whatever other tag you already have at the right location. Using <a> for anchors died when Netscape 4 did.

Same on my site: underfashion.nl/maattabellen#kids does NOT scroll down to the kids-part of the page.
I tried both <a name=“kids”></a> and <h2 name=“kids”></h2>

Works fine in Chrome 4.0 for me (using <a href="#foo">link</a> and <h3 id="foo">target</h3>).

Question, is this Chrome/Windows or Chrome/Linux? They do not work the same (funny joke, cause the Linux version doesn’t have the “report a bug” feature)?

I use empty anchors as the destination often (not always) because the id’s of non-focussable elements can’t take focus, so if you click a skippy with the keyboard, the browse moves the visual focus but your next TAB or whatever brings you back up to where your cursor was.

However the anchor can’t be empty if I want Opera to work. I’ve also tried <a id=“destination”> </a> (with a whitespace char) and then CSS to make like negative letter spacing or something.

<h2><a id=“dest”> </a>Text of the header</h2>
It’s more work and I don’t like it (kludgy), but anyway that’s one reason some of us may use an anchor.

My test above was done in Chrome/Win at the office. I’ll check in Chrome/Linux when I get home tonight.

My test above was done in Chrome/Win at the office. I’ll check in Chrome/Linux when I get home tonight.

Was just me being lazy, as I has Chrome/Linux and actually I’m sure I have a page somewhere that already had in-page skip links…

*edit worked identically to both id-on-non-focussable-element and id-on-anchor in Chrome/Ubuntu.

I’ve now verified that it works in Chrome 5.0 beta under Linux as well.

You are using the wrong attribute and have an extra invalid character as well.

<h2 name=“kids”></h2>

should be

<h2 id=“kids”></h2>

then it will work in all browsers except Netscape 4.