This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting.html Multipage: http://www.whatwg.org/C#pseudo-classes Complete: http://www.whatwg.org/c#pseudo-classes Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: :enabled shouldn't match links, since they have no disabled state Posted from: 98.110.194.132 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:34.0) Gecko/20100101 Firefox/34.0
http://www.w3.org/TR/selectors/#enableddisabled seems pretty clear that :enabled should only match things that can in fact be disabled....
And there is no clear web compat need for the current spec, of course, nor obvious reasoning that I can see.
FWIW, I agree with Boris.
Looks like this is the way the spec has been since February 2009. I don't see any record of why. Given that only Chrome seems to do this, I guess the spec should change. Tab, any opinion on this?
Apparently WebKit has recently been updated to do this too, actually. I don't have a strong opinion one way or the other. I think it makes sense to make :link match :enabled, since it's quite possible that we'll make it possible to disable links one day. I also think there's not a very good reason to have specced this in the first place, though. The biggest reason I have to not change the spec is that flip-flopping the spec is really bad for morale amongst browser vendors, and runs a huge risk of making people ignore the spec going forward. But if pretty much all the deployed browsers do something different than what the spec says, it's easy to argue that the spec is just wrong.
Speaking just as a web developer I would like to be able to disable links (preferably with the [disabled] attribute), and have :enabled/:disbabled apply to them. I have many times had to add class="disabled" to my links, and change my CSS selectors from :disabled { ... } to :disabled, .disabled { ... }, and change my JS code from .setAttribute("disabled", "") to .classList.add("disabled"), when refactoring from button to link or similar.
I would be ok with links matching :enabled if they could in fact be disabled.
(In reply to Boris Zbarsky from comment #7) > I would be ok with links matching :enabled if they could in fact be disabled. +1 for that. This would maintain current specification for :enabled, as Hixie mentioned, and provide a simpler understanding of how both :enabled and :disabled selectors behaves.
Well we can certainly add a feature to make links be something that can be disabled, if there's vendor interest in implementing that. But would we add that feature in the absence of this forcing function?
I would ;) More seriously, assuming this passes the Intent to Implement "does this help mobile performance?" gauntlet of blink-dev, I'd volunteer to implement disabling links via the disabled attribute in Blink. So there's some tentative vendor interest for you...
bz, hober: So is disabled="" on <a href=""> something you want to implement? Or is this something we should wait on for now? And if we wait, do you want :enabled to stop matching <a href=""> even though it'll start matching it eventually if we add this?
We're not strongly for or strongly against. It seems reasonable, but it's already pretty easy to disable links in practice.
I'm strongly against having a halfway state, I think. Past that, I have no strong views and no immediate plans to implement anything here....
Checked in as WHATWG revision r8818. Check-in comment: Make :enabled not match <a href> https://html5.org/tools/web-apps-tracker?from=8817&to=8818