You could assign a specific class or rel to these links, and then use Javascript to add a the linked image after each one, which would open in a new window. For example, if you have the jQuery framework installed (my preference), you could use something like this:
Depending on your specific needs, you may want to fiddle with that to exclude, or handle differently, things like linked images, etc.
Most, if not all, major blog platforms open links in the current window by default; changing this behaviour does not require changing source code, as most include a simple radio/checkbox in the editor to handle this, if desired.
That’s a huge problem in and of itself. If there are no studies saying that users actually prefer one way or the other, then the standards are merely arbitrary. Why would anyone feel the need the need to follow something that is completely arbitrary?
But I think there’s a bigger disconnect here. Why should any standards be telling you what the user wants? Even at their best, they can only tell you what the average user throughout the entire web wants. It’s very likely that the users of your site will not fit that mold.
Standards should be about simplifying markup. About making it accessible* and forwards compatible. It should only provide guidelines about what users want. Don’t take away the ability to provide it, making us have to craft ugly work arounds (see also making custom scroll bars).
A problem you have yet to quantify as existing. If the research goes both ways, how can you say it is a problem? So not only do we have standards telling us that our users should want what average users want, but they aren’t even sure what the average user wants.
*While accessibility should be possible, anyone with a severe disability should be fine with having to have special settings. They already have to have special software. Heck, I’d even go with colorblind people needing to enable colorblind mode, just like people with bad eyesight enable high contrast mode. And yes, they could disable custom scroll bars mentioned above. If the other users want it, provide them a way to have it, while still allowing those who don’t not to have it. That’s good design.
There’s no checkbox to change this is Blogger, the largest platform. Blogger Help Center tells users to add a target=_blank to the URL to open a new window.
If the most popular blog platform tells people to do it this way, how can your pronouncements on the subject be taken seriously?
The standards in question are in a constant state of development by an international community. Are they perfect? No. Do they need to be perfect for me to follow them, advocate for others to follow them, and potentially take part in the on-going development? No. I’m not even entirely convinced the standards on this particular topic are 100% correct (someone earlier in the thread mentioned the opening of non-web documents in a new window, which makes logical sense to me).
You’re right, there is a disconnect - but it’s not where you think. The standard on the use of the target attribute is not telling us what the user wants. Not the average user, not a particular user, not any user. It’s telling us what is currently believed to be the best practice to allow the most users the most control.
Two great things about web standards: 1) you don’t have to follow them - no one is making you craft any workarounds, ugly or no; 2) if you wish to follow them, but don’t like them, you can take part in the discussion and make a case to have them changed. This standard in particular is one I break on a daily basis: the client wants their links to open in new windows; I explain why I feel it is better not to do that; sometimes they agree, and sometimes they don’t; I always do what they want in the end if I want to get paid.
The problem is that some people expect/want links to open in new windows, and others expect/want them to not and without a standard being followed people on both sides are being left frustrated. If a standard is being followed, even if it’s not 100%, at least people on both sides know what to expect. This is where I again concede the idealism.
Let’s imagine for a moment that ‘it’ refers to ‘opening external links in a new window’. Until future versions of common user agents include an easy option for people to set their preference, or more people begin using custom plugins to the same effect, the best way to fulfill your “good design” is to always open links in the same window by default. Those who don’t want this, can force the link to open in a new window by Ctrl-click, Middle-mouse-click, or right-click. Those who do, just click. If you reverse these, you’ll find that people who want new windows just click, while those who don’t want new windows no longer have a choice.
Thank you for independently confirming my research regarding #1, at least as far as Blogger is concerned. As for #2, I suppose I could have moved a word or two around to ensure my point would not be misunderstood - it was my intention to include ‘changing the source code’ in my grouping of ‘most’ - not to claim that ‘no major blogging platform requires changing the source code’ which is seemingly what you read?
Can we at least agree that there are some situations in which a link should never open in the same window? If you are on step 3 of 5 of checkout at an online store, and you click the product name to double-check something about it, or you click a link to the Terms & Conditions, next to the checkbox that says you agree with them, would you ever want those links to open in the same window, discarding the context of the partially-completed checkout process?
I’m challenging the second part of that statement. Most, if not all, major blog platforms do NOT “include a simple radio/checkbox in the editor to handle this, if desired.”
As I noted in my last post, there are scenarios in which a new window does make a lot of sense. I would still make an effort to find a solution that doesn’t involve forcing the new window. Take Terms & Conditions during a checkout as an example. The text of the Terms & Conditions can be included in the original markup, perhaps at the bottom or side of the page; when the page loads, a javascript function hides this text from being displayed until such time as the link is clicked upon; then, a “popup” is created using something similar to the popular LightBox (popup in quotes because it is not actually a new window at all - I’d be happy to create a demo of this scenario if you’re not familiar with the effect I’m describing). By doing all the hiding and showing of this content via javascript, people with it disabled (either by choice or because their agent doesn’t support it, ie. screen-readers, search engines, etc) instead see the text displayed on the page and the clicking of the link uses an #anchor to scroll them down to the desired location. All this without forcing anyone to open a new window or leave the checkout process.
Yes, it does. I’m not sure why the Codex is outdated on this topic, while the support documents are not, but after I’m done here I’ll make an effort to have it updated.
Yes, it does. Also, the PPT that you’re referring to was written in 2005; presumably that’s why it is inaccurate.
Conceded. This was the platform I had in mind when I specified “most” as I had actually performed some testing before making the claim.
Also conceded. * This is one I hadn’t tested, making the mistaken assumption that if TypePad was using a smart WYSIWYG, then so would Movable Type, as they’re from the same company.
Your unnecessary snark aside, your contribution led me to clear up a few areas of my own ignorance on this subject - so, thanks?