Re: My thoughts on XHTML 2

Chris Mannall:
> Kelvin Chung 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
>
> H<sub>2</sub>SO<sub>4</sub>
> H<span class="sub">2</span>SO<span class="sub">4</span>

Naturally one would expect something like <index/> for almost all accepted
usages of sub and sup, but how do you know whether it's an index for the
following or the preceding character[s]? This however fails--in opposite to
sub/sup--with e.g. isotopes. You'd need to have at least another element
span that area: <span><index>2</index>H<index>2</index></span>O.
Perhaps having sub and sup is the most convenient solution.

>> 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.

Those, and <section/>, would resemble <hr/> as much as <l/> does resemble
<br/>.

>> 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,

It could be the element for anchors again for cases where there's no other
element that could get an id attribute.

> <object> is another matter.

Yes. Although most elements now have a src attribute, object is the only one
that's allowed to have <param/>s inside and I seriously hope it'll learn
some captioning mechanism, too.

>> 5. Will there be a skeleton XSL stylesheet that transforms between
>> XHTML 1.x Strict and XHTML 2.0?

Seeing how inconsequently <hN/> are used, this wouldn't be of much usage for
most people. <br/> to <l/> conversion isn't unambigous neither. I see a use
for the downwards direction, though.

>> 8. Will either the linking module or the meta module be
>> deprecated/replaced (in favor of RDF/XLink)?

Btw.: Am I'm the only one who's confused by the fact that it'll probably be

  <meta name="author">Christoph Päper</meta>

now instead of

  <meta name="author" content="Christoph Päper"/>,

but still

  <link rev="author" href="/#about" title="Christoph Päper"/>

and not

  <link rev="author" href="/#about">Christoph Päper"</link>?

>> 9. Will there be an XFrame module?

Hopefully not!!1

>> 2. Although this is somewhat controversial and perhaps out of
>> personal preference, what about removing <script> and <style>?

That's IMHO too puristic to be widely accepted.

> The alternatives are simply too horrible to contemplate - either
> I'd have to allocate IDs on a site-wide rather than document-wide basis

You /could/ of course use

  <body id="one"><p id="start"> </p></body>
  <body id="two"><p id="start"> </p></body>

with

  body#one p#start {color: green}
  body#two p#start {color: red}

in the common stylesheet.

>> 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.

This probably required an attribute value type of 'boolean' and breaks
backwards compatibility once more, but I see your point. It's not appearing
that often, though.

> (my personal bugbear here is <cite cite="">)

<cite href=""> should be enough, yes.

>> 5. And now for something a bit stupid: how about a "XSemantic"
>> set of elements?

You may of course use several namespaces in one XML document.

> People have suggested a set of extension elements before...

I'm confident that there are elements that should be in HTML, e.g. for names
and numbers and maybe adverts, which all could be justified with the very
specialized elements for the IT sector (code, var etc.). IMHO it is at least
as much important to find out what elements/attributes are needed in RL as
it is to remove flaws from previous specs.

> 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.

I've not seen many, though. At least not reasonable ones, more like: "Give
us back elements to /style/ text."

>> 6. The difference between <section> and <div> should be made more clear.
>
> I think you're in a minority here. Personally, the introduction of
> <section> is something that I am incredibly happy with -

Sure, but without any doubt people will confuse it with div.

> 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 ;-)

It's probably easier to implement div *and* span than an element that could
be inline as well as block level.

Christoph Päper

Received on Tuesday, 21 January 2003 08:33:15 UTC