Re: kelvSYC's Thoughts on the new XHTML Draft

On 5/8/03 8:05 PM, "kelvSYC" <kelvsyc@shaw.ca> wrote:

> 
> Here are my thoughts on the new XHTML draft:
> 

...

> Inline and Block Modules:
> The last time I checked, whether something was inline or block has no
> semantic meaning.

Please check again.  This has been thoroughly discussed, both in the
archives of www-html and other locations.


> Trying to separate text module elements based on
> (visual) presentation seems to defy the overall design goals of XHTML2.

The separation is based on content model, and is done so for better
modularity.


> Style Attribute Module:
> I thought the style attribute was soundly defeated in an earlier
> debate...?

Quite the opposite.  It boiled down to the professional web community
(individuals and companies) demonstrating real-world use/need-cases, which a
few theoreticians argued in theory should either not be necessary or not
exist, thus completely missing the point, no matter how many times the same
hollow theoretical arguments were reiterated.


...

> class Attribute:
> The definition of the class attribute seems to depend on CSS.  If this
> is so, then why isn't this moved to being a part of CSS?

The class attribute is a hook for style rules and more.  It can be used to
effectively semantically subclass an element.

And besides, CSS doesn't have attributes (attribute selectors, yes, but not
attributes).


> Edit Collection:
> This seems like metadata about some part of the document, and it looks
> like you can only have information about (presumably) the last time the
> content was edited (instead of every time).  To resolve this, I propose
> that there should be some child to this element that can deal with the
> changes.  Here's an example:
> 
> <div>I am a
>  <edit>
> <original date="before_operation">boy</original>
> <change date="after_operation">girl</change>
>  </edit>
> </div>
> 
> It's a rough idea, but it might work.

It's not clear how this solution handles multiple generations of edits any
better.  In addition, the markup is simpler when just attributes are used.
Experience of using ins/del elements demonstrated that elements for this
purposes are unnecessarily heavyweight and cumbersome to say the least.
Nevermind the fact that such edit elements also introduce additional
structure which can break scripts/styles/contentmodels which depend on
particular structures.  Attributes work much better in this way.


> target Attribute:
> It seems that this definition depends on XFrames.  If this is so, then
> why isn't this moved to being a part of XFrames?

Authors make use of target without frames all the time.  Target can be used
with frames but neither is dependent on the other.


> rev Attribute:
> I don't see the point in having this, when something like rel="reverse"
> might work.

In practice I have not found much utility for the 'rev' attribute either,
but given that authors are free to define their own linktypes using
profiles, it seems reasonable to keep 'rev' unless it is causing some harm
(which has not been demonstrated).


> Speaking of which, wasn't there some debacle about XLink
> in XHTML?

You could shorten that to "wasn't there some debacle about XLink?", and you
would be right.


> This Collection could be replaced with some form of XLink
> implementation...

But why?  Do you think authors like typing unfamiliar markupJunk over and
over again?


> accesskey and navindex Attributes:
> In the spirit of Device Independence, please drop these...

With accesskey - I agree.  The specification of a particular accesskey is
typically quite device-DEPENDENT.  The CSS3 key-equivalent property[1] seeks
to address this problem, since different values can be specified for
different media, and using Media Queries[2], for devices with different
capabilities.  This allows for more device independent content (XHTML) which
can then specify a multitude of style sheets tailored for particular media
and classes of devices.

With navindex - I partially agree.  I agree that navindex may in some cases
be device-dependent.  But I think it is also possible for authors to simply
use navindex to represent the abstract overall sequential navigation order
for user interface elements of a page.  How that order is used on a
particular device is left up to the user agent.

However, I do think navindex may tend to be more device-DEPENDENT than
independent, and thus there is also the CSS3 nav-index property[3] to help
address this problem (in a similar way as that explained above).


> 
> Section 6.7:
> Image maps seem to be unchanged, which is a bad thing.

In my opinion, these are still in progress.  So feedback (as you gave below)
on image maps is helpful.


> For one thing, 
> the power of XML could sure be used to improve the shape and coords
> attributes

What does XML have to do with shape and coords?  XML is about annotated
trees of data.  That has nothing to do with shapes and coordinates.

> to something that could describe a shape better (say, a la
> SVG)...

Perhaps.  Certainly it may make sense to at least make that possible.  It
may not however be the "simplest" solution, and thus we should keep an eye
open to alternatives for "typical" usage scenarios.


> But then, most consider image maps to be a turn-off, so why keep it at
> all?

Because even if most consider image maps to be a turn-off (which I'm not
sure is even true), if some consider image maps to be useful/essential they
should likely be kept.  Those that don't like that can simply opt to not use
them.

> style Attribute:
> Sorry, but I can see people abusing this to defy the purposes of XHTML.
> I'd like to see this dropped.

Just because something can be abused is not sufficient justification to drop
it.  In such cases, certainly guidance should be provided to steer folks
away from such abuses.


> address Element:
> I'd call this either a metadata element or a footer element.  address
> just sounds wrong.

How is this data about data?  And address may just be that, an address.  It
does not have to be the address OF something.

Now, that being said, <address> is woefully inadequate to markup typical
address information.  Perhaps someone needs to come up with a vCard XHTML
module (perhaps somebody already has).


> body Element:
> I still think it's just another name for a section element.

But is has its own meaning, and is certainly used as such.


> blockquote, blockcode, code, and quote Elements:
> As I said earlier, it seems like whether something was block or inline
> was purely presentational

And that is incorrect.  The distinction about block/inline is not just about
presentation (see above).  For one, the content model is affected.


> div and span Elements:
> Again, that block and inline thing.  Drop span.  Better yet, drop both
> and leave generic formatting to sections.

But <section> already has a semantic.  It would be tag abuse to use
<section> for something it didn't mean.  Akin to using <blockquote> simply
to indent text.  And see above again about div/span block/inline.


> h1 to h6 Elements:
> Drop them.  The section/h combo has every advantage in terms of
> semantics over them.

I agree with deprecating them, but disagree with dropping them.
They have been tried and true elements that both work and are mostly
harmless.  I would be in favor of deprecating h1...h6, but certainly not
removing them.


> hr Element:
> What's the difference between hr and giving presentation to an empty
> element?  Drop it.

Books often have content that appears to represent a horizontal rule.  At a
minimum, the XHTML 2.0 <hr> element can be used to markup such horizontal
rules.

 
> pre Element:
> Looks presentatonal for its example.  I'd say drop it - I don't think
> it has any semantical relevance.

The whitespace of a pre element contains semantics.

...

> kbd and samp Elements:
> I'd say rename these to input and output so that it can encompass a
> greater range of semantics...

i believe those names would conflict (semantically at least for humans, even
if namespaces are used to uniquify the terms for machines).


> strong Element:
> It's semantically identical to the em element.  Remove it.

As fantasai noted, STRONG means more <em>phasis.

> sub and sup Elements:
> Presentational.  Remove it.

I used to think that too, and was convinced of the contrary.

Elements *do* have subscripts and superscripts which contain meaning


...

> Hypertext Module:
> It's already redundant with Hypertext Attribute Collection. Remove it.

<a href> is still very well known.  It would be a mistake and a shame to
remove <a href>.


> List and Table Module:
> So which is better for a key-value pair?

Good question.  I think it 'depends'.


> link Element:
> Why don't you use something like XLink to put such linking information
> in head anyways?

Because it is more of a pain?

...

Tantek


[1] http://www.w3.org/TR/css3-ui/#key-equivalent
 
[2] http://www.w3.org/TR/css3-mediaqueries/

[3] http://www.w3.org/TR/css3-ui/#nav-index

Received on Friday, 9 May 2003 07:00:43 UTC