Wednesday, July 23, 2008
Viewport Flux, Part 3
Blog Entry #120
Lagniappe: Using links to open new windows
In the "Minimize/Maximize a Browser Window" tutorial, Joe codes the hyperlink to the tutorial's demo page as:
The above link opens the demo page in a new browser window; this reminded me that HTML Goodies' Getting Started Tutorial sector sports a "So, You Want A New Browser Window, Huh?" tutorial that offers the following code for using links to open new windows:
<a href="http://www.site.com/page.html" target="resource window">Text Text Text</a>
How 'bout them target attribute values, huh? new window? resource window? Seem suspicious, don't they? To be sure, they're not standard, but - at least with respect to HTML - they're not invalid, either.
Shared by the anchor, area, base, form, and link elements, the target attribute is detailed in the Transitional Document Type Definitions (DTDs) of HTML and XHTML but is not deprecated. The target attribute's data type designation is %FrameTarget;, an entity reference whose replacement text is "CDATA" in the HTML 4.01 Transitional DTD but is "NMTOKEN" in the XHTML 1.0 Transitional DTD.
• CDATA is defined in Section 6.2 ("SGML basic types") of the HTML 4.01 Specification. A CDATA string can contain any Unicode characters, including white space characters, and also character references (e.g., £ for £); however, before you add a target="@#$%" attribute to your Web page, I draw your attention to Section 6.16 ("Frame target names") at the bottom of the page, which states,
[F]rame target names (%FrameTarget; in the DTD) must begin with an alphabetic character (a-zA-Z). User agents should ignore all other target names.(So as to why the target attribute has a CDATA data type and not a NAME data type, well, you'll have to ask Dave Raggett about that.)
• For a definition of NMTOKEN, Section C.8 ("Fragment Identifiers") of the XHTML 1.0 Specification directs the reader to the Name and NameChar productions in the XML 1.0 Specification
Name ::= (Letter | '_' | ':') (NameChar)*
NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
according to which a NMTOKEN string must begin with an alphabetic character, an underscore, or a colon, followed by zero or more NameChar characters (letters, digits, periods, hyphens, etc.). NameChar characters do not include white space characters, and thus the new window and resource window target values are actually invalid from an X(HT)ML standpoint.
The aforecited "Frame target names" section specifies that the reserved target value _blank
<a href="fileURI" target="_blank">Link text</a>
can be used to open a link in a new window. But why do the new window and resource window target values open links in new windows? Our situation is addressed by the W3C in Section 16.3.2 ("Target semantics") of the HTML 4.01 Specification:
4. If any target attribute refers to an unknown frame F, the user agent should create a new window and frame, assign the name F to the frame, and load the resource designated by the element in the new frame.It follows that there's nothing special about the new window and resource window target values - we could set a link's target attribute to Bond_007 (but not 007_Bond) and the link will open in a new window as long as there isn't another window named Bond_007 open on the screen.
FYI: If an empty string is assigned to the target attribute (target=""), then the link's href file will not be loaded into a new window but into the current window.
Interestingly, Mozilla pooh-poohs the use of target="_blank", arguing that
(a) it's inefficient, more specifically, a given target value should be reusable by other links in the document, which is not the case for the _blank value, and
(b) it's semantically unsatisfying: target="demoWindow" would be a better choice for a demo page link, for example.
(For that matter, Mozilla argues against loading files into new windows more generally.)
But I'm sure Mozilla would agree that there's nothing terribly wrong with target="_blank" if you only use it once or twice in your document.
I think we can skip a discussion of this, uh, crucial issue, but one sentence in the tutorial did grab my attention:
[A selection rectangle] makes image maps look cruddy.This reminded me that HTML Goodies has an Image Maps Tutorial sector, a part of the site I had previously not worked through. I then read the sector's "So You Want A Client-Side Image Map, Huh?" tutorial, which presents image map code that in some respects is seriously out of sync with the W3C's image map documentation and which, given that image maps would be an entirely new topic for us, we'll check over in the next post.