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).
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).
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.
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.
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.
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)