I suppose one explanation is that links are the only thing on can interact with without JavaScript. (True?) you can build an interactive dynamic page with JavaScript, so that’s one solution. You can make whatever you like sing and dance.
But if you forego JavaScript, then dynamic interaction is limited to a tags. Special casing with hover is an acknowledgment that a tags are already special.
Well, and form fields. Though in 2015 it would be astonishing to see a form without some JavaScript around it, if only to implement client-side validation. Which is actually on-topic, since form validation has been a thing that there have been attempts to turn into a declarative specification for at least the eleven years since this piece was written. :)
I do think the author’s question remains a good one today. As he suggests, :hover itself may not be particularly important either way, but it certainly weakens the argument for separation of responsibilities to have exceptions like this.
One thought that occurs to me is that JS often breaks accessibility concerns. When the navigation mechanism requires it, as so many drop-down menus do… But I haven’t spent much time at all playing around with voice-based browsers, so I don’t really know whether CSS-based hover features are better, worse, or the same as JS-based ones for those users. I can certainly say that neither is at all friendly to keyboard-based browsing, and of course these days lots of sites find themselves broken on touchscreens, where hover is not a possible operation.
But the fact that it’s not a feature everyone can use is an argument for doing it carefully or not at all; it’s not an argument for one way of doing it over another. One of the big benefits of CSS is that it’s at least possible to write a site that degrades well when not all the styles it asks for can be fulfilled, but the way hover features degrade isn’t helped by them being in CSS, because the author needs to have specifically created an alternative to them, regardless.
I suppose one explanation is that links are the only thing on can interact with without JavaScript. (True?) you can build an interactive dynamic page with JavaScript, so that’s one solution. You can make whatever you like sing and dance.
But if you forego JavaScript, then dynamic interaction is limited to a tags. Special casing with hover is an acknowledgment that a tags are already special.
Well, and form fields. Though in 2015 it would be astonishing to see a form without some JavaScript around it, if only to implement client-side validation. Which is actually on-topic, since form validation has been a thing that there have been attempts to turn into a declarative specification for at least the eleven years since this piece was written. :)
I do think the author’s question remains a good one today. As he suggests, :hover itself may not be particularly important either way, but it certainly weakens the argument for separation of responsibilities to have exceptions like this.
One thought that occurs to me is that JS often breaks accessibility concerns. When the navigation mechanism requires it, as so many drop-down menus do… But I haven’t spent much time at all playing around with voice-based browsers, so I don’t really know whether CSS-based hover features are better, worse, or the same as JS-based ones for those users. I can certainly say that neither is at all friendly to keyboard-based browsing, and of course these days lots of sites find themselves broken on touchscreens, where hover is not a possible operation.
But the fact that it’s not a feature everyone can use is an argument for doing it carefully or not at all; it’s not an argument for one way of doing it over another. One of the big benefits of CSS is that it’s at least possible to write a site that degrades well when not all the styles it asks for can be fulfilled, but the way hover features degrade isn’t helped by them being in CSS, because the author needs to have specifically created an alternative to them, regardless.
So, I dunno. :)