Re: My thoughts on XHTML 2

On 1/21/03 3:25 AM, "Chris Mannall" <chris.mannall@hecubagames.com> wrote:

>> 1. Is there any point to having <sub> or <sup>?  I cannot find any real
>> semantic value in these two elements.
> 
> Neatly sidestepping the issue of semantic value, I will limit myself to
> saying that I greatly prefer the first of the following two examples:
> 
> H<sub>2</sub>SO<sub>4</sub>
> H<span class="sub">2</span>SO<span class="sub">4</span>
> 
>> 2. Would <l/> (ie. An <l> element with no content) be the same as <br/> in
>> the long run?
> 
> No more so than would e.g. <p />, <div /> and so on. This isn't how the
> elements are meant to be used, so the results aren't described in the
> spec. Basically, it depends on how CSS styling (yours or the UA's
> default) applies to empty elements.

Too bad there isn't something in Schema or DTD that forbids elements being
empty...
 
>> 3. Is there any point in keeping <a> or <object> now that any element can
>> act as such?  Perhaps an accessibility objective...?
> 
> Although I agree that <a> is now entirely redundant, <object> is another
> matter. In fact, I'm puzzled by your statement - exactly how can "any
> element" be used to embed Flash into a page, or even just an image?

I thought the src attribute now embeds stuff...

I was thinking that if an embedded object needed <param>, then it would be
the first children of such an element (with your fallback after the
<param>), thus neutralizing the need for <object>.

However, both elements could be kept in for a purpose like accessibility...

>> 4. <nl>, the accesskey attribute, and the navindex attribute seems to be a
>> bit media-specific, as it seems that non-screen media do not benefit much,
>> if anything, from this.  Perhaps someone can enlighten me on what is going
>> on?
> 
> In the case of <nl>, I find it easy to see uses for non-screen media.
> The default visual rendering of <nl> is that only the top-level <li>'s
> should be visible until one is activated, and so on down the hierarchy -
> which maps perfectly onto aural media, for example, since only the
> top-level <li>'s need to be *read out* until one is activated by
> whatever mechanism the user agent provides. If in doubt, think about how
> automated phone systems work - when I call my bank, the robot on the
> other end reads me my basic options, such as "balance information",
> "transfer funds" and so on. I then press the number corresponding to
> that option, and get a new list of suboptions.

But it still doesn't do squat for print...  I guess that's my gripe.  I
withdraw this statement.

>> 5. Will there be a skeleton XSL stylesheet that transforms between XHTML 1.x
>> Strict and XHTML 2.0?
> 
> I'm not sure such a conversion would be complex enough to warrant it
> being part of the specification.

Such an XSL stylesheet would be able to say, change the <meta>s to XHTML
2.0-compliant ones, <a> to <span>, and maybe deal with <h1> to <h6>
(assuming that is being thrown out).  Then you will have to replace the
elements that are gone (the forms stuff to XForms, the formatting stuff,
etc.)

>> 6. With <section> and <h>, is there any point in keeping <h1> to <h6>?
> 
> A more careful reading of the spec would have shown that this is already
> listed as an issue [1].

Point taken.
 
>> 7. I'm not sure on this, but is multiple instances of <title> permitted so
>> that you can have titles in different languages?
> 
> No need for this at all - your document is only in one language, so your
> title only needs to be in one language. If you have provided alternative
> versions of the document in different languages, then there is already a
> mechanism for linking to them - there's an example[2] of this in the
> spec already, a modified version of which appears below:
> 
> <html xml:lang="en">
>  <head>
>    <title>The documentation in English</title>
>    <link title="La documentation en Fran&ccedil;ais"
>          rel="alternate"
>          xml:lang="fr"
>          href="http://example.com/manual/french.html"/>
>  </head>
>  ...
> </html>

Let's say you have one page that has the same thing repeated in English and
French (and you format the page so that you have an <nl> linking to the two
sections, marked out by <section> and id attributes.).  What do you put in
the title?

So you're saying that it would be better to split the page into two than
deal with the title...?

>> 8. Will either the linking module or the meta module be deprecated/replaced
>> (in favor of RDF/XLink)?
> 
> With regards the meta module: I doubt it, since RDF is rather complex.
> The meta module represents a clean, simple way of attaching basic
> metadata without diving into the complex world of RDF.
> 
> With regards the linking module: You must be one of the few people to be
> unaware of The Great XLink Debacle. Note that the XHTML 2.0 draft does
> say, under "Status of this Document", that "[t]his version also does not
> address the issues revolving around the use of XLINK by XHTML".
> 
> Use of XLink within XHTML is something of a political minefield. The TAG
> were of the "unanimous opinion"[3] that XHTML should use XLink, whereas
> the XHTML working group were strongly against the use of XLink,
> apparently believing that the XLink spec was broken and unsuitable for
> use in XHTML. This led to the development of the HLink specification[4].
> Exactly what the current state of play is I don't know, since the
> argument seems to be largely taking place behind closed doors right now.

Point taken on the RDF part.

I'd say that the arc-linking in XLink could be useful in XHTML to describe
more complicated links than say, what <link> can provide, and it would be
more organized, too.

>> 9. Will there be an XFrame module?
>> 
>> 10. I can see how advertisers can abuse the "universal link" by placing a
>> href attribute in one of the main structural tags.  Is this of anyone's
>> concern at W3C?
> 
> I don't see how <body href="http://foo.com">...</body> is any more open
> to abuse than <body><a href="http://foo.com">...</a></body> was in the past.

Point withdrawn.

>> I'd also like to make some suggestions, although they may have been debated
>> to death:
>> 
>> 1. <hr> - although it possesses some semantic meaning, it's in the
>> "presentation" module.  If <hr> is "purely presentational" as its position
>> implies, wouldn't something like the skeleton example below suffice?
>> 
>> <l src="hr.gif">* * *</l>
>> 
>> Thus, <hr> either needs to be retooled so as to make its semantic meaning
>> clear, or be removed completely.
> 
> This is an issue that has been debated quite extensively, but with
> no-one able to come up with the "killer argument" to conclusively
> save/condemn it. I'm mostly ambivalent, since I do use <hr/>
> occasionally and yet wouldn't consider it earth-shattering if it were
> removed.

Tough call.  But say <hr> was kept.  What would be the difference between
that and the line I posted?

>> 2. Although this is somewhat controversial and perhaps out of personal
>> preference, what about removing <script> and <style>?  From a "structural
>> purist" perspective, style sheets and scripts should be kept separate from
>> the XHTML document at all times.  (This argument might be invalidated if you
>> consider putting XML from multiple namespaces together)
> 
> That just isn't practical. Imagine that I want to style one particular
> instance of an element within my document. I (probably) no longer have
> the use of the style attribute, since Ian seems to have roundly defeated
> us on this issue[5], so my only option is to give the element an ID and
> attach a CSS rule to it via that ID. This seems to me for more suited to
> an internal rather than external stylesheet, since the style rule
> applies to *this document only*. The alternatives are simply too
> horrible to contemplate - either I'd have to allocate IDs on a site-wide
> rather than document-wide basis (ensuring either that id="myID" occurs
> only once on the entire site, or only when I'm certain that I want both
> elements to be styled identically), or I should start maintaining
> separate external stylesheets for each document. Neither are pretty.

Point taken about <style>.  What about <script> and <noscript>?  Compared to
other tags, this seems prehistoric.  Is there any advantage to keeping these
two?

>> 3. ismap="ismap" (as an example) seems to be a bit too much.  I think
>> something similar like ismap="yes" or ismap="true" should be used instead.
> 
> I see where you're coming from (my personal bugbear here is <cite
> cite="">), but I wouldn't be at all surprised if you ran into arguments
> about backwards-compatibility.

Me neither, but I guess I'll find the "it won't be backwards-compatible"
argument in _every_ issue related to XHTML 2.0.
 
>> 4. Could a limited subset of SVG be used instead of the shape and coords
>> attributes?
>> 
>> 5. And now for something a bit stupid: how about a "XSemantic" set of
>> elements?  For example, if you want to markup a URI, you could mark it up in
>> something like <xs:uri>.  This "extra" set could address large numbers of
>> semantic element requests while keeping XHTML slim and not bloated...
> 
> People have suggested a set of extension elements before... the problem
> is that there are an awful lot of people with an awful lot of ideas for
> what elements should be part of these extensions. You're probably best
> off either writing your own set, or finding someone who happens to have
> written a set that covers your needs - but I can't see the W3C ever
> reaching consensus on what should be included when it's difficult enough
> just to get an XHTML spec out of the door.

... And that's why it's a corny idea, just there for the humor.

>> 6. The difference between <section> and <div> should be made more clear.  I
>> have a hard time determining the difference, and I fear that people may not
>> care about the difference, seeing that <div> elements currently do what
>> <section> would do anyways.
> 
> I think you're in a minority here. Personally, the introduction of
> <section> is something that I am incredibly happy with - I've long lost
> count of the number of documents in which I've used <div class="section>
> extensively. If there's any redundancy here, I would say it's with
> regards <div> and <span>. But now I'm the one in the minority ;-)
 
I'm also happy with <section>.  However, there doesn't seem to be any real
difference in semantic value if I did something like these two:

<div>foo</div>
<section>foo</section>

Or these two:

<div><h1>bar</h1></div>
<section><h>bar</h></section>

Received on Tuesday, 21 January 2003 19:13:22 UTC