In principal I really don’t think it’s as big an issue as folks typically make it out to be. I am going to go out on a limb and state the original document is still perfectly valid.
Another Pop-Up Window Script
Finding yet another script for dealing with pop-up windows in XHTML Strict scenarios where the “target” attribute is not allowed got me thinking about all the different variations of scripts like this I’ve seen.
First, let me make it clear, as Roger does in his article, that I’m a firm believer that pop-up windows should typically be avoided, but in the real world there are cases where it still comes up. Clients, external Web sites, document formats such as PDF and Word (Doc) files. There are some arguments that are just hard to win, especially when clients start and won’t listen.
The case of the pop-up window and the “target” attribute is just an example to express a point in this post. However, it does introduce something worth considering. The browser knows what “target” means. But what if it didn’t? It might be just another expando property which would introduce no behavior to the page whatsoever. The fact is that it does introduces the behavior, but it very well might not. Say in a few years that behavior is removed from the browser. No popup. Use window.open instead. But is “target” really invalid as introduced by script?
Back to the Point at Hand: Strict Document Attributes
Not a stunning example, but I’ve used it to store initial values for rollover scripts. For instance, parse the document and find the original source of an IMG element and set it as “oldsrc”, set the new source on the “newsrc” attribute, then go to town with your rollover action. Sure, you could store that same data in another structure such as a custom object or an array. I say it depends on the circumstances which you choose, and just because you’ve added it, doesn’t mean you’ve added an attribute which makes the document invalid.
The browser allows it, and the DOM allows it.
Invalid Attributes Set Via Script
In this case however, the “target” attribute was removed from the HTML 4.01 Strict DOCTYPE and XHTML 1.0 Strict DOCTYPE, and deprecated in the corresponding TRANSITIONAL Doctypes. Therefore, it’s considered an “invalid attribute”. Is it? Just because the browser knows the difference between “target” and another expando property, does that make it different? I don’t think it does.
What is different in my mind is if the attribute existed in the hard-coded, saved document, versus a dynamic document which doesn’t really exist.
Common arguments against inserting invalid attributes include:
- an invalid attribute in the DOM is not a standards compliant technique
- you’re just fooling the validator, it’s still invalid
- an invalid attribute will break validation of the resulting document
- an invalid document then exists, which is… invalid code
Not a “standards” compliant technique? I just don’t think the argument holds any weight.
Back to New Windows with the Target Attribute
In this post, this fellow rants against adding the target attribute via scripts to links. It’s just interesting to me that it’s in response to a post from Tantek Çelik, a guy who I would have a hard time arguing against in general when it comes to standards compliance. He was on the team which created Internet Explorer 5 for the Mac, which, in it’s day was the most standards compliant browser around.
In the post, the argument against says:
“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.”
Honestly, I don’t think it is. I could be wrong, but that’s my opinion. And Tantek seems to agree, on his own site in response, he says:
“I disagree dolphinling. There is no supporting evidence (nor even reasoning) provided that dynamically adding a target attribute makes the document invalid. And if anything, the fact that the DOM permits you to do so without error provides evidence that it is valid to do so.”
That’s coming from a guy who built Web browsers for a living.
A New Document, In Memory Only
I’m thinking that the insertion of invalid attributes (read: expando properties) only really exists in one place: in memory, at run time, in a user agent or browser which supports the DOM methods which have inserted them and executed them.
Where does validation really matter in the end?
- Testing and Quality Control
- Consistent and appropriate browser rendering
- External Tools which might parse the original document
- Accessibility tools and assistive devices
In most cases, the behavior happening here is a controlled scripting environment just like within the standard browsing experience.
The point of DOM scripting is to add the behavioral layer to the document. This article points out that the DOM standard allows it and it is a totally different standard. It’s like saying that CSS can’t make something green because the HTML element is rendered black.
Back to the Start: Using window.open vs. Target
However, the argument that adding a “target” attribute back via scripting is resulting in an invalid document holds no weight for me. Feel free to use it if you want to. For that matter, use “oldsrc” on those images too. As long as it’s added dynamically, and not in the orginal source document.
Possibly Related Articles
commenting closed for this article