...

View Full Version : target="_" Strict Alternative



daemonkin
06-28-2007, 11:39 AM
Is there an alternative to the deprecated target="_blank" for
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

I am having problems with my validation.

Thanks D.

Bill Posters
06-28-2007, 11:52 AM
There are a number of techniques available to workaround the deprecation of the target attribute.

This SitePoint article was amongst the early ones.
http://www.sitepoint.com/article/standards-compliant-world

I also have my own, more exhaustive efforts in this area.
http://test.newplasticarts.co.uk/dom-js/flag-offsite-links


It's likely that some will post to recommend against using new windows as opinions about their use vary.

daemonkin
06-28-2007, 12:15 PM
Its not really a new window.

I am having problems with the <noscript> tags - even when I remove the <a> tag, the <img> tag and replace it with just text it finds a problem with that.

Any comments appreciated.

D.

Bill Posters
06-28-2007, 12:54 PM
Its not really a new window.
Then why suggest that the problem is target="_blank", which is used to create new windows?


I am having problems with the <noscript> tags - even when I remove the <a> tag, the <img> tag and replace it with just text it finds a problem with that.
None of that is likely to make more sense we can see your code.
Post a link to the page in question.

Fwiw, noscript elements need to use block-level elements as their direct descendants. Placing an inline element as a direct descendant is invalid under a Strict doctype.

e.g.

<!-- valid -->
<noscript>
<p><a href="…"><img src="…" alt="…" /></a></p>
</noscript>

<!-- invalid -->
<noscript>
<a href="…"><img src="…" alt="…" /></a>
</noscript>

Using noscript elements adheres to the principle of 'graceful degredation'. However, if you follow the approach of 'progressive enhancement' instead, there should be no need for noscript elements.

The principles of progressive enhancement mean starting with the non-js version and then using js to remove or replace certain parts of the markup or enhance them with js functionality.

The SitePoint article and my own js method both show how the principle of progressive enhancement can be used to tackle the issue of links and new windows.

Jutlander
06-28-2007, 06:58 PM
It is possible to do with Javascript, with this line added to the link


onclick="window.open(this.href, '_blank'); return false;"

But I advice you not to use it, because the user has absolutely no choice whether to open or not and if he or she holds down Ctrl while pressing, it will open two windows (tabs in my case, because I use Firefox).

Bill Posters
06-28-2007, 08:07 PM
It is possible to do with Javascript, with this line added to the link


onclick="window.open(this.href, '_blank'); return false;"

But I advice you not to use it, because the user has absolutely no choice whether to open or not and if he or she holds down Ctrl while pressing, it will open two windows (tabs in my case, because I use Firefox).

Fwiw, if you use js to add the target, then it won't trigger the double window issue.

e.g.

<a href="…" onclick="this.target='_blank';">…</a>
I know it's not ideal as it kinda goes against the sentiment of its deprecation, but so long as using window.open triggers a second new window, …

Fwiw, my own method, to which I linked in an earlier post provides a toggler, enabling users to choose whether external links should open in a new window or not.
(It covers those who might like it so, but who aren't sufficiently familiar with their UA to enact it themselves.)


Of course, in all cases, links which open in new windows should provide notice to users of that behaviour, either by text, icon or a combination of both.

felgall
06-28-2007, 09:04 PM
If you use target="_blank" either in the HTML or the JavaScript then you should be using a transitional doctyle as your page is no longer valid for strict. Adding invalid elements after you validate doesn't make the page valid, it just means you are validating only part of the page.

Jutlander
06-28-2007, 09:12 PM
IMO, developers shouldn't put any code in the links that open them in a new window or tab. Let the users decide for themselves.

Bill Posters
06-28-2007, 09:46 PM
If you use target="_blank" either in the HTML or the JavaScript then you should be using a transitional doctyle as your page is no longer valid for strict. Adding invalid elements after you validate doesn't make the page valid, it just means you are validating only part of the page.

Until the W3C stipulate to UA developers that deprecated attributes should be unaddressable/unsettable via the DOM, there's wiggle room for interpretation over just how wrong using the target attribute via js under a Strict doctype is.

However, as mentioned, the use of the target attribute is a less-than-ideal fallback used due to the problems which arise when using the window.open method.


(Fwiw, I shall continue to use Strict doctype regardless, because it's the only doctype which can set browsers on their absolute, best behaviour.)

Bill Posters
06-28-2007, 09:48 PM
IMO, developers shouldn't put any code in the links that open them in a new window or tab. Let the users decide for themselves.
This is part of a long and often over-simplified argument.
Suffice to say that I won't go into it now, but the end result is invariably - views differ.

Jutlander
06-28-2007, 09:56 PM
I am aware of that, that's why I used the abbreviation "IMO" as the first.

Arbitrator
06-29-2007, 04:19 AM
Is there an alternative to the deprecated target="_blank" for
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

I am having problems with my validation.Your valid alternatives are to (A) generate a pseudo‐window by use of something like an absolutely positioned div and scripting, (B) use proprietary methods such as window.open(), or (C) switch to use of the HTML or XHTML Transitional DTD so that you can use the target attribute.

Your invalid alternatives are to (A) use the target attribute anyway or (B) use scripting to generate the target attribute. The latter method will allow you to maintain the guise of using valid code while not actually doing so. I point this out, mainly, since solution (B) is what Bill Posters and that SitePoint article would have you do. I would imagine that the main advantage (of (B)) is so that you can show others that you’ve produced “valid” code while being compelled to use a Strict DTD for whatever reason.

I would take into careful consideration whether generating a new window is actually necessary. If it is not, I would avoid doing so.


Until the W3C stipulate to UA developers that deprecated attributes should be unaddressable/unsettable via the DOM, there's wiggle room for interpretation over just how wrong using the target attribute via js under a Strict doctype is.element.setAttribute("target", "_blank") is the same thing as <element target="_blank"/>. Thus, setting the attribute via the DOM results in an invalid document. I would imagine that an implementation of DOM3 Validation and element.allowedAttributes or element.canSetAttribute("target", value) would affirm this; it’s unfortunate that I don’t have such an implementation to demonstrate with.

Bill Posters
06-29-2007, 09:45 AM
element.setAttribute("target", "_blank") is the same thing as <element target="_blank"/>. Thus, setting the attribute via the DOM results in an invalid document. I would imagine that an implementation of DOM3 Validation and element.allowedAttributes or element.canSetAttribute("target", value) would affirm this; it’s unfortunate that I don’t have such an implementation to demonstrate with.

With all respect, you can go on about how using scripting to implement the invalid target attribute is bad mojo until you're blue in the face. I've already acknowledged that it's not the ideal approach. However, it's still the least problematic option available and I'll continue to use it (and endorse it, with caveats) until UAs manages to sort out a better way to deal with links which use window.open which have also been targeted at a new window/tab by the user.

I use it knowingly, aware that it doesn't tick all the boxes, but also knowing that the validity of the computed DOM is not always the absolute be-all and end-all. As said, until such time as UA or the DOM actively and practically reflect spec DOM validity, it's there as an option.

Truth be told, I don't see it as being that much different in principle to using conditional comments to shield the DOM from non-standard, IE-targeted markup or CSS. It's a trick, but these are the things we are sometimes required to do to achieve the results we want.

Arbitrator
06-29-2007, 11:33 AM
With all respect, you can go on about how using scripting to implement the invalid target attribute is bad mojo until you're blue in the face. I've already acknowledged that it's not the ideal approach. However, it's still the least problematic option available and I'll continue to use it (and endorse it, with caveats) until UAs manages to sort out a better way to deal with links which use window.open which have also been targeted at a new window/tab by the user.If your basic point is, “While setting the target attribute under a Strict DTD via scripting is technically invalid, due to the poor state of current implementations, I would suggest a compromise in favor of functionality and use the attribute in such a circumstance anyway,” then I see no need to argue.

However, my impression is that you’re implying that using the DOM to insert the attribute means that the document is valid. One of my objectives is to dispel such illusions. If one is going to set the target attribute anyway, they might as well take the easy path and just set the attribute directly, without use of the DOM. The only reasonings that I can see for the scripting‐based approach is if one wants to build extra functionality onto the attribute (e.g., as shown in your second resource) or a client (including one’s self) insists upon a Strict DTD, validity, and the ability to reliably generate new windows at the same time and one wants to also be deceptive about meeting the validity constraint.


Truth be told, I don't see it as being that much different in principle to using conditional comments to shield the DOM from non-standard, IE-targeted markup or CSS.A conditional comment is, literally, just a comment from a technical point of view. That Internet Explorer does something proprietary with it doesn’t make it less valid. It’s different because a correct implementation will see a valid document.

nolvorite
06-29-2007, 01:08 PM
If you want your page to be valid w/ that doctype, use javascript. period.

Bill Posters
06-29-2007, 01:43 PM
my impression is that you’re implying that using the DOM to insert the attribute means that the document is valid.
Your impression is wrong.
I've made more than one statement in this thread making clear that I know the technique to produce an invalid DOM, and that, as such, it is not ideal, but merely an effective compromise.


If one is going to set the target attribute anyway, they might as well take the easy path and just set the attribute directly, without use of the DOM.
I disagree. By using js to instate the target attribute, we can still, at least in part, honour the sentiment for which the W3C deprecated the target attribute - namely that behavioural attributes, along with presentational attributes, should be farmed out to scripting layer and presentational layer respectively.


A conditional comment is, literally, just a comment from a technical point of view. That Internet Explorer does something proprietary with it doesn’t make it less valid.
It's still simply using a backdoor approach to adding often invalid markup or stylesheets to a valid document in a way which the validator won't notice.
As said, I don't see it as being that different.

Clearly we'll disagree over this point.

I can be as evangelical as the next standardista, but idealism is sometimes going to play second fiddle to pragmatism.

felgall
06-29-2007, 10:58 PM
If you grab the generated source after the JavaScript has been run using any standards compliant browser hen that HTML should still pass validation. If it doesn't then either the browser has corrupted the page content or the JavaScript has inserted invalid content. With a decent browser the first shouldn't happen and the page author has control of the second so that it shouldn't happen unless the author deliberately invalidates the content. As long as they don't attempt to claim that the content is valid by adding a logo to that effect to their invalid page then they are only fooling themselves.

Arbitrator
06-30-2007, 12:42 AM
I've made more than one statement in this thread making clear that I know the technique to produce an invalid DOM, and that, as such, it is not ideal, […].Well, at least we agree on something.


I disagree. By using js to instate the target attribute, we can still, at least in part, honour the sentiment for which the W3C deprecated the target attribute - namely that behavioural attributes, along with presentational attributes, should be farmed out to scripting layer and presentational layer respectively.I’m a bit dubious about that. Consider XLink (http://www.jsgp.us/demos/CF117463.xml).


<?xml version="1.0" encoding="UTF-8"?>
<document xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:xlink="http://www.w3.org/1999/xlink">
<xhtml:title>Demo CF117463</xhtml:title>
<xhtml:style type="text/css">
document { display: block; padding: 1em; background: white; text-align: center; font: 16px/1.2 sans-serif; }
style { display: none; }
link { padding: 0.1em 0.2em; color: blue; text-decoration: none; cursor: pointer; }
link:visited { color: purple; }
link:focus { outline: 1px solid #eee; }
link:hover { background: #ffe; }
</xhtml:style>
<link xlink:type="simple" xlink:show="new" xlink:href="http://www.codingforums.com/">http://www.codingforums.com/</link>
</document>xlink:show exhibits behavior identical to that of target="_blank". It also takes the form of an un‐deprecated attribute. I wonder if this was an oversight, a conflict, or if the target attribute was deprecated for other reasons (such as usability).


It's still simply using a backdoor approach to adding often invalid markup or stylesheets to a valid document in a way which the validator won't notice.Subscribing to your view, I guess it all depends on how one uses it. I tend to use it to insert proprietary, yet valid, content crafted in a way such that Internet Explorer will handle it as desired. My main purpose for their use is not validity, but to avoid code conflicts.

With regard to the use of proprietary CSS properties and the W3C CSS validator, there really isn’t any such thing as CSS validity. There’s only technical well‐formedness and conformance. For example, the zoom property is non‐conformant on Microsoft’s part because it exhibits no vendor prefix; its name and values are well‐formed though, so you can use it freely from a technical standpoint.


I can be as evangelical as the next standardista, but idealism is sometimes going to play second fiddle to pragmatism.Of course.

Insertion of the target attribute via the DOM to meet the perceived intent of the W3C seems a bit more like a concession to idealism than pragmatism though. I guess that we disagree upon what is ideal as well.

whizard
06-30-2007, 01:26 AM
I think there is definitely a place for popup windows -- remember not every popup window is an external website.

A very appropriate instance of a popup window would be a rate calculator, a calendar, or directions

Dan

Arbitrator
06-30-2007, 02:31 AM
A very appropriate instance of a popup window would be a rate calculator, a calendar, or directionsI’m not sure why any of those cannot be put inline or what detrimental effects would be caused if they did. Perhaps you can enlighten me?

felgall
06-30-2007, 02:47 AM
Much easier to do most of those in the page itself as an overlay.

whizard
06-30-2007, 03:11 AM
They can be put inline or as an overlay, but my point is that there should be a way to do it with a popup as well. There is nothing bad about the popup method in this case, assuming it meets standards.

Dan

Arbitrator
06-30-2007, 04:09 AM
They can be put inline or as an overlay, but my point is that there should be a way to do it with a popup as well. There is nothing bad about the popup method in this case, assuming it meets standards.Opening a new window tends to be bad for several reasons.

It requires management of another window (or tab).
Authors tend to do it for reasons that are unnecessary.
Authors will, generally, provide no means to disable the functionality.
Many authors do not indicate that such functionality is present.
There are technical issues already discussed throughout this thread.

If you were going to argue in favor of new windows, the best use case would probably be during the streaming of continuous media such as games, chat rooms, music, or video. I can’t think of any situations were it would be strictly necessary though.

felgall
06-30-2007, 05:26 AM
You left out that browser owners can completely disable opening in a new window and force all pages to open in a new tab or even the same tab instead.

Bill Posters
06-30-2007, 09:48 AM
Opening a new window tends to be bad for several reasons.
It requires management of another window (or tab).
Given that even IE7, the browser for the unthinking masses, has finally acknowledged the wisdom of tabbed browsing - not to mention that multi-windowed browsing has been around for many, many years -, I'm not so sure this is such the stumbling block that many consider it to be.


Authors tend to do it for reasons that are unnecessary.
Authors will, generally, provide no means to disable the functionality.
Many authors do not indicate that such functionality is present.
Nielsen would be proud.

Same old argument as used on Flash.
Flash is often implemented badly, ergo Flash is bad.

Censuring a technique which can be implemented considerately because many, possibly even most, implement it inconsiderately is a weakly founded argument which I thought the web community had learned to look beyond of a while back.

Heck, should we condemn markup on the grounds that some authors out there are publishing sites which are so far removed from being valid, semantic or even well-formed that they remain only barely usable?


There are technical issues already discussed throughout this thread.
Few, if any, of which are cause for real concern outside the realm of the most devout standardistas.



You left out that browser owners can completely disable opening in a new window and force all pages to open in a new tab or even the same tab instead.
Users can completely disable stylesheets. It's extremely likely that some do.
So, does that mean we should not bother adding CSS to our sites?


Everything has its limitations. So long as we try to implement our sites considerately and with our eyes open, then we shouldn't recoil from trying simply because not everything we do is going to please every user.
The best we can aim to do is to optimise for our target audience*, but do so in a way which doesn't present significant obstacles to those outside our target audience.




* the notion of a 'target audience' seems increasingly to be seen as somehow old-fashioned, a forgotten people, due to the well-meaning, but possibly misplaced notion that we should be trying to make our sites all things to all people.
Imo, that's a shame.

Hmmm. Might be time to start me a blog. ;)

Bill Posters
06-30-2007, 10:33 AM
Fwiw…

It's only recently occured to me that, in cases where we are providing some form of visual or image-based pre-notification that a links opens in a new window, the likelihood that users will middle-click/ctrl+click/cmd+click on the link is significantly reduced - possibly.
If this can safely assumed to be the case, the problem which I'd identified with window.open (the double window problem) is, in turn, significantly less likely to occur.

So, I'm now debating with myself whether it's time to ditch the target-oriented, js-based solution, which I use and endorse in my own scripted toggler method, in favour of the window.open method.

I think I might be able to convince myself that it's OK to switch to window.open. Of course, it would certainly settle the niggle it gives me over the reintroduction of an invalid attribute.

By coincidence, I've been rejigging the script for the sake of some long-overdue optimisations and some minor rethinks on certain aspects. So, now seems as good a time as any to switch it to window.open instead.


Hmmm. :strokes-chin:

felgall
06-30-2007, 10:57 PM
The target attribute was deprecated in favour of using window.open() since JavaScript is supposed to be the way that you define behaviour and opening a new window is a behaviour.

That not everyone will see the page open in a new window either because they have JavaScript disabled or have configured their browser to work differently is irrelevant since everything about a web page except the content itself are purely recommendations that may or may not be overridden by individual visitors. The problem only comes if you rely on the stylesheet or JavaScript in order for your page to be functional in which case in many instances it will not be.

Too many people expect to be able to place things in their web page that affect things outside of their page. As more security holes are uncovered and plugged we can expect browsers to put more and more restrictions on web page access to anything outside of the current page and so designing things to work within the page rather than opening new windows and such is more likely to continue to work as expected in the future.

Bill Posters
07-01-2007, 07:13 AM
Much of what you say is stuff that I'm aware of, agree with and which already forms the basis of my own position on how best to implement new windows.
You and I (and Arbitrator) are largely on the same page.
However, I don't think we'll see an end to multiple-paned browsing any time soon, particularly if the HTML5 model plays a role in the future of web development, specifically regarding its un-deprecating of the target attribute.

- - -

In my previous post, I mentioned that I'd possibly be tweaking my custom, new windows methodology to use window.open instead of setting the target attribute value.
Given that this now means adding and removing events, I must say that honouring completely the validity of the DOM makes the task considerably more difficult than is the case when using js to set/unset target attributes.

I've so far been unable to nail the addEvent() and removeEvent() approach needed to reliably switch to a window.open approach.

felgall
07-01-2007, 08:58 AM
If you are going to use deprecated attributes like target then use a transitional doctype where such things are valid. Adding it after validation invalidates the validation.

If you are going to use strict then the command to open a new window is window.open()

Bill Posters
07-01-2007, 09:27 AM
If you are going to use deprecated attributes like target then use a transitional doctype where such things are valid. Adding it after validation invalidates the validation.

If you are going to use strict then the command to open a new window is window.open()
:sigh:

If using window.open was problem-free, I wouldn't think twice.
Unfortunately, that's the not the case.
So, it becomes a judgement call, rather than the b/w case you seem to view it as.

Please take the time to read the points that have already been made rather than patronisingly restating the same party line over and over.

Arbitrator
07-01-2007, 02:48 PM
This reply was more verbose to start with, but after my browser crashed and then the power went out, I decided to go for something more brief as my third attempt. I’m tired at this point, so it’s more likely that there are errors.


Given that even IE7, the browser for the unthinking masses, has finally acknowledged the wisdom of tabbed browsing - not to mention that multi-windowed browsing has been around for many, many years -, I'm not so sure this is such the stumbling block that many consider it to be.I wasn’t aware that Internet Explorer opened new windows into new tabs. The problem with being able to open hyperlink destinations in the current window or tab remains, however.

I stumbled upon some helpful functionality while looking into this issue. Internet Explorer 7 and Opera 9 both allow one to right-click a hyperlink and select “Open” from a shortcut menu to override behavior that would otherwise trigger a new window or tab to open. Firefox requires that one navigate to the URI about:config and change the preferences browser.link.open_newwindow and browser.link.open_newwindow.restriction and set their values to 1 and 0, respectively; these settings will permanently disable the functionality of the target attribute and window.open() method. Alternatively, Firefox can disable target while allowing window.open() to remain fully or conditionally functional.

Drawbacks of the Internet Explorer and Opera functionality include requiring that hyperlinks that open new windows or tabs be clearly marked and that this technique must be used each time one wants to open the destination in the current tab or window; opening a menu is notably more tedious than middle-clicking. Drawbacks of the Firefox functionality is that it is tedious to toggle on and off, the switch is in a hidden location, and that online documentation (http://kb.mozillazine.org/Browser.link.open_newwindow.restriction) is required to understand what the preferences and their values do.


Nielsen would be proud.
Your sarcasm is noted.


Same old argument as used on Flash.
Flash is often implemented badly, ergo Flash is bad.I would rephrase that to say, “Flash is often implemented badly and, thus, Flash is often bad.” The comparison is poor, however, since Flash has numerous other issues, aside from validity and being annoying, including lost browser functionality, increased download times, management of a plug-in, and, I would guess, basic accessibility issues such as access to visually-impaired users and those without a pointing device. To get around all of them, you would probably have to build an equivalent HTML page. Of course, if you want to build and maintain two documents for the same content, I guess that’s up to the author.

From the author side, issues include increased bandwidth usage, necessary knowledge of the proprietary ActionScript, and the purchase of expensive software. Perhaps all of these are easily solved though. I haven’t done much research.


Censuring a technique which can be implemented considerately because many, possibly even most, implement it inconsiderately is a weakly founded argument which I thought the web community had learned to look beyond of a while back.How often something is likely to be misused is something worth consideration nevertheless.

You do have a point, however. The alternative is to teach others how to avoid those pitfalls. A problem is that the explanation would be rather verbose; perhaps I should write an article that I can refer to. Another issue is that I generally consider the relevant functionality superfluous, so I don’t have as much incentive to explain how to use it when I generally disagree with its use in the first place.


Heck, should we condemn markup on the grounds that some authors out there are publishing sites which are so far removed from being valid, semantic or even well-formed that they remain only barely usable?


Users can completely disable stylesheets. It's extremely likely that some do.
So, does that mean we should not bother adding CSS to our sites?Rhetorical questions make weak arguments, if any at all. You should make and prove assertions instead.


Everything has its limitations. So long as we try to implement our sites considerately and with our eyes open, then we shouldn't recoil from trying simply because not everything we do is going to please every user.I agree. I think that a significant dividing issue is that we disagree over what “considerate” is.


The best we can aim to do is to optimise for our target audience*, but do so in a way which doesn't present significant obstacles to those outside our target audience.If your point is that your target audience is too ignorant or inept to open a new window or tab via built-in browser functionality, then I would say that you would be doing them a greater service by educating them instead. I agree with the general sentiment though.


* the notion of a 'target audience' seems increasingly to be seen as somehow old-fashioned, a forgotten people, due to the well-meaning, but possibly misplaced notion that we should be trying to make our sites all things to all people.
Imo, that's a shame.I don’t see a movement toward universal access as shameful.


It's only recently occured to me that, in cases where we are providing some form of visual or image-based pre-notification that a links opens in a new window, the likelihood that users will middle-click/ctrl+click/cmd+click on the link is significantly reduced - possibly.
If this can safely assumed to be the case, the problem which I'd identified with window.open (the double window problem) is, in turn, significantly less likely to occur.

So, I'm now debating with myself whether it's time to ditch the target-oriented, js-based solution, which I use and endorse in my own scripted toggler method, in favour of the window.open method.

I think I might be able to convince myself that it's OK to switch to window.open. Of course, it would certainly settle the niggle it gives me over the reintroduction of an invalid attribute.


If using window.open was problem-free, I wouldn't think twice.
Unfortunately, that's the not the case.
So, it becomes a judgement call, rather than the b/w case you seem to view it as.May I ask under what conditions this issue is occurring? Middle-clicking a hyperlink with window.open() functionality seems to serve a single window or tab in Firefox 2 and Internet Explorer 7.


By coincidence, I've been rejigging the script for the sake of some long-overdue optimisations and some minor rethinks on certain aspects. So, now seems as good a time as any to switch it to window.open instead.


In my previous post, I mentioned that I'd possibly be tweaking my custom, new windows methodology to use window.open instead of setting the target attribute value.
Given that this now means adding and removing events, I must say that honouring completely the validity of the DOM makes the task considerably more difficult than is the case when using js to set/unset target attributes.

I've so far been unable to nail the addEvent() and removeEvent() approach needed to reliably switch to a window.open approach.My attempt to duplicate this functionality as unobstrusively as possible is shown below. You can also view a live version (http://www.jsgp.us/demos/D0006.html). The demo seems to work fine in Firefox 2, Internet Explorer 7, and Opera 9. Safari 3 showed an error message in place of the document; hopefully, this is just an issue in the beta build.

The code below is for archival purposes. I’m not going to upload the images; they have text fall-backs anyway.


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

<html lang="en-Latn-US">
<head>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="Content-Script-Type" content="application/ecmascript">
<base href="http://www.jsgp.us/demos/">
<title>Demo D0006</title>
<meta name="Author" content="Patrick Garies">
<meta name="Created" content="2007-06-30">
<meta name="Revised" content="2007-07-01">
<style type="text/css" media="all">
* { margin: 0; padding: 0; }
html { background: #f7f7ee; color: black; font: 16px/1.2 sans-serif; }
body { background: url("window_new.gif") -16px -16px no-repeat; /* This preloads an image. */ }
p { margin: 1em; }
p + p { border-bottom: 1px solid #ccc; padding-bottom: 1em; }
p + p + p { border: none; padding: 0; }
a { color: blue; text-decoration: none; }
a:visited { color: purple; }
a:hover { color: black; text-decoration: underline; }
a:hover span { color: blue; }
a:visited:hover span { color: purple; }
code { color: green; }
.special + img { color: blue; vertical-align: middle; cursor: pointer; }
</style>
<style type="text/css" media="print">
.special + img { display: none; } /* Oddly, it doesn’t work. */
</style>
<script type="application/ecmascript">
// Is this text obvious and accessible enough? Or is it too verbose?
// I don’t know how visually impaired persons handle click events or new windows.
var current = "(view in current window)";
var neo = "(view in new window)"; // “new” is a reserved keyword, hence “neo”.
document.defaultView.addEventListener("load", function () {
if (window.open) {
var anchors = document.getElementsByTagName("a");
for (var i = 0; i < anchors.length; i++) {
// Mechanism A
if (anchors[i].getAttribute("class").match(/(^| )special( |$)/)) {
var toggle = document.createElement("img");
toggle.setAttribute("alt", current);
toggle.setAttribute("width", "16");
toggle.setAttribute("height", "16");
toggle.setAttribute("src", "window_current.gif");
toggle.addEventListener("click", function () {
var anchor = this.previousSibling.previousSibling;
if (this.getAttribute("alt") == current) {
anchor.addEventListener("click", function (event) {
event.preventDefault();
window.open(this.getAttribute("href"), "_blank");
}, false);
this.setAttribute("alt", neo);
this.setAttribute("src", "window_new.gif");
}
else {
var clone = anchor.cloneNode(true); // Events are not cloned; this removes the event.
anchor.parentNode.replaceChild(clone, anchor);
this.setAttribute("alt", current);
this.setAttribute("src", "window_current.gif");
}
}, false);
anchors[i].parentNode.insertBefore(toggle, anchors[i].nextSibling);
anchors[i].parentNode.insertBefore(document.createTextNode("\u00a0"), anchors[i].nextSibling);
}
// Mechanism B
if (anchors[i].getAttribute("class").match(/(^| )special2( |$)/)) {
var clone = anchors[i].cloneNode(true);
clone.firstChild.firstChild.data = "new\u00a0window";
clone.addEventListener("click", function (event) {
event.preventDefault();
window.open(this.getAttribute("href"), "_blank");
}, false);
anchors[i].parentNode.insertBefore(document.createTextNode(")"), anchors[i].nextSibling);
anchors[i].parentNode.insertBefore(clone, anchors[i].nextSibling);
anchors[i].parentNode.insertBefore(document.createTextNode("\u00a0("), anchors[i].nextSibling);
i++; // This is needed to prevent an infinite loop from occurring.
}
}
}
}, false);
</script>
<!--[if IE]>
<script type="text/javascript">
// Is this text obvious and accessible enough? Or is it too verbose?
// I don’t know how visually impaired persons handle click events or new windows.
var current = "(view in current window)";
var neo = "(view in new window)"; // “new” is a reserved keyword, hence “neo”.
window.onload = function () {
var anchors = document.getElementsByTagName("a");
for (var i = 0; i < anchors.length; i++) {
// Mechanism A
if (anchors[i].className.match(/(^| )special( |$)/)) {
var toggle = document.createElement("img");
toggle.setAttribute("alt", current);
toggle.setAttribute("width", "16");
toggle.setAttribute("height", "16");
toggle.setAttribute("src", "window_current.gif");
toggle.onclick = function () {
var anchor = this.previousSibling.previousSibling;
if (this.getAttribute("alt") == current) {
anchor.onclick = function () {
window.event.returnValue = false;
window.open(this.getAttribute("href"), "_blank");
};
this.setAttribute("alt", neo);
this.setAttribute("src", "window_new.gif");
}
else {
var clone = anchor.cloneNode(true); // Events are not cloned; this removes the event.
anchor.parentNode.replaceChild(clone, anchor);
this.setAttribute("alt", current);
this.setAttribute("src", "window_current.gif");
}
};
anchors[i].parentNode.insertBefore(toggle, anchors[i].nextSibling);
anchors[i].parentNode.insertBefore(document.createTextNode("\u00a0"), anchors[i].nextSibling);
}
// Mechanism B
if (anchors[i].className.match(/(^| )special2( |$)/)) {
var clone = anchors[i].cloneNode(true);
clone.firstChild.firstChild.data = "new\u00a0window";
clone.onclick = function () {
window.event.returnValue = false;
window.open(this.getAttribute("href"), "_blank");
};
anchors[i].parentNode.insertBefore(document.createTextNode(")"), anchors[i].nextSibling);
anchors[i].parentNode.insertBefore(clone, anchors[i].nextSibling);
anchors[i].parentNode.insertBefore(document.createTextNode("\u00a0("), anchors[i].nextSibling);
i++; // This is needed to prevent an infinite loop from occurring.
}
}
};
</script>
<![endif]-->

</head>
<body>

<p>A hyperlink placed in this paragraph will direct you to <a class="special" href="/demos/"><span>http://www.jsgp.us/demos/</span></a> when activated. For testing purposes, I have chosen to have it open via <code>window.open()</code>. In consideration of users, an option has been added that allows one to disable the <code>window.open()</code> functionality. The hyperlink destination opens in the current window by default.</p>
<p>This paragraph contains filler content, added for testing purposes. It ensures that multiple such hyperlinks can coexist without issues. It looks like <a class="special" href="http://edition.cnn.com/"><span>http://edition.cnn.com/</span></a> has a new look. <a class="special" href="http://www.codingforums.com/"><span>http://www.codingforums.com/</span></a> and <a class="special" href="http://www.slashdot.org/"><span>http://www.slashdot.org/</span></a> are green, as usual.</p>
<p>I think that it would be simpler to have a brief tooltip or other mechanism explain how to open a new window though. The user would learn something that would be useful on other sites instead of only how to work a script proprietary to one site.</p>
<p>For the sake of example, here is another mechanism that doesn’t require a toggle and provides the usual one-click gratification: <a class="special2" href="http://www.ie7.com/"><span>http://www.ie7.com/</span></a>. An image could be used here too, but that’s more likely to cause confusion since the user may think that that means that the initial hyperlink opens in a new window.</p>

</body>
</html>

Bill Posters
07-01-2007, 08:54 PM
Firstly, thanks for taking the time to put together a lengthy response (twice over). :)


I wasn’t aware that Internet Explorer opened new windows into new tabs. The problem with being able to open hyperlink destinations in the current window or tab remains, however.
I didn't mean to suggest that IE offers users the ability to route new, site-created windows into tabs instead. I'm not an IE/Win user, so can't say whether that feature exists or not.
The point I was making was simply that multi-paned browsing is not such an obstacle that it once might have been.
GUI browsers have been able to create multiple windows for many years and now it seems that the most widely used browser has finally cottoned on to the wisdom of tabbed browsing.
This demonstrates that there is significant interest amongst users in browsing outside of the single-window/single-session model.


I would rephrase that to say, “Flash is often implemented badly and, thus, Flash is often bad.”
Even so, it's not the fault of the technology that it's often used badly.


The comparison is poor, however, since Flash has numerous other issues, aside from validity and being annoying, including lost browser functionality, increased download times, management of a plug-in, and, I would guess, basic accessibility issues such as access to visually-impaired users and those without a pointing device. To get around all of them, you would probably have to build an equivalent HTML page. Of course, if you want to build and maintain two documents for the same content, I guess that’s up to the author.
Fwiw, I was limiting my notion of Flash=bad to those issues which predate the questions arising from accessibility (or lack thereof).
e.g. Flash is bad because Flash = huge download times (during pre-broadband era).

Failing that, take the HTML comparison.
It is surely mangled more often than not, but that does not make HTML itself bad.


How often something is likely to be misused is something worth consideration nevertheless.
Then, as I say, HTML is no better as it's likely that it's being 'misused' far more often than it's being used well.



Users can completely disable stylesheets. It's extremely likely that some do.
So, does that mean we should not bother adding CSS to our sites?
Rhetorical questions make weak arguments, if any at all. You should make and prove assertions instead.
The fact that the question is purely rhetorical (and the fact that you recognise that) serves to suggest how questionable the 'people can disable it, so we should avoid it' argument really is.
(Bear in mind that the 'rhetorical question' was in response to a remark by Felgall, rather than yourself.)



Everything has its limitations. So long as we try to implement our sites considerately and with our eyes open, then we shouldn't recoil from trying simply because not everything we do is going to please every user.
I agree. I think that a significant dividing issue is that we disagree over what “considerate” is.
If it comes down to it, I think we're both likely to put practical usability before validity.
On that count, I think we're more alike than you might think.


I don’t see a movement toward universal access as shameful.
If it comes at the cost of diluting the message for our target audiences, then I personally have reservations and think that it's something which needs further consideration (and discussion).

No-one here is trying to make the web inaccessible. They're simply reserving the right to implement techniques which they feel make a better connection between the site and the target audience.
As said, it's possible to do it according to progressive enhancement/graceful degredation, so no-one's getting turfed out.



May I ask under what conditions this issue is occurring? Middle-clicking a hyperlink with window.open() functionality seems to serve a single window or tab in Firefox 2 and Internet Explorer 7.
e.g.
http://test.newplasticarts.co.uk/dom-js/double-window-test/

FF/Mac, FF/Win & Safari/Mac…
cmd-clicking (ctrl-clicking in Windows) on a link targets a new window/tab.
Performing that action on a _blank targeted link brings up that window in a new window/tab.
cmd-clicking on a link which has window.open attached brings up two instances of the destination url ('double windows'.)

I'm not sure how Safari3/Mac or Win behaves.

In all instances, as you say, middle-clicking does appear to invoke only one instance of the window in both _blank and window.open scenarios.
However, so long as the issue with the cmd-click/ctrl-click exists, and so long as cmd-click/ctrl-click is potentially used by a significant number of those seeking to create new windows/tabs, the 'double window' issue is still a concern to me.

As a method for creating new windows, it possibly predates middle-clicking (certainly on Macs) and is likely to be more popular than targeting new windows/tabs via the contextual menu.




A usability study on how users interact with each of their mouse buttons and keyboard modifier keys and how the various approaches break down into %s.




My attempt to duplicate this functionality as unobstrusively as possible is shown below…
I understand the logic behind your approach, but as a solution, I'm not a big fan of providing a secondary new window link for every external link.
There's nowt wrong with it per se, it's just a different approach - and not the one which I most prefer.

The technique within which I'm seeking to swap target for window.open is a toggler, so I'll be needing to add the onclick events and remove them, cleanly and in a way which doesn't interfere with any existing onclick events which an obj might already have.

Adding is the lesser part of the problem, but I'm having significant trouble nailing the syntax for removing them cleanly.


Fwiw, this is the current state, though I'm working on some updates and modifications offline.
http://test.newplasticarts.co.uk/dom-js/flag-offsite-links/

Moving away from target to window.open entails switching from using the target property to using addEvent and removeEvent.

In my update tests, I've so far been unable to nail down their integration into the toggler procedure, bearing in mind that I need to pass in the anchor's href as an argument.


I'll possibly post a new thread asking for help and advice, if I'm unable to make a breakthrough next time I dive back into it.
Getting too deep into it here could turn an already complex thread into a real quagmire. ;)

felgall
07-01-2007, 09:03 PM
Please take the time to read the points that have already been made rather than patronisingly restating the same party line over and over.

Well you can either use valid code or invalid code - the choice is yours. There haven't been any points raised in this thread that change anything regarding what is and isn't valid.

kewlceo
07-01-2007, 09:56 PM
Well you can either use valid code or invalid code - the choice is yours. There haven't been any points raised in this thread that change anything regarding what is and isn't valid.

Yes, that is the bottom line. If having 100% valid code is paramount over the possibility of losing a potential client, then go for it. :D

Bill Posters
07-02-2007, 09:17 AM
Well you can either use valid code or invalid code - the choice is yours. There haven't been any points raised in this thread that change anything regarding what is and isn't valid.

No-one has sought to claim that invalid = valid.
The question isn't about what's valid and what's not valid. As kewlceo acknowledges, it's about what's more important - validity or, in this case, usability?
(As the situation in question demonstrates, the two don't always point to the same solution.)

Code validity is not the entire point, it's a means to an end.
Don't get me wrong, it's one which I wholly understand and appreciate.
The question the situation raises is if an outcome can be served by using either a technique which makes the code invalid in a minor way or by using a 100% valid technique which has some usability issues, which is the better approach to take?
Or to look at it from another perspective - which is worse, a minor invalidation or a potential usability problem?
In real terms, which approach is likely to have fewer casualties? (…and how does the spread correlate to overall audience and target audience?)

I am personally doubtful that a single UA would present problems on account of the use of a target attribute within a Strict doctype. (Even in XML render mode, XML-compliant UAs aren't going to balk at a target attribute in a Strict doctype.)
By contrast, using window.open has already been demonstrated to be slightly problematic when it comes into contact with certain, reasonably common, user techniques.
(It's my guestimation that more people are likely to use modified-clicks to target new windows/tabs than to be using a UA which chokes on the presence of a target attribute within a Strict doctype.)


As firmly as I believe that we should all be aiming to achieve valid code, I am ready to acknowledge that it's not the only thing - or even the most important thing - that we need to consider when we put our sites together; hence the dilemma.

Fwiw, I would only consider opting for invalid code if, in my view, a greater benefit could be had at minimal cost. Just to be clear, when talking of invalid code, I'm talking about the odd invalid attribute, such as target or placeholder, rather than something more substantial such as invalid elements or even malformedness.

Of course, for any project requiring P2+/AA+ accessibility compliance, invalid attributes are a no-no. I'm adherent enough to recognise that the accessibility demands of some projects will most often outweigh the benefits of any technique which relies on the use of invalid attributes. (I would be extremely reluctant to resort to using a Transitional doctype for reasons I've already outlined.)

As said, it's about recognising what's more important.

Arbitrator
07-07-2007, 03:26 PM
It took me awhile to get to this…


Safari 3 showed an error message in place of the document; hopefully, this is just an issue in the beta build.As a follow up, it seems that this is the case. My code works fine in Safari 3.0.2 (beta). Previously, I had tested under version 3.0.1 (beta).


I didn't mean to suggest that IE offers users the ability to route new, site-created windows into tabs instead. I'm not an IE/Win user, so can't say whether that feature exists or not.The feature exists and seems to be the default behavior of Internet Explorer 7; hyperlinks with a target="_blank" attribute or window.open() method specified will both open in a new tab.


The point I was making was simply that multi-paned browsing is not such an obstacle that it once might have been.I’m not sure what you mean by “multi‐paned”. In Windows, a multi‐paned window is a single window that’s divided up into sub‐windows.


GUI browsers have been able to create multiple windows for many years and now it seems that the most widely used browser has finally cottoned on to the wisdom of tabbed browsing.
This demonstrates that there is significant interest amongst users in browsing outside of the single-window/single-session model.It’s a given that users, in general, want easy‐to‐manage multiple sessions. They do not necessarily want multiple windows (hence tabs instead) nor the Web site author to be the one that invokes them.


Even so, it's not the fault of the technology that it's often used badly.Depending upon the issue, you’re both correct and incorrect. Some issues are inherent to the technology.


Fwiw, I was limiting my notion of Flash=bad to those issues which predate the questions arising from accessibility (or lack thereof).
e.g. Flash is bad because Flash = huge download times (during pre-broadband era).Noted. We’re not exactly past the dial‐up era though.


If it comes at the cost of diluting the message for our target audiences, then I personally have reservations and think that it's something which needs further consideration (and discussion).I don’t see how any message would be “dilut[ed]”.


e.g.
http://test.newplasticarts.co.uk/dom-js/double-window-test/

FF/Mac, FF/Win & Safari/Mac…
cmd-clicking (ctrl-clicking in Windows) on a link targets a new window/tab.
Performing that action on a _blank targeted link brings up that window in a new window/tab.
cmd-clicking on a link which has window.open attached brings up two instances of the destination url ('double windows'.)

I'm not sure how Safari3/Mac or Win behaves.

In all instances, as you say, middle-clicking does appear to invoke only one instance of the window in both _blank and window.open scenarios.
However, so long as the issue with the cmd-click/ctrl-click exists, and so long as cmd-click/ctrl-click is potentially used by a significant number of those seeking to create new windows/tabs, the 'double window' issue is still a concern to me.I see the keyboard issue in Firefox 2. I see it in neither Internet Explorer 7 nor Safari 3 (beta).

It seems that the Firefox issue is Bug 151142 (https://bugzilla.mozilla.org/show_bug.cgi?id=151142). I added that bug to my list of votes.


As a method for creating new windows, it possibly predates middle-clicking (certainly on Macs) and is likely to be more popular than targeting new windows/tabs via the contextual menu.Assuming that the user knows that the link opens in a new window, it would seem to be redundant and unnecessary for them to use modifier keys, making this less of an issue. Assuming your check box functionality and that the default is for hyperlinks to activate normally (i.e., in the same window or tab), the user could simply avoid checking the box and this would be a non‐issue.


I understand the logic behind your approach, but as a solution, I'm not a big fan of providing a secondary new window link for every external link.
There's nowt wrong with it per se, it's just a different approach - and not the one which I most prefer.

The technique within which I'm seeking to swap target for window.open is a toggler, so I'll be needing to add the onclick events and remove them, cleanly and in a way which doesn't interfere with any existing onclick events which an obj might already have.Assuming that I would want to offer this functionality, what I dislike about your current approach is that the check box is likely to only be present once. This means that, if all of the hyperlinks are not grouped in a single location, then one has to scroll to get at the functionality and then scroll back to activate the hyperlink. If one wants to use toggle this functionality, the inconvenience multiplies. And this is not even considering that the user may not notice or forget that the functionality is there at all if not placed in the vicinity of all hyperlink groups. Considering the inconvenience, I would think that that would make it that much less likely to be used and, thus, lessen its utility.

Alternatively, one could repeat the check box in various regions of a page such that it exists around all hyperlink groups, but I would guess that authors would not be willing to do so due to aesthetic concerns.

By the way, I experienced a weird bug, at one point, where there were two copies of the check box and its respective text in Firefox. I couldn’t reproduce it though.


Adding is the lesser part of the problem, but I'm having significant trouble nailing the syntax for removing them cleanly.Look at my demo (http://www.jsgp.us/demos/D0006.html). It shows you how to do this using both the W3C and “traditional” methods.

Later: I updated my demo so that it uses the Microsoft method instead of the traditional method.


Moving away from target to window.open entails switching from using the target property to using addEvent and removeEvent.I don’t know what “addEvent” and “removeEvent” are. If they involve Microsoft’s attachEvent() and detachEvent() methods, know that I tried that approach and scrapped it since the this keyword is broken under that event model.

Later: I fixed this issue. My demo now uses attachEvent(). It seems that you cannot use cloneNode() to remove an event under the Microsoft event model; thus, I used outerHTML as an alternative.


I am personally doubtful that a single UA would present problems on account of the use of a target attribute within a Strict doctype.I’m also doubtful. In theory though, HTML 4.01’s error‐handling is mostly undefined, so it’s possible that a conforming UA could choose to ignore the attribute should it appear with the wrong public identifier present.


(Even in XML render mode, XML-compliant UAs aren't going to balk at a target attribute in a Strict doctype.)On the other hand, assuming that the UA isn’t a validating parser, I would think that it would be incorrect for the attribute to be ignored in XML due to the presence of namespaces (even if the document is invalid).

Bill Posters
07-07-2007, 05:41 PM
I’m not sure what you mean by “multi‐paned”. In Windows, a multi‐paned window is a single window that’s divided up into sub‐windows.
By multi-paned, I simply mean single-window UA - i.e. not something which supports new windows or new tabs.


It’s a given that users, in general, want easy‐to‐manage multiple sessions. They do not necessarily want multiple windows (hence tabs instead) nor the Web site author to be the one that invokes them.
Not quite as much of a given as some assert. It's really particularly unusual, in discussions on this topic, to have some chime in stating that they both expect and prefer sites to open external links in a new window/tab.


Depending upon the issue, you’re both correct and incorrect. Some issues are inherent to the technology.
Indeed, but I don't think that js qualifies is one which is inherently bad in some ways.


I don’t see how any message would be “dilut[ed]”.
Circumstances differ from site to site and I like to keep an open mind. I don't have confidence in any 'one rule for all sites' mindsets.

It's the lack of 'one rule which works for all' in this situation that led me to the toggler as a fair compromise between the desires of some authors/owners and users.


It seems that the Firefox issue is Bug 151142 (https://bugzilla.mozilla.org/show_bug.cgi?id=151142).
It's certainly good to see that this particular wrinkle is on the to-do list, but until it is addressed, it's an active issue.


Assuming that the user knows that the link opens in a new window, it would seem to be redundant and unnecessary for them to use modifier keys, making this less of an issue.
…as I already noted earlier (http://www.codingforums.com/showpost.php?p=582868&postcount=26).


Assuming that I would want to offer this functionality, what I dislike about your current approach is that the check box is likely to only be present once. This means that, if all of the hyperlinks are not grouped in a single location, then one has to scroll to get at the functionality and then scroll back to activate the hyperlink.

I don't see this as a particular problem.
Accessibility tools and other style-switchers are typically only presented once per page. Afaik, it's never been considered a 'problem' in need of a fix.

If a user is likely to use the toggler as the only means of opening individual links in a new window or not, toggling it on and off according to how they wish each individual external link to behave, it's likely that they'll be somewhat better informed and more capable of opening links according to their own preferences (leaving the toggler off).
(Bear in mind that the first use of an external link with the toggler set to off is going to take them away from the site and consequently away from the toggler.)

The toggler is there to provide a user-switchable, all-on or all-off setup. It's unlikely that users will use it in the way which you describe.



By the way, I experienced a weird bug, at one point, where there were two copies of the check box and its respective text in Firefox. I couldn’t reproduce it though.
I've never encountered such an issue. It's possible that I was in the middle of fiddling with the page at the very moment you checked, causing your UA to receive an incomplete or otherwise malformed copy.


Look at my demo (http://www.jsgp.us/demos/D0006.html). It shows you how to do this using both the W3C and “traditional” methods.
As mentioned, I'm not particularly a fan of that approach, not least because it doubles up every link, something which is potentially problematic for keyboard users and screen-reader users, both of whom will have twice as many links to tab/listen through.
I also think that it presents extra screen clutter, even for those users who would choose to have external links open in the current window/tab.

Regarding the problem I was having with using removeEvent in my own trials…
A fresh set of eyes the next morning helped me to spot the issue. It now works as intended using the custom removeEvent.

(I'll be sorting a revised introduction page to sit alongside my current 'tutorial' page.)


I don’t know what “addEvent” and “removeEvent” are. If they involve Microsoft’s attachEvent() and detachEvent() methods, know that I tried that approach and scrapped it since the this keyword is broken under that event model.
There exist a number of custom functions devised to provide x-browser means to add and remove events, including accurate support for the this keyword.
The one I use is a slight tweak of one produced by John Resig (http://ejohn.org/projects/flexible-javascript-events/), which passes the event target silently to the function being added, making access to the event target possible using the this keyword.

It all stems from PPK's 'addEvent recoding contest' (http://www.quirksmode.org/blog/archives/2005/10/_and_the_winner_1.html) a year or two back.


I’m also doubtful. In theory though, HTML 4.01’s error‐handling is mostly undefined, so it’s possible that a conforming UA could choose to ignore the attribute should it appear with the wrong public identifier present.
I have no doubts whatsoever that any HTML-compatible UA which has already reached release status has had and will continue to have far worse code crimes to deal with than an invalid attribute.
If a particular UA's error-handling were to be so inflexible as to balk on a target attribute which shouldn't be there, it's likely to be unusable on so many other counts.


On the other hand, assuming that the UA isn’t a validating parser, I would think that it would be incorrect for the attribute to be ignored in XML due to the presence of namespaces (even if the document is invalid).
I also assume that to be the case, particularly as the scripted readdition of the target attribute, as used in my (original) method appears to trigger new windows in both HTML mode and XML mode under a Strict doctype.

Arbitrator
07-07-2007, 07:39 PM
As mentioned, I'm not particularly a fan of that approach, not least because it doubles up every link, something which is potentially problematic for keyboard users and screen-reader users, both of whom will have twice as many links to tab/listen through.
I also think that it presents extra screen clutter, even for those users who would choose to have external links open in the current window/tab.I meant that you should look at the methods used to attach and remove event listeners in building the code for your existing technique. I guess that’s not relevant now though, since you seem to have solved the problem.


There exist a number of custom functions devised to provide x-browser means to add and remove events, including accurate support for the this keyword.
The one I use is a slight tweak of one produced by John Resig (http://ejohn.org/projects/flexible-javascript-events/), which passes the event target silently to the function being added, making access to the event target possible using the this keyword.

It all stems from PPK's 'addEvent recoding contest' (http://www.quirksmode.org/blog/archives/2005/10/_and_the_winner_1.html) a year or two back.I took a look at that technique and, unfortunately, I don’t understand how it restores the this keyword. I guess that my understanding of objects is too weak. For the time being, I’ll stick with my method.



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum