{"id":188,"date":"2003-07-01T19:25:59","date_gmt":"2003-07-01T23:25:59","guid":{"rendered":"https:\/\/www.goer.org\/wordpress\/xhtml2_explorations_part_i"},"modified":"2003-07-01T19:25:59","modified_gmt":"2003-07-01T23:25:59","slug":"xhtml2_explorations_part_i","status":"publish","type":"post","link":"https:\/\/www.goer.org\/Journal\/2003\/07\/xhtml2_explorations_part_i.html","title":{"rendered":"XHTML2 Explorations, Part I"},"content":{"rendered":"

You read that right: “XHTML2<\/acronym> Explorations”. Yes, the fun never stops here at goer.org.<\/p>\n

I’ve decided to take a closer look at XHTML2<\/a>, or more specifically, XHTML2 Working Draft 6<\/a>. I’ll admit that I haven’t done a good job slogging through the thousands of messages<\/a> on the W3C<\/acronym> lists. I’m just a casual observer.<\/p>\n

Fortunately, there’s been plenty of weblog chatter over the <object><\/code> replacing <img><\/code><\/a>, <cite><\/code> getting dropped<\/a> and then added back<\/a>, the excitement over <blockcode><\/code><\/a>, the battle<\/a> over the style<\/code> attribute, navigation lists, the new <h><\/code> and <section><\/code> model, the “href<\/code> on everything” model, and more. The Alphas have been discussing these issues for months, and we Gammas have been well-served by just listening in.<\/p>\n

But even with all the healthy public discussion, XHTML2 is a big<\/em> specification (430 KB<\/a> and counting). At least for my own edification, it’s time to see how deep the rabbit hole goes.<\/p>\n

A Swarm of Attributes<\/h4>\n

XHTML2 provides a huge<\/em> number of common attributes that are divided up into collections<\/dfn>. Most XHTML2 elements accept attributes from all<\/em> collections. The most well-known example of this is the “everything is a hyperlink” concept, wherein you can turn any XHTML2 element into a link by applying the href<\/code> attribute.<\/p>\n

But of course there’s much more. Consider the set of “common” attributes in HTML 4.01: there’s id<\/code>, style<\/code>, class<\/code>, dir<\/code>, lang<\/code>, title<\/code>, and the “event” attributes (such as onmouseover<\/code>). This yields a little over 15 attributes, depending on how you’re counting. In contrast, XHTML2 already<\/em> provides around 30 common attributes. Let’s take a closer look.<\/p>\n

The Edit Collection<\/h4>\n

The Edit Collection<\/a> provides an edit<\/code> attribute with four allowed values: inserted<\/code>, deleted<\/code>, changed<\/code>, and moved<\/code>. Presumably if something is moved<\/code>, you can specify where<\/em> it moved to by using the href<\/code> attribute. There’s also a datetime<\/code> attribute<\/a> for specifying the timestamp, the format of which is defined in XML Schema<\/a>, which references ISO 8601<\/a>, which has since been revised<\/a>. Whew<\/em>.<\/p>\n

The default presentation should be display: none<\/code> for deleted<\/code> markup, while the other three types should be displayed as-is. Note that if we assume that the XHTML2 browsers of the future will have solid CSS2<\/a><\/acronym> support, then we can write:<\/p>\n

\n  *[edit=\"deleted\"] {\n    display: inline;\n    color: red;\n    text-decoration: line-through;\n  }\n<\/pre>\n
I’ll admit I like the idea of having a simple change record facility. However, there doesn’t appear to be an editedby<\/code> attribute, which seems like a bit of an oversight.<\/p>\n
The Embedding Collection<\/h4>\n
Through the Embedding collection<\/a>, each element can have a src<\/code> attribute. The browser attempts to replace the element’s content with the embedded file or resource. If the embedding fails for some reason, the browser proceeds to process the contents of the element. The spec provides an example involving a table:<\/p>\n
\n  <table src=\"temperature-graph.png\"<\/strong> type=\"image\/png\">\n    <caption>Monthly temperatures<\/caption>\n    ... (lots of table rows and cells) ...\n  <\/table>\n<\/pre>\n
The spec also declares,<\/p>\n
\n
Note that this behavior makes documents far more robust, and gives much better opportunities for accessible documents than the longdesc<\/code> attribute present in earlier versions of XHTML, since it allows the description of the resource to be included in the document itself, rather than in a separate document.<\/p>\n<\/blockquote>\n
I scratched my head over the new src<\/code> attribute for a while… but if you think of it as a replacement for the longdesc<\/code> attribute, then it sort of<\/em> makes sense.   A couple of points, though.<\/p>\n
First, a quibble with the W3C’s example — I’m not quite sure how replacing a perfectly good XHTML table with a PNG<\/acronym> image constitutes a great leap forward under any circumstances.<\/p>\n
Second, the W3C recommends:<\/p>\n
\n
This collection causes the contents of a remote resource to be embedded in the document in place of the element’s content. If accessing the remote resource fails, for whatever reason (network unavailable, no resource available at the URI given, inability of the user agent to process the type of resource) the content of the element must be processed instead.<\/p>\n<\/blockquote>\n
Maybe I don’t understand this statement correctly, but I take the “instead” to mean that browsers should not<\/em> continue to process content if the remote resource is<\/em> accessible.  If so, I certainly hope that the browsers ignore this recommendation.  The browser doesn’t need to display the child content directly, but it needs to process the entire document and provide access to the child content somehow<\/em>. Otherwise, accessibility gets worse, not better.<\/p>\n
Finally, this concept opens up all sorts of interesting UI issues.  Take the <table><\/code> example above.  If I use my browser’s “Find Text In This Page” function, will the browser search the text in the table cells? How will it highlight successful matches?<\/p>\n
The Cite Attribute<\/h4>\n
The Hypertext collection<\/a> permits any element to have a cite<\/code> attribute. At first glance, I thought that this made the <cite><\/code> element redundant. But as Mark Pilgrim<\/a> points out in Semantic Obsolescence<\/a><\/cite>:<\/p>\n
\n
“No, the cite<\/code> tag and the cite<\/code> attribute are not the same thing.  The cite<\/code> attribute is a URL<\/acronym>; the cite<\/code> tag is wrapped around actual names within your text.”<\/p>\n<\/blockquote>\n
Fair enough.  However, I’ve been thinking that this might be an oversight on the part of the W3C, and the cite<\/code> attribute should be allowed to contain arbitrary text.  For example:<\/p>\n
\n  <h1>Ask Dr. Science!<\/h1>\n\n  <p>Q: Dr. Science, why is the sky blue? -- Ashley, age 8<\/p>\n\n  <p>A: Glad you asked, Ashley!  The answer is simple, really:<\/p>\n\n  <blockquote\n    cite=\"Jackson, J.D. 1975. Classical Electrodynamics, 2nd. ed. \n          New York: John Wiley and Sons\"<\/strong>>\n  <p>\n    The scattering of light by gases, first treated quantitatively by Lord\n    Rayleigh in his celebrated work on the sunset and blue sky, can be \n    discussed in the present framework.  Since the magnetic moments \n    of most gas molecules are neglible compared to the electric dipole\n    moments, the scattering is purely electric dipole in character.  In \n    the previous section we have discussed the angular distribution and\n    polarization of the individual scatterings (see Figure 9.6).  We \n    therefore confine our attention to the total scattering cross section\n    and the attenuation of the incident beam.  The treatment is in two \n    parts...\n  <\/p>\n  <\/blockquote>\n<\/pre>\n
The cite<\/code> attribute provides an elegant way to scope sections of a document as belonging somewhere else, so why limit it only to stuff on the web?  As for the <cite><\/code> element, it would still be good for explicitly marking up citations (such as the ones found at the end of a journal article). Well, just a thought.<\/p>\n
New LinkType Options<\/h4>\n
The rel<\/code> attribute, once the sole province of the <link><\/code> element and <a><\/code> element, is now universal<\/a>. The allowed values are defined by the LinkType<\/code> data type<\/a>. There are three new options:<\/p>\n