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. 


Agreed.

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

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


Agreed.

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