target="_blank" without validation errors.

[tech_support]

How would I use target="_blank" without getting a validation error without switching DOCTYPE?

[GhettoT]

How do you get a validation error? What doctype are you using?

[codeexploiter]

I think he is using strict DTD and it will fail the validation if you use TARGET attribute.

I think you better have a look at this article (http://accessify.com/features/tutorials/new-windows/) which deals with this problem.

or

You can go for a JavaScript based solution (fail in certain machines where it is turned off).

[mburt]

A think a loose DTD (with target="_blank") is better than a JavaScript window open.

[Twey]

The hint behind removing the "target" attribute is that you shouldn't be opening windows :)

If you really want to open a window, Javascript is quite sufficient, since the content of popups shouldn't be vital anyway.

[djr33]

Opening windows is very useful in many situations. That's stupid.
Like... a forum, where people place links in posts that open in a new window so the forum isn't lost.

[BLiZZaRD]

True djr... but find me a forum that passes validation.... :D

[djr33]

I think validation is overrated. Sure, it's good in some ways, but if it just removes some options completely, then that's dumb.

[Twey]

BLiZZaRD: SMF does :) I think it's as XHTML Strict (or maybe Trans), but it does validate.

djr33, that's the point of Strict DOCTYPEs.
Opening windows is very useful in many situations. That's stupid.As I said, there's no reason not to use Javascript. A simple way to replicate target="_blank" is:
<a href="somepage.html" onclick="window.open(this.href); return false;">

[BLiZZaRD]

BLiZZaRD: SMF does :) I think it's as XHTML Strict (or maybe Trans), but it does validate.


Only when you don't have any modifications on it. :D

I run about 12 on my forums, and I haven't seen one SMF that didn't have at least one. Not saying all mods make it invalid code, but most do.

[mburt]

Take this forum for example (:D), I open my JavaScript Console, and it's filled with errors (I know it's a different situation with the DocType, but you get the picture). Forums are made for functionality.

[djr33]

I think I'd rather break the doc type than have it rely on javascript.

[jscheuer1]

Some things to consider here are - That, currently most browsers will support invalid code as long as it can be understood. Generally this means that it would be valid in some DOCTYPE but there are exceptions in both directions. In some cases even code that would be invalid in any DOCTYPE will get parsed but, most likely this will vary from browser to browser. There may come a time when browsers will not support anything that is invalid in a given DOCTYPE. To be forward compatible, it is best to at least adhere to the DOCTYPE you are using. The other approach is quirks mode. To do this effectively is actually more involved than coding to a DOCTYPE and it still carries no firm promise of forward compatibility.

[tech_support]

Ok. Will you recommend switching DOCTYPES or using JavaScript?

[Twey]

I think I'd rather break the doc type than have it rely on javascript.It wouldn't be relying on Javascript. That's the point. If that popup is necessary for the page to function correctly then there's something wrong with your design, whether it uses Javascript or deprecated attributes/DOCTYPEs.

[jscheuer1]

Ok. Will you recommend switching DOCTYPES or using JavaScript?

I think that is a gray area, you need to guess what the future of the web will be like. If the page is likely to be replaced soon, it probably doesn't matter.

As Twey noted, the pop up content shouldn't be essential. I will expand upon this.


It wouldn't be relying on Javascript. That's the point. If that popup is necessary for the page to function correctly then there's something wrong with your design, whether it uses Javascript or deprecated attributes/DOCTYPEs.

Yes, the advantage of a javascript pop up of the sort:


<a href="some.htm" onclick="window.open(this.href);return false;">Link Text or Image</a>

Is that some.htm will be loaded into the same window if javascript is disabled. That way at least the user gets to see it and can use their back button if nothing else is available to get back to the referring page. If javascript is enabled, there will be a new window as planned.

The only downside is that javascript pop ups, even 'user initiated' ones like this can be blocked at times. However, the same settings that will disable this sort of pop up will disable target="_blank" pop ups (also considered 'user initiated' pop ups).

Javascript gets the edge here as well because, at least in theory, the presence of the new window can be tested for and a non-pop up version can be supplied via script if the new window was blocked.

And as stated, if all else fails, the site should be able to stand on its own without the pop up or the content that would have loaded into it.

[djr33]

... "window.open(this.href);return false;">

Why not:

... "return window.open(this.href);">

[jscheuer1]

... "window.open(this.href);return false;">

Why not:

... "return window.open(this.href);">

Did you try it? I think it will return 'undefined' - not the desired result.

[djr33]

I didn't test it, but, in general, when I've been playing with javascript, it seems to make more sense to return the result rather than returning false after doing the event.
Is this generally right but not in this case?
Or am I just wrong?
I'm not questioning you or claiming to be right; I just want to know why/how this works.

[Twey]

window.open() returns a Window object. Trying to navigate to this is generally not a good idea, so we return false instead.

[tech_support]

Ok. Looks like I'll just use the javascript. Thanks for all your help!

[jscheuer1]

window.open() returns a Window object. Trying to navigate to this is generally not a good idea, so we return false instead.

You're right about it returning a window object (I was wrong that it would return undefined) but, we are not navigating to the return value. We are simply using it to determine how to treat the normal result of clicking on the link. Only by returning false are we guaranteed to not fire the link.

When you have a function, it will return whatever value you set it up to return or, undefined if no return value is set up for it. Here (in the onclick situation we've been discussing) we want a return value of false.

[Twey]

You're right about it returning a window object (I was wrong that it would return undefined) but, we are not navigating to the return value.Oops, yes, you're right. I was getting confused with javascript: pseudo-URLs. Sorry.

[djr33]

I thought that return meant, in short, do this... execute this as a reaction.
So....
<tag a="..." do="..." something="...." onclick="return alert('hi');">

that would ignore all of the other hypothetical attributes that would cause an event on click and return the javascript instead... making an alert.

I understand the concepts of what you are saying, but I don't yet fully understand why it is like it is and why another method wouldn't work.

[Twey]

No.
<a id="mylink" href="something" onclick="return doSomething();"></a>is exactly the same as saying:
<a id="mylink" href="something"></a>
<script type="text/javascript">
document.getElementById("mylink").onclick = function(event) {
return doSomething();
};
</script>If the value returned by the event-handling function is truthy, the default behaviour will be performed as well; otherwise, it won't. Since any function without an explicit return value in Javascript implicitly returns undefined, it would probably be safe to omit the return statement entirely, but better safe than sorry.