{"id":189,"date":"2003-07-04T12:18:18","date_gmt":"2003-07-04T16:18:18","guid":{"rendered":"https:\/\/www.goer.org\/wordpress\/xhtml2_explorations_part_ii"},"modified":"2003-07-04T12:18:18","modified_gmt":"2003-07-04T16:18:18","slug":"xhtml2_explorations_part_ii","status":"publish","type":"post","link":"https:\/\/www.goer.org\/Journal\/2003\/07\/xhtml2_explorations_part_ii.html","title":{"rendered":"XHTML2 Explorations, Part II"},"content":{"rendered":"

In the last installment of XHTML2<\/acronym> Explorations<\/a>, we touched on how XHTML2’s attribute collections<\/a> provide a rich variety of behaviors for nearly all elements. Today’s installment focuses on the individual elements themselves. As with Part I, this post does not discuss “well-known” XHTML2 concepts.1<\/a><\/sup><\/p>\n

New Paragraph Model<\/h4>\n

XHTML2 gives us a new twist on our old friend the <p><\/code> tag. In previous versions of HTML<\/acronym> and XHTML<\/acronym>, you could not nest other block elements inside a paragraph. Now you can nest any block element<\/a> except for another paragraph. In other words, you can now consider a list or table to be semantically part of a paragraph.<\/p>\n

This leads to an interesting result (first brought to my attention by Jacques Distler<\/a>). Consider the following (invalid) markup2<\/a><\/sup>:<\/p>\n

\n  <p style=\"color: red\">\n    Why is Gordon better for Dana than Casey?\n    <ul>\n      <li>Knows mayor Giuliani<\/li>\n      <li>Can dress self w\/o assistance from Wardrobe<\/li>\n      <li>Obvious physical prowess<\/li>\n      <li>Two!! post-graduate degrees<\/li>\n    <\/ul>\n  <\/p>\n<\/pre>\n
Since a paragraph can’t contain lists, a standards-compliant browser would end the paragraph just before the start of the unordered list.  Thus the words, “Why is Gordon…” would be colored red while the list items would remain unchanged.<\/p>\n
However, under XHTML2’s new paragraph model this code is<\/em> valid, and everything inside <p><\/code> and <\/p><\/code> would be red.  I have to admit that from a coding standpoint, I like this.  If nothing else, it matches my naive expectations a little better.  (“Hey, why isn’t my list red?” the newbie web designer wonders…)<\/p>\n
From a semantic standpoint, I’m a little less sure about this.  I usually don’t think of my tables as being nested inside my paragraphs.  Neither does Framemaker, for that matter.  Is Framemaker broken?  Am I<\/em> broken?  Well, maybe.  The good thing about this model is that it’s totally optional — you can nest stuff inside paragraphs, or not.  Works for me.<\/p>\n
Scripting<\/h4>\n
You can now nest <script><\/code> elements<\/a> and process them like the <object><\/code> element. If the browser understands the parent script, execute it; otherwise go on to the child script(s). It’s a nifty model, albeit one that is not backwards compatible<\/span>. Whoops — I forgot, it’s not fair for us to harp on that. Sorry.  Anyway, the model itself looks good, particularly if you want to script with multiple languages.  The spec does take great pains to mention that there are<\/em> scripting languages besides Javascript, such as… type=\"text\/x-perl\"<\/code>.  Hmmm.<\/p>\n
There is also a new declare<\/code> attribute for both scripts and objects. This boolean attribute specifies whether the script or object is a “declaration only”, meaning that it is not to be processed until the user initiates some sort of action.  And speaking of actions, there’s a brand-new events model<\/a> defined by the XMLEVENTS standard (which is pleasantly short and easy to read). XMLEVENTS allows you to set any element as the observer or handler for standard  DOM<\/acronym> events<\/a>.  It also provides a generic <listener><\/code> element that can pass events off to handlers. The XMLEVENTS spec looks to be far more comprehensive and flexible than our current model, which involves slathering our code with onmouseover<\/code> attributes and whatnot.  The only catch is that XMLEVENTS has totally replaced the existing model, which means our current scripts all just went POOF!<\/span>.  Argh, there I go again…<\/p>\n
The spec also declares the death of document.write<\/code>:<\/p>\n
\n
Note that because of the XML processing model, where a document is first parsed before being processed, the form of dynamic generation used in earlier versions of HTML, using document.write<\/code> cannot be used in XHTML2. To dynamically generate content in XHTML you have to add elements to the DOM tree using DOM calls [DOM] rather than using document.write<\/code> to generate text that then gets parsed.<\/p>\n<\/blockquote>\n
Well, that’s fair enough.  The W3C seems to be saying, “Look guys, this is XML<\/em> here. Not HTML<\/a>, not some halfway-step<\/a> that decays back into friendly tag-soup if you make a mistake — this is the real stuff<\/em> here.” I suppose the real question is whether they’re going to forbid XHTML2 to be served up as text\/html<\/code>. I can’t find any discussion of MIME-type issues in the current spec, so it’ll be interesting to hear the W3C’s final decision on this.<\/p>\n
Miscellany<\/h4>\n