Re: My thoughts on XHTML 2

On 1/21/03 6:33 AM, "Christoph P*per" <christoph.paeper@tu-clausthal.de>
wrote:

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

I don't get that part: why would an empty <section> resemble more of <hr>
than <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.

I was hoping <param> could go under any element as its first children,
seeing that <object> is pretty much universal now...

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

Weird...
 
>>> 9. Will there be an XFrame module?
> 
> Hopefully not!!1

I kind of see the point of not having one... It's just to appease people who
complain that "my frames are gone! Noooooo!"

Point withdrawn.

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

Maybe I am too puristic in that regard...
 
>> 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.

But that makes it so that your ID scope is now site-wide instead of
page-wide.

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

Wouldn't that put a link inside <cite>, or is that the point?
 
>>> 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.

Of course.

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

Those people must be really in the dark.  Such elements would further screw
up the mess that is HTML 4.0.

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

... Such as myself.

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

Received on Tuesday, 21 January 2003 19:29:23 UTC