I guess my real question is this: What does the presence of an href say about an a? And what does its absence say? Should an anchor, ideally, only be used when you’re linking to a different page (or different part of the same page)? Is it wrong to use the anchor primarily to capture the tab?
I used to think the href was a requirement in the spec because some browsers didn’t react to anchors without one, but apparently it’s an optional attribute (!)
(you can see that it is not required by seeing that the specs call that attribute #IMPLIED (meaning the user agent might have it’s own default) and not #REQUIRED)
This possibility that some user agent may have a default is important… but you’re going to return false anyway right?
You’re thinking if there’s an href, the anchor is meant as a hyperlink to somewhere else, and if that’s not why you put it there, then maybe an anchor isn’t the right element?
I would say that in general hyperlinks should be used for going somewhere, whether it’s on-page or another page. However I have used them for when I need a focus point, mostly for accessibility reasons.
I’ve used them to make help text appear in forms.
I’ve used them to make something focusable in IE6 (who only focuses on anchors and inputs, and only does :hover and cursor:pointer on anchors).
However I’m careful to make sure the correct element (semantically) is also present: the anchor is usually WITH the correct element to help-along, and isn’t just scattered around for Doing Stuff. If I need to use anchors for that, they would be created purely in Javascript.
Again if these “tabs” you mean are for people to choose/select settings or that kind of thing, then a form of some sort may make way more sense. Forms can easily be kept accessible as they have pre-defined behaviours in user agents and modern screen readers are cool with those.
Re the article:
approach 1 as you’ve noticed leaves keyboarders out (unless you do the whole negative tab index thing… but look what they’re doing: taking a non-anchor and trying to make it an anchor. I find this worse than taking and anchor and making it a button).
Approach 2 seems silly: if I’m creating an anchor with Javascript in order to Do Stuff, then why am I adding Javascript inside to do nothing?
I’d even see if document.createElement(‘a’) with some textNode and an onclick event would work in all browsers (it might not, like IE8 might insist on an href). If it worked in all browsers then I’d consider making anchors-who-don’t-go-anywhere just not have that attribute.
However I’d also see if creating an actual <button> element was better. The point of <button> is to add scripts to it that Do Stuff… really the disadvantage of them is IE is retarded with them. There are Javascripts to fix that buggy behaviour though… Dean Edwards has one I believe.
Approach3 removes the flexibility of keeping event triggers external, you can’t use this and if you have a bazillion links on the page who need to do that same event, it’s a lot of added HTML crap. Even if you’re creating them in JS and adding them to the page… makework.
However the guy is absolutely right about the #. First place of trouble is the bringing the user to the top of the screen— this is especially a problem with users with a screen reader. They’ll know the page reloaded, and after they get the Title or start scrolling back into the page they’ll (hopefully) realise they’re on the same freakin page, and be like wtf? Instead, you want them to remain where they were.
Second issue with # is in menus like dropdown menus. People will have a Main category at the top, as an anchor with href=“#” and then use Javascript (or even JS and CSS) to make the dropdowns appear. This is retardation on a few levels: that top anchor should be an anchor, but instead of href=“#”, it should be href=“a page with all the same options available in the dropdown” because plenty of users won’t be able to get those dropdowns to show for one reason or another (no JS, or they’re using IE6 and you didn’t build for that, or they’re using a touch device that can’t :hover, or you didn’t make it keyboard-friendly…)
I surf with JS off 99% of the time. I notice these href=“#” and they bug me too. If the link doesn’t work without JS, remove it.
This defeats the guy’s main point though: IF you have href=“#” in an anchor who is created with Javascript in the first place, then you have an event on that sucker and you’re going to return false. So this behaviour of filling up your history (doesn’t on my browser but it’s a valid complaint) or bringing the user to the top isn’t an issue: even the “#” is false and gets ignored. Those without scripting who can’t run the event… don’t have any anchors anyway.
Still, I’d prefer to either
-try without href and see if that’s cross-browser
-use a non-existent href like #void or #foo
-see if another element like a <button> makes more sense (and if it works cross-browser… one button is usually ok but IE has issues with mutliple buttons and styling them or not letting text get cut off in them is IE trouble)