IE8, a whole new form of anger...

Ok... through some testing I have some more data on this one. It seems that this is a bug with IE8 and how it handles the A tag. Specifically, if it looks like this:

<a id="bookmark" />

It screws up the CSS. But if it looks like this:

<a id="bookmark"></a>

Then it seems to be ok. Since it is valid XHTML, and handled better by screen readers, I would rather use the first. Does anyone know a work around for this?

Thanks in advance

The element shouldn't be self closing and isn't valid xhtml 1.0

Ok, that is news to me. I thought when used as a bookmark (vs a link to some other webpage, where the element was not designed to be empty), that this was valid (since it would be an empty element by design). Indeed, it validates via the W3C code validator as XHTML 1.0 and 1.1. Firefox also doesn't fail when the page is served as application/xhtml+xml and declaired with an XHTML 1.1 doctype.

Checking W3C website, I find this link:
http://www.w3.org/TR/xhtml1/#guidelines

There, section C.2 talks about how minimized syntax should be used for elements with empty content model. However, looking further down at C.3 it says not to use it for an empty instance of an element whos content model is not empty. Since it validated as XHTML, and IE was the only browser I have found that doesn't handel it the way I would expect, I assumed that a bookmark version of the anchor tag was considered empty (since nothing will ever be in it).

I guess I am supprised that it was IE that did something right, and W3C, Firefox, and everyone else that was doing it wrong.

Thanks for pointing out my error. I will adjust the pages, even though screen readers seem to balk at an empty anchor tag.

-dcolpi

In xhtml you should not be using empty anchors for targets. An ID on any element can be used for that. This is a more semantic and robust way to do things, and the old "A tag with a name attribute but otherwise empty", as you are attempting, should not be used for that. I suspect but don't know for sure that it is deprecated.

Really?!!! I did not know that. That makes everything so much easier (and cleaner). I would much prefer just sticking an id onto the list item or whatever that I want to bookmark. I am wondering how this would work for earlier browsers. This is no longer a CSS question though. I will research this.

thanks for the tip!

-dcolpi

It's not deprecated in XHTML1.0 (cause I saw my husband's boss do that I was like, what the hell is ???) but since "name" was being moved to other purposes in XHTML it is deprecated in XHTML1.1 and 2 and was simply allowed (but not encouraged) for XHTML1.0 since that was a "transition" of sorts. Whatever, it was not a good idea.

Anchors are not empty elements even if you make them so (so just like you also can't do

There is one problem with the using of the id of an existing element (otherwise a great idea and one I prefer too): some browsers suck at it. Clicking on an in-page link for instance, like a skip link or a table of contents link, will indeed properly bring the visual focus down the page, but if the user is a keyboarder, the next TAB might start back at where they left the REAL focus-- this happens to me in Safari all the time, while FF continues me further from where the visual focus was.

To get around this I've done this crazy stupid thing that still guarantees that ALL the focus always goes to the new place: hiding anchors with id's. Like this:

skip to Foo

later...
Header text abour Foo

Yes, ugly. But as an anchor is a truly focussable element, all browsers should move the focus there if the skip link is clicked. Because it's empty, people shouldn't be able to click it, but if somehow they accidentally do, they don't end up back at the top of the page, cause I assign the href to its own id (I've seen people do href="" but I don't know how that works cross browser).

Visually, you don't see the anchor at all, nor does it appear in Lynx (I don't remember seeing it but I have coloured Lynx and I might have seen a different colour, but no option to click anything). JAWS might read out the href. It knows there's a link there. So that's another negative, hearing "link" before the header text. Possibly href="" gets around that? I'd have to test.

Thanks, Stomme poes. The empty anchor works in IE8, which the old zoomfix didn't. But it doesn't seem to work in Opera, Chrome or Safari. Does anybody know of a fix which does?

I am unable to replicate your findings. Stomme's example works as expected in Firefox, IE, Opera, and Safari.

cheers,

gary

I must be doing something wrong, but I can't see what.

I have posted a very simple example:

http://www.cheesyweasels.com/foo_anchor/foo_anchor.htm

I've tried it in Opera (9.63 & 9.64) and Safari (3.2.2), on Win2k and XP.

Add enough filler, e.g.

fill

, to force a scroll situation.

cheers,

gary

I've updated the example with filler text. However, on my system the keyboard focus does not move when I follow the link.

In Opera, I press 'a' to highlight "skip to Foo".
I press 'return' to follow the link.
The page scrolls down so "Header text about Foo" is visible.
I press 'a' again.
- The focus is now on "First Content Link", which is *before* the target. It should be on "Second Content Link", i.e. the first link *after* the target.

Is this different to what you see?

Moving to the target does not change focus. In Opera, focus remains on the link, until focus is removed, e.g., clicking somewhere else.

Add this to your stylesheet:

*:target {
  color: green;
  }
 
a[href]:focus {
  color: pink;
  }

cheers,

gary

OK, thanks. I thought that Stomme poes was saying that her method *would* make the focus move to the target in all browsers, and hence let keyboard users follow internal links. But from what you're saying, that isn't the case.

Thank you for your patient help - I appreciate it. The target css is neat, I didn't know about that before.