Re: kelvSYC's Thoughts on the new XHTML Draft

kelvSYC wrote:

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

I thought so also, and agree it should be removed.

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

Also strongly agree, leaving it in just allows for further abuse of it
(ie using it to open new windows)

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

Again, I agree. There's just no point having an extra attribute when a
value works just as well.

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

Worth looking into...

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

Not so sure about that.

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

Calling this metadata would be a mistake, which literally means "data
about/on data". I see nothing wrong with the name, and changing it may
cause undue confusion.

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

I disagree, it is the body to the header. Hence the names.

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

I see no reason why not to change the names, your arguement sounds good
to me.

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

Hmm, I'm not an expert on this but most elements have a 'default'
display value, yes? So if neither inline or block, what then? Leaving to
section and making block or inline just replaces div or span
respectively. Although I agree that having to elements that can serve as
generic block/inline elements, I don't believe one element can
reasonably replace them both.

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

Agreed, this element serves no semantical purpose and thus should be

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

I also agree. The only arguement would be for poetry or such, which can
now be done with the l element.

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

I disagree, line-breaks do serve semantical purposes. Although whether
the l element should replace the br element seems to be a hot topic, I
think there should be some form available.

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

Hmm, no I must disagree. Unless there are entities in XHTML2 (which is
unclear to me at this time) for <sup>0</sup> through <sup>9</sup> and
the same for <sub/> I feel that they have a place. The all too common
example is denoting a footnote or H<sub>2</sub>O for example. It's silly
to have to resort to including MathML to do this.

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

Agreed, it's similar to a situation that might occur if there were no
table-rows in the Tables Module (relatively).

> 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 Friday, 9 May 2003 03:21:58 UTC