W3C home > Mailing lists > Public > www-html-editor@w3.org > April to June 2003

kelvSYC's Thoughts on the new XHTML Draft

From: kelvSYC <kelvsyc@shaw.ca>
Date: Thu, 08 May 2003 21:05:37 -0600
To: www-html@w3.org
Cc: www-html-editor@w3.org
Message-id: <1BE3F700-81CB-11D7-9D01-0003931CB8D4@shaw.ca>

Here are my thoughts on the new XHTML draft:

So XFrames and HLink (or XLink) is not part of XHTML2?

Section 3.1:
That example XHTML document defies proper XHTML 2 (in terms of its 
purpose).  A better example is needed.

Inline and Block Modules:
The last time I checked, whether something was inline or block has no 
semantic meaning.  Trying to separate text module elements based on 
(visual) presentation seems to defy the overall design goals of XHTML2.

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

Ruby, XML Events, XForms:
I think the mention of these three are somewhat redundant.  Why don't 
we have the MathML Module or the SVG Module or the (insert your own 
XML-based Module)?  Furthermore, doesn't XHTML 2 allow importing from 
other namespaces (presumably with the exception of XHTML 1) across all 
elements?

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?

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.

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?

rev Attribute:
I don't see the point in having this, when something like rel="reverse" 
might work.  Speaking of which, wasn't there some debacle about XLink 
in XHTML?  This Collection could be replaced with some form of XLink 
implementation...

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

Section 6.7:
Image maps seem to be unchanged, which is a bad thing.  For one thing, 
the power of XML could sure be used to improve the shape and coords 
attributes to something that could describe a shape better (say, a la 
SVG)...

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

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

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

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

blockquote, blockcode, code, and quote Elements:
As I said earlier, it seems like whether something was block or inline 
was purely presentational - thus, why not drop blockquote and blockcode 
and let the context decide its presentation?

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

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

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

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

nr and br Element Suggestions:
I think both are riduculous.  nr makes markup somewhat on the anal side 
(forgive my language.  br is clearly all presentational.

cite Element and Attribute:
I think the entire citation mechanism needs to be reworked.  What if 
someone used print (or generally non-internet) citations?  Currently, 
the cites cannot address this.

dfn Element:
I don't get it.

l Element:
Don't say it is meant to replace br, even if it is.  It will make l 
look like a presentation element, which it isn't.

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

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

sub and sup Elements:
Presentational.  Remove it.

var Element:
I find little use of this, for some reason.

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

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

dl, dt, and dd Elements:
I think this needs to be reworked, as there is currently no way to 
associate a dd with a dt other than their positions.

nl Element:
I'd say devote an element where its contents contain strictly 
navigational information (so, for example, you can skip it in print 
media), rather than using an nl.

label Element:
I'd like to see something like that in ol and ul too.

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

Object Module:
If any element can be some form of basic object, why don't you just put 
param and standby as some form of "universal children" so that any 
element can become an object element, just like any element can be an 
anchor?

content-length Attribute:
As someone said before, you really need a unit of measuerment, and the 
unit should be part of content-length.

noscript Element:
Need a better example.  The current one defies proper XHTML 2.

Section 18.1.3:
Uh... I think that xml-stylesheet PI got left out in the cold...
Received on Thursday, 8 May 2003 23:06:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:17:44 GMT