Ok. I just put IE8 on my computer and I thought I would take a look at my websites in the new version.
I started singing the anger song.
It seems that IE8 like line breaks and is putting them in where they don't belong.
To be clear:
In IE7, it looks fine
In Firebox, it looks fine
In IE8 with "compatability view" (oh God... help me) turned on, it looks fine
But in IE8 (with compatability view turned off, I am getting extra return lines. It seems to happen around A elements, but it is sporatic.
Take a look at this link:
http://www.thecolpis.com/geocaching/guestbook_log_entry.php?id=1#texttop
See how "Visit the" and "picture index" are on seperate lines? That is bad (and it doen't happen in other browsers or if I turn compatability view on.
Same thing here:
http://www.thecolpis.com/geocaching/bookaneers_log_entry.php?sf=dt&so=lh&rp=-1&pa=1&id=3&oi=3&pi=1#pictop
But now, take a look at this one:
http://www.thecolpis.com/geocaching/bookaneers_log_entry.php?sf=dt&so=lh&rp=-1&pa=1&oi=3&id=3&pi=2#pictop
Similar problem, but now the 1st line is blank.
Same thing here:
http://www.thecolpis.com/geocaching/bookaneers_log_entry.php?sf=dt&so=lh&rp=-1&pa=1&id=8&oi=8&pi=4#pictop
Any help would be appreciated. Thanks in advance.
-Daniel
more data
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 <A> element shouldn't be
... are you sure?
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
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.
HOLY COW!!!
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
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
might also validate. It's closed.
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:
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
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
I am unable to replicate your findings. Stomme's example works as expected in Firefox, IE, Opera, and Safari.
cheers,
gary
That's interesting...
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.
Add enough filler, e.g.
fill
, to force a scroll situation.
cheers,
gary
I've updated the example
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
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
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.