I just started a blog, and after I finished my first entry I went back to proofread and check the hyperlinks. I discovered that for some reason, clicking a link doesn’t open a new page, it goes to the link in the existing window (tab).
I searched all over blog.com’s help stuff, but couldn’t find a specific answer to what I’m looking for: how do I set it so that links open in a new window, instead of in the existing window?
The reason I want it like this is because I want to help my readers navigate to new content, but not lose my content in the process. I’d rather they close the new window to get to my article than have to hit the back button.
Is this something that would be in the settings for the blog, or is it some variation on the HTML code to set up the hyperlink?
Adding in that bit of code has somehow caused all my links to disappear. EVERY thing that was <a href=http://somethingdotsomething"target="_BLANK"> now just says <a>
That means over 25 sites I have to find again in order to get their address, then I have to recode the whole page.
You’re of course welcome to do whatever you wish, but it’s worth pointing out that the use of the target attribute for links is not only a poor choice from a usability standpoint, it’s also no longer part of the specification.
Missed the edit window, but it appears that the links that you can set up in the “blogroll” on the sidebar also are not “open in a new window”… It seems like there has to be a way to set that as the default for the blog, so that every link you post will open in a new window. Or is that just something that a person would have to set their browser to do, and in fact I do have to code everything as described, which then causes everything to get erased?
Hmm I don’t see why it would have done that. Did you forget any quotation marks? I see you’re missing one in the example code you just gave but maybe you just mistyped it in your post.
Regarding usability, now it’s the standard to put all of your tag attributes into CSS (cascading style sheets). For what you want to accomplish, however, I personally think it’s unnecessary.
The problem here in SD seems to be that when the links window opens…it already has the http:// in it. So if you have copied a link with that in it, it doubles that part of the address…and screws things up.
I had a problem putting a link into my stuff…but now I delete everything in the window…and then paste the address into the url space…and it works fine.
yeah that was just me typing quickly and not doing <a href="http
All I did to add the code to my blog was paste target=“_BLANK” into each of the already written <a href=“http://website.com”> code, right after the last " and before the final >
And now every link in code just says <a>text</a>
ETA: great. I seem to have missed a space before the word target. Still not sure why that would cause all the link info to disappear, maybe it has something to do with the autoHTML feature that blog.com has.
From a usability standpoint, you are forcing the user’s browser to behave in a certain way; if I want to open the link in a new tab or window, I’m perfectly capable of doing so on my own. The logic that I will read the new window and then resume reading your content when I’ve closed the new window is flawed; I should resume reading your content because I desire to do so - it’s the quality of your content that should draw me back, and (again) I’m perfectly capable of using my Back button if I so desire (or closing the new tab/window that I chose to open your link in on my own.
Tag attributes like “target” have nothing to do with CSS.
I wouldn’t recommend this approach either as it alienates an (admittedly small) portion of your potential readers with different accessibility needs than yours or mine - someone using a screen reader or browsing without javascript enabled will have no idea there is a link here.
All the other discussion aside (sorry for the hijack), this is likely the cause.
I do this shit for a living, and disagree with you. If I’m in context A, and I wish to retain that context while accessing context B, I am grateful to the web manager to make my browser retain my first context while accessing the new one.
Like, for example, links on the SDMB. It would drive me nucking futs to have to hit “back” to return to a thread - particularly if context B contains hyperlinks that lead to further exploration, which they often do. I’m therefore very glad that vBulletin automatically inserts the target="_blank" attribute into every external link.
Plus, from observation I believe most web users are not as sophisticated as you or I, and don’t know how to open stuff in new tabs or windows with a right-click, etc. To regain their original context, they’d have to perform conceptual gymnastics - particularly if they’ve passed through dynamic content or form submissions.
So I say to the OP, yes, open a new window for external content, and let your users retain the origin of the link, while giving them the option to explore further without losing it. My professional policy is roughly “if it’s on a different domain, or is a different filetype, then open it in a new window”.
I have served content to millions upon millions upon millions of web visitors over the years, and have received not one single complaint about this policy.
In my experience a lot of blog software is capable of massacring source HTML, even when you are trying to edit it directly. They prefer you use use those inline WYSIWYG editors that have an option to edit directly, but are incapable of keeping the ASCII you enter the same as the ASCII it stores in a database field. For instance, I’ll type a space in the source editor field and have it turn into a in the datacase. As in if I were writing javascript that says if (…), the blog will turn my code into if (…).
Maybe I’m reading too much into your question but I’m not at all surprised to hear blog software blew away all the URLs someone hand coded into their source HTML.
Yeah, best I can figure is that the auto-HTML software saw my improperly coded entry, and erased the entire string of text where the error occurred, this leaving non-error-ed coding intact, so the page will display.
At any rate, I was able to find where links had been and then it was easy to find them and re-code the HTML properly. My thanks to Engywook for noticing that missing space. BrandonR, you still rock!
Thanks to everyone else for their help.
Oh, and jjiimm pretty much followed my same reasoning, plus I have extensive research that shows that my target audience is pretty much going to have been influenced by many of the same things that I am usually being influenced by, and sometimes out of sight translates into out of mind. Making sure that my blog is still up in a window will go further towards ensuring that people can remember who steered them whatever song or shiny object captured their attention so completely.
The usability part has been addressed, but to reiterate: it’s not your browser, do not try to control it. It is not your purview to do so.
No longer part of the specification means that there are rules for (X)HTML, standards as to what markup is to be supported by browsers and what markup browsers can choose not to support. The target attribute is no longer valid markup, it is deprecated and a browser that does not support the target attribute at this point would still be entirely standards-compliant. All the major browsers do still support it, but they don’t have to.
But that’s a HUGE if. If retaining context is important to you, then it is incumbent upon you to learn how to use your browser’s tools to do so, not to rely upon content providers to make that decision for you and me, when I am completely disinterested in being forced into new windows or new tabs.
Probably because you’re not serving content on a blog but on corporate sites, where disregard of web standards is de rigeur and multiple windows and tabs being spawned beyond the user’s request is not unusual. People consider it par for the course, but that doesn’t mean that they appreciate it.
I agree (although I don’t do this for a living, so my opinion carries less weight than yours) - reference links appearing in the middle of the flow of an article are conceptually quite different from site navigation links that are used when one is finished with the page.
Opening reference links in a new tab offers the reader a choice of looking at them now or later. Granted, it probably does annoy a few people if they feel strongly about re-using windows, but you can’t possibly please everyone all of the time.
There are even a number of scenarios in which I would consider it preferrable to have an on-site link open in a new window/tab - for example: links to product descriptions or Terms & Conditions, when appearing midway through a shopping cart checkout process.
That’s a damn good way to alienate users of NoScript, like me. Care should be taken to ensure that a site is at least somewhat usable with JavaScript disabled. Putting your links in a Javascripted div is needlessly complex, less compatible with screen readers (as fubbleskag noted), neatly bypasses whatever browser settings users may have regarding links, and is just daft. Please stop doing it.
IMO this is an idealistic view, and based on a context of actually understanding how this stuff works. Whereas most - and by “most” I literally mean “the majority of” - Web users need to be spoon-fed in how they handle their browser. I work with “usability” in terms of how the lowest common denominator in terms of how Web users actually use sites (until recently, I was running very large sites for the UK government).
If you’re really good at using a browser, and understand its underlying concepts, then you’ll likely be able to override the stuff you don’t like.
However, if you think Internet Explorer is something mysterious called “the Internet”, then you do indeed a lot of prompting, pushing and shoving - purview or otherwise. And that is in fact the majority of Web users.