Do NOT attach “target” through script!

Using target in (X)HTML Strict. If you need to use the target attribute, either stick with Transitional DOCTYPEs, or add the target attributes dynamically using semantic scripting, e.g. based on semantic class names.


NO NO NO NO NO! Your page is just as invalid if you add target in with script as if you put it in your markup.

If you absolutely must open a new window, make it a normal <a href=""> and use and cancel the default action for the link. But if you weren’t providing any size or chrome info (which are impossible with target anyway), then you don’t have any reason to be opening a window in the first place. Just don’t do it.

9 Responses to “Do NOT attach “target” through script!”

  1. - says:

    nad use

    Also your Trackback link doesn’t seem to work.

  2. dolphinling says:

    Thanks, fixed the typo. I’ll look into the trackback issue, although I’m rather new to php and at this point I’m rather dependent on wordpress.

  3. S├ębastien Guillon says:

    (Followed the link from Tantek’s page)

    The question is: Should browser accept to attach and work with a target attribute even if the document has a strict DOCTYPE? None that I know refuse to.
    Can this be equated to a bug? Should browsers respect the DTD?

    That would be a different web.

  4. Nat says:

    So, if you have valid XML and then use XSLT to transform it into an invalid HTML document … the XML is “invalid”?

  5. abba bryant says:

    Why bother with target if you are going to use unobtrusive js to attach it?
    You can simply find links with class=”new-window” and add the and chrome code then cancel the default click behavior. Adding an invalid attribute the the anchor to do something that works fine another more valid way seems a waste of time. If you want to use target use target. If you can’t or don’t want to then do it the js way without adding invalid attributes to the DOM.

  6. zcorpan says:

    S├ębastien, no, the spec does not require that UAs behave differently depending on the doctype. (Formally, handling of invalid documents is undefined in HTML4.)

    Nat, no, the HTML that the XSLT outputs is invalid (or, to put it in another way, the resulting DOM is invalid).

  7. PJ says:

    It’s funny that you’re preaching this from the default WordPress theme.

    It was hard, but I gave up target tags to be “Strict”.

  8. Rob Cherny says:

    I have to disagree with the content of this post, dolphinling, and agree with Tantek Celik. If you dynamically insert a target attribute your original document is still perfectly valid. The only place the “invalid” document exists is at runtime, in memory, and there’s no reasoning that the dynamic document, which doesn’t even persist, matters in the world of validation. The page still renders (in standards mode no less), will continue to, and the DOM has added the behavior layer which is actually exactly the way it’s supposed to work.

  9. dolphinling says:

    The “in memory” document is the one that the user actually sees and interacts with; it’s the most important to keep valid. Especially note, for example, assistive software. It’s not so much an obvious problem with target, but it’s equivalent to, for example, adding a font element inside a paragraph through script. The original markup will be valid, but the resulting DOM will be invalid, and it’s the resulting DOM that the assistive software looks at. It’ll see the invalid, non-semantic font, and not know what to do with it.

    PJ, yes, I’m entirely aware of the irony of writing this from wordpress. :-\