Loading...Web Development
Invalid XHTML Strict Attributes and DOM Expando Properties
Just asking the question: Is it really bad form to add an invalid property or attribute to a valid document, via JavaScript and the Document Object Model (DOM)? The argument against is that the resulting document has become invalid.
Loosely speaking, it might be related to JavaScript expando properties, and there are a variety of issues at stake, including performance. Other things to consider might be how is the value set? Via the exposed DOM interface or via the DOM tree and .setAttribute()? But, that’s another article.
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.
There’s another script which is popular to link to, like some I’ve written myself, that, via script, apply the “target” attribute via JavaScript and the DOM. It returns a working attribute (valid or not) it to the document, giving the browser some level of behavior that the author intended. Again, the argument against is that the document is now invalid because “target” is not allowed.
Disclaimer
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
The typical reaction is that in Strict XHTML there is no “target” attribute, so this is invalid code you’ve just introduced. There are other cases where, parsing the DOM, you might want to add a property to a DOM node in the document by exploiting the ability of JavaScript to add arbitrary properties (which might be interpreted as attribute nodes in the document).
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
- Syndication
- 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
I’m of the opinion that, if you’re adding to your behavior layer via JavaScript and the DOM anyway, you might as well use “window.open” anyway, as the end results are the same. Pick a method and stay with it: you might want the same script to launch customized windows and such, so pick a method and adjust as needed. The only case where I can see it really being an issue what method you use is where alternative or assistive devices might come into play (which I haven’t thoroughly researched, so I won’t comment on).
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.
Oct 16, 02:29 AM in Web Development (filed under Web-Standards, JavaScript)
Possibly Related Articles
Commenting is closed for this article.