4 ms·

It's not that pushState() apps interfere with middle-clicking on links, it's that they have no real links to middle-click on. Common practice is to have a <div>

by skymt 14y ago

It's not that pushState() apps interfere with middle-clicking on links, it's that they have no real links to middle-click on. Common practice is to have a <div> or <span> (or maybe <a> without an href) styled to look like a link/button, then onclick run some code that performs a task and changes the URL with pushState(). This article suggests making your pushState() "links" actual links to the desired URL, then overriding the unmodified click case to run the desired code rather than fetch a new page from the server.

JoshTriplett 14y ago
I understood that much, and sure, if you try to construct browser links from scratch then their behavior won't match the behavior of real browser links. However, if you really do have an <a> tag, then you should only have the ability to override the "unmodified click case".
- skymt 14y ago
  I read the article as simply suggesting that developers create real, genuine <a>-tag links in their modern pushState-using web apps. Doubtful that there are enough people specifically overriding middle-clicking on links to warrant a blog post. For example (and not to call anyone out), there's this demo (warning: will fill your history): http://bodytag.org/rollstate/ http://bodytag.org/rollstate/ Looking at its source, it uses real <a> tags for its pushState() links, but with href="#". If you click on "contact", then middle-click "about", a new tab will open to "/rollstate/contact" (which 404s, another pushState() no-no).
  - pbiggar 14y ago
    Actually, there are. If you override the click handler on a link, you'll override the Cmd-click handler as a side-effect. My site does this (by accident), and I eventually had to ask StackOverflow to find that Sammy.JS (my client-side router) was doing it.
    - damncabbage 14y ago
      Also, Quora does it. (It's infuriating when I try to middle-click a run of interesting-looking questions and it "steals" the clicks.)
  - adavies42 14y ago
    i assume this is much like the js-driven crap that's been around for over a decade now where the mouseover text looks real but the actual href is "javascript:void(0)" or something?
alanh 14y ago
Oh god — that’s common practice? … What happened to progressive enhancement & unobtrusive JS being best practices?
- ori_b 14y ago
  It died when people stopped writing pages and started writing apps.
- devgutt 14y ago
  This is not a common practice, this is a wrong practice...unobtrusive isn't dead, even more semantic
- pbiggar 14y ago
  Both progressive enhancement and unobtrusive JS are dead. They died, in my opinion, for a lot of good reasons: - basically everyone has JS enabled - they were too hard to do - IE6 went away - you can make significantly better UX without them - there is business value to usable apps - there is no business value to catering to people who disable javascript - the existence of things like Modernizer make it possible to assume that everyone has the fancy features you need.
  - alanh 14y ago
    Some of your points are quite valid, but I must disagree progressive enhancement & unobtrusive JS are “dead” or should be. > - you can make significantly better UX without them This is the biggest place where you’re wrong, as the examples of right-clicking or middle-clicking a “div with JavaScript” plainly illustrate. Now obviously complicated web apps can’t work 100% or sometimes even 10% without JavaScript, but when reasonably possible, using progressive enhancement & unobtrusive JS will increase your compatibility across UAs, search engines, and other agents, and will avoid cases where your site seems broken in some crucial way. Not to mention users with accessibility needs will do much better interacting with your `<a>` tags than scripted `<div>`s. Have we forgotten about them again, already? Edited to add: Biggest tips w.r.t. accessibility: (a) Spend an hour using a screenreader and no mouse — e.g. VoiceOver, which comes with your Mac and works just fine in Safari. (b) Using semantic tags & progressive enhancement means your code will make the most sense to the screenreader — e.g. you will be able to tab onto your button/link because you actually defined it as one — and it will be described fairly accurately. Your "clickable" <span> is plainly going to be trickier for a screenreader… (c) Read up on WAI-ARIA, which lets you define roles for certain elements (like "notification" or "button"). If you want to make your AJAX work well for those with accessibility needs, this becomes fairly important as it can also help you manage focus and direct user attention.
derefr 14y ago
Really, it seems like a middle-click should just be a sent as a regular click event to Javascript, but with all document.href edits and window.open calls redirected to act on a new tab.

by skymt 14y ago

JoshTriplett 14y ago

I understood that much, and sure, if you try to construct browser links from scratch then their behavior won't match the behavior of real browser links. However, if you really do have an <a> tag, then you should only have the ability to override the "unmodified click case".

skymt 14y ago
I read the article as simply suggesting that developers create real, genuine <a>-tag links in their modern pushState-using web apps. Doubtful that there are enough people specifically overriding middle-clicking on links to warrant a blog post. For example (and not to call anyone out), there's this demo (warning: will fill your history): http://bodytag.org/rollstate/ http://bodytag.org/rollstate/ Looking at its source, it uses real <a> tags for its pushState() links, but with href="#". If you click on "contact", then middle-click "about", a new tab will open to "/rollstate/contact" (which 404s, another pushState() no-no).
- pbiggar 14y ago
  Actually, there are. If you override the click handler on a link, you'll override the Cmd-click handler as a side-effect. My site does this (by accident), and I eventually had to ask StackOverflow to find that Sammy.JS (my client-side router) was doing it.
  - damncabbage 14y ago
    Also, Quora does it. (It's infuriating when I try to middle-click a run of interesting-looking questions and it "steals" the clicks.)
- adavies42 14y ago
  i assume this is much like the js-driven crap that's been around for over a decade now where the mouseover text looks real but the actual href is "javascript:void(0)" or something?

alanh 14y ago

Oh god — that’s common practice? … What happened to progressive enhancement & unobtrusive JS being best practices?

ori_b 14y ago
It died when people stopped writing pages and started writing apps.
devgutt 14y ago
This is not a common practice, this is a wrong practice...unobtrusive isn't dead, even more semantic
pbiggar 14y ago
Both progressive enhancement and unobtrusive JS are dead. They died, in my opinion, for a lot of good reasons: - basically everyone has JS enabled - they were too hard to do - IE6 went away - you can make significantly better UX without them - there is business value to usable apps - there is no business value to catering to people who disable javascript - the existence of things like Modernizer make it possible to assume that everyone has the fancy features you need.
- alanh 14y ago
  Some of your points are quite valid, but I must disagree progressive enhancement & unobtrusive JS are “dead” or should be. > - you can make significantly better UX without them This is the biggest place where you’re wrong, as the examples of right-clicking or middle-clicking a “div with JavaScript” plainly illustrate. Now obviously complicated web apps can’t work 100% or sometimes even 10% without JavaScript, but when reasonably possible, using progressive enhancement & unobtrusive JS will increase your compatibility across UAs, search engines, and other agents, and will avoid cases where your site seems broken in some crucial way. Not to mention users with accessibility needs will do much better interacting with your `<a>` tags than scripted `<div>`s. Have we forgotten about them again, already? Edited to add: Biggest tips w.r.t. accessibility: (a) Spend an hour using a screenreader and no mouse — e.g. VoiceOver, which comes with your Mac and works just fine in Safari. (b) Using semantic tags & progressive enhancement means your code will make the most sense to the screenreader — e.g. you will be able to tab onto your button/link because you actually defined it as one — and it will be described fairly accurately. Your "clickable" <span> is plainly going to be trickier for a screenreader… (c) Read up on WAI-ARIA, which lets you define roles for certain elements (like "notification" or "button"). If you want to make your AJAX work well for those with accessibility needs, this becomes fairly important as it can also help you manage focus and direct user attention.

derefr 14y ago

Really, it seems like a middle-click should just be a sent as a regular click event to Javascript, but with all document.href edits and window.open calls redirected to act on a new tab.