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.
__________________
Daemonkin.
If this was helpful, please add to my reputation Thousand Sons - Freelance Web Developer - ninetyonedegrees.com
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.
__________________
Daemonkin.
If this was helpful, please add to my reputation Thousand Sons - Freelance Web Developer - ninetyonedegrees.com
Then why suggest that the problem is target="_blank", which is used to create new windows?
Quote:
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.
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.
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).
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.
Code:
<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.
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.
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.)
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.
Location: Splendora, Texas, United States of America
Posts: 2,922
Thanks: 6
Thanked 194 Times in 191 Posts
Quote:
Originally Posted by daemonkin
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.
Quote:
Originally Posted by Bill Posters
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.
__________________
Please for the love of god stop making IE. You current "browser"s cause me to cry every day. —Phil *
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.
Location: Splendora, Texas, United States of America
Posts: 2,922
Thanks: 6
Thanked 194 Times in 191 Posts
Quote:
Originally Posted by Bill Posters
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.
Quote:
Originally Posted by Bill Posters
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.
__________________
Please for the love of god stop making IE. You current "browser"s cause me to cry every day. —Phil *
Before you post, read our: 
