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.
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".
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/
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).
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?
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.
Certainly, there's the right way and the wrong way, but don't throw the baby out with the bathwater. It's still early days for pushstate apps, and they have yet to get their "Rails moment". Middle-clicking problems and the like are inevitable. (Do you remember sites used sessions to remember where you clicked, so tabs didnt work at all? This too shall pass).
You say progressive enhancement helps you out in all these cases, but I just see opinion, and very little evidence. So all I have to offer you in rebuttal is the same - I believe the opposite.
I agree about accessibility. I frankly don't know what to do there. On the one hand, I hate the idea that I might be excluding somebody. On the other hand, I tend to implement things lazily, so if I'm never asked for a feature, I probably won't do it.
Please don't put words in my mouth, and please don't immediately assume the very worst interpretation of what I say.
For example, when I said "there is business value to usable apps", I actually didn't imply "there is no business value to casting a wider not". To say nothing of your "quick buck" comment.
It's dishonest to play tricks like this, so I would ask you to rewrite your comment as if your target audience was an intelligent human being looking for an intelligent discussion.
"there is business value to usable apps" didn't fit into the tone of your post, so I hope you can forgive a bit of unintentional creative interpretation (one word). I made no attempt to play tricks.
The rest of the post was simply a point-by-point dissection. None of your other points are valid. The only somewhat valid argument I hear against proper browser compatibility is "we don't have time", which is usually a self-inflicted wound.
Stable web pages that gracefully degrade are fully possible, even today. I wrote a unit test that degrades in IE 5 this week.
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.
Comments
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.
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".
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/
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).
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.
Also, Quora does it.
(It's infuriating when I try to middle-click a run of interesting-looking questions and it "steals" the clicks.)
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?
Oh god — that’s common practice? … What happened to progressive enhancement & unobtrusive JS being best practices?
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.
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.
Certainly, there's the right way and the wrong way, but don't throw the baby out with the bathwater. It's still early days for pushstate apps, and they have yet to get their "Rails moment". Middle-clicking problems and the like are inevitable. (Do you remember sites used sessions to remember where you clicked, so tabs didnt work at all? This too shall pass).
You say progressive enhancement helps you out in all these cases, but I just see opinion, and very little evidence. So all I have to offer you in rebuttal is the same - I believe the opposite.
I agree about accessibility. I frankly don't know what to do there. On the one hand, I hate the idea that I might be excluding somebody. On the other hand, I tend to implement things lazily, so if I'm never asked for a feature, I probably won't do it.
> - basically everyone has JS enabled
Nope; don't forget that scripts don't always load. Opera on Mint kills bloated scripts (a.k.a. jQuery). This usually results in a white page.
> - they were too hard to do
Perhaps lazy developers should reconsider their profession then.
> - IE6 went away
Browser versions are irrelevant.
> - you can make significantly better UX without them
An utter falsehood. Refer to my earlier experience with white pages.
> - there is business value to usable apps
There's no business value in casting a wider net? That's bewildering.
> - there is no business value to catering to people who disable javascript
It seems to me that you're only interested in turning a quick buck. That's disheartening.
> - the existence of things like Modernizer make it possible to assume that everyone has the fancy features you need.
Assumptions cast from half-baked feature tests aren't an absolute by any measure. "Everyone" is definitely misleading here.
Please don't put words in my mouth, and please don't immediately assume the very worst interpretation of what I say.
For example, when I said "there is business value to usable apps", I actually didn't imply "there is no business value to casting a wider not". To say nothing of your "quick buck" comment.
It's dishonest to play tricks like this, so I would ask you to rewrite your comment as if your target audience was an intelligent human being looking for an intelligent discussion.
"there is business value to usable apps" didn't fit into the tone of your post, so I hope you can forgive a bit of unintentional creative interpretation (one word). I made no attempt to play tricks.
The rest of the post was simply a point-by-point dissection. None of your other points are valid. The only somewhat valid argument I hear against proper browser compatibility is "we don't have time", which is usually a self-inflicted wound.
Stable web pages that gracefully degrade are fully possible, even today. I wrote a unit test that degrades in IE 5 this week.
> I wrote a unit test that degrades in IE 5 this week.
I hope the 0.02% of your users who benefited from that, are very happy.
It died when people stopped writing pages and started writing apps.
This is not a common practice, this is a wrong practice...unobtrusive isn't dead, even more semantic
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.