¶ Dan’s latest SimpleQuiz asks the question ‘When using the XHTML 1.0 Strict doctype, how would you launch links in a new window?.’ The problem to overcome is that the target attribute is deprecated and not available in XHTML 1.0 Strict. We’re not talking about launching a pop-up here, the question alludes to opening a linked PDF in a new window.
Sadly most folks’ answer is to use JavaScript to launch a new window. While this can be achieved in an entirely accessible manner it’s hardly a suitable replacement for a simple target attribute. The answer has to be: don’t use Strict, use Transitional. You require the target attribute – it isn’t available in your first chose doctype – so use a different doctype. There’s nothing practical to be gained by specifying Strict instead of Transitional, particularly if you code your XHTML as if it’s Strict thereby avoiding deprecated presentational mark-up.
Others are saying use XHTML modularisation and write your doctype with target included. But, again, I ask why when it is contained in Transitional. Now if you were creating your own elements, perhaps for use with DOM scripting then I would say yes, modularise away. But you’re not.
But why is the target attribute deprecated in the first place? Surely that’s a mistake by the W3C? The target attribute is required to interoperate framesets. There’s no direction from the W3C that the frameset doctype is either inadvisable or deprecated, after all frames can be useful and indeed preferable in some circumstances. An oddity, but what does it matter? If you’re using frames your pages need to carry a Transitional doctype and you lose nothing for that.
So by now half of you have probably found that I’m using a Strict doctype for this page. Why? Mostly as an intellectual exercise (it is a personal site), partly to eliminate presentational mark-up (good practice) and because I didn’t need any of the deprecated mark-up found only in Transitional.
Comments
1
The target element isn’t deprecated. It has merely been moved to its own module, as have frames; there’s a module for them, too.
The W3C says:
“These modules serve as “points of conformance” for the content community. The content community can now target the installed base that supports a certain collection of modules, rather than worry about the installed base that supports this or that permutation of XHTML elements.”
...and:
“Modularization also allows for the extension of XHTML’s layout and presentation capabilities, using the extensibility of XML, without breaking the XHTML standard.”
Extending XHTML isn’t something hackish. Wanna’ extend XHTML without breaking the standard? That’s exactly what modules are for.
2
I think Richard is right: If you need a target use transitional. That’s OK for XHTML 1.0 where I think that the transitional is just strict+modules – so the inclusion of the target-module is not needed.
It is another thing with XHTML 1.1 where are no different doctypes. There it is right to include the target module.
In XHTML 1.0 I think it isn’t worth it.
3
The purpose of the transitional version is to be able to support features for older browsers that do not understand stylesheets (http://www.w3.org/MarkUp/#xhtml1). It’s purpose is not to allow web developers to use features that aren’t supported in Strict. If you support XHTML, why only go half way? You might as well just stick with HTML 4.01.
4
On framesets and use of the target attribute: If you’re using frames, you can’t even use the XHTML 1.0 Strict doctype, as the <frame> and <frameset> tags aren’t included in Strict either. But they are included in the XHTML 1.0 Frameset doctype, as is (of course) the target attribute.
Still doesn’t answer your question about why you can’t use target within a non-frameset Strict document to pop open a new window (or target a pre-existing secondary window). But thought I’d point out the Framset doctype issue.
5
Actually, there’s a great practical reason to use strict instead of transitional and it’s the reason I’ve been implementing the strict flavors of html 4 or xhtml 1 on as many projects as I can: it triggers a completely different rendering engine in most modern browsers, one that’s way smaller and leaner than the tag soup mode that most other doctypes trigger. As long as your pages actually validate and don’t throw any monkey wrench errors (making the browser start all over again in quirks mode), this makes a huge difference in how fast the pages are displayed, especially for dialup or bogged-down cable modem connections.
I love previewing my pages on slow connections, I’m addicted to the sight of my content popping onto the screen with the correct layout and color scheme instantly, while the the graphics load to flesh out the rest of the interface. It makes it feel so much faster, even if it takes just as long by the clock as a page that loads less progressively. Even better the loading bars in Flash, let’s you start reading and click around before it’s done.
6
Doug – I was hoping to allude to use of the frameset doctype for building framesets, and for Transitional/Strict for writing the pages displayed within the frameset. Re-reading I can see I didn’t quite make that clear.
As an aside, it seems reasonable to me to have a separate doctype for creating framesets as the mark-up is simply for dividing the viewport into windows, as opposed to indicating document structure and meaning.
7
Al – thanks for your input (sorry about your double post earlier – must get around to sorting that). I must confess it hadn’t occurred to me that writing Script code would render more quickly with a Strict doctype than the same code with a Transitional doctype.
While I’m happy to take your word for it – on the face of it, it seems perfectly reasonable that different algorithms would be used – I’d love to see some stats demonstrating the difference.
8
If the target attribute is only in the Frameset Doctype should then a browser never open a non-framset document in a frameset?
That would get around the need to have the target attribute to break out of a framset jail. All other uses can be left to the users right click menu..
9
Rich – No problem, I blamed myself for the double post anyway and chalked it up to Stupid User Syndrome, not the page design. I think Safari was trying to be overly helpful and filling out the form for me on my subsequent visits to the page.
As for stats on the rendering engine speeds, that might be a bit difficult to find, it’s not something as well-documented as download speeds. I tried to compile some proof for something similar at my old job; I picked up a meme from Andy King’s speed optimization book about how browsers use a two-pass algorithm to render tables (one pass to load the data, the second to actually render it, won’t display anything until the end of the 2nd pass to understand how the page should be laid out, takes forever for large data sets) unless the tables are marked up correctly, in which case you can coax the browser to load the whole enchilada in one pass and display the rows progressively along the way, with each row displayed on screen as its loaded, and with the same caveat as the Standards mode rendering engine – if it threw an error, it would start all over and treat it like tag soup, go back to doing two passes of the whole table. This is something important to understand and not just geek trivia when working on things like, for example, a contact list of several hundred people. Unfortunately, they had to just take my word for it because benchmarks for rendering speed (as opposed to simple loading times) was something beyond my skills to demonstrate. Being on the bottom of the totem pole that I was, my word wasn’t quite enough to change everyone’s coding practices. Same with the Standards vs Quirks mode engines – I know that Standards mode is easier and less taxing for the browser to display because valid xml is so structurally simple (it’s the whole point of xml!) but I’m absolutely at a loss on how to give more concrete proof. It’s a shame and I’d love to get my hands on some numbers – I can already cite Jakob-style writing on how progressive loading (how fast and responsive a site feels vs how fast it really is) is great from a psychology and usability point of view. Any help is sorely appreciated on this front!
10
“On framesets and use of the target attribute: If youre using frames, you cant even use the XHTML 1.0 Strict doctype, as the <frame> and <frameset> tags arent included in Strict either.”
Good point, Doug. But I can extend XHTML 1.0 Strict to include the Frames and Target modules, which begs the question: Is there any benefit to choosing one way over the other? Jeffrey Zeldman’s case was that extending the DOCTYPE could have unintended consequences, including sending browsers into Quirks Mode. The tests I’ve done, however, suggest that this is not an issue. Mozilla and IE properly render extended DOCTYPES in Standards Mode.
Assumptions: 1) Extending XHTML is in the spirit of the spec; 2) there are no known browser incompatibilities related to XHTML extensions; and 3) lots of folks want to conform to the Strict DOCTYPE.
If these can be taken as fact, is there any reason not to extend XHTML? Given that we can extend XHTML to get whatever elements and attributes we need, is there a real benefit to settling for a less rigid DOCTYPE?
Add your comment
Comments are now closed on this post. If you have more to say please contact me directly.