Re: kelvSYC's Thoughts on the new XHTML Draft

Tantek Çelik:
> On 5/8/03 8:05 PM, "kelvSYC" <kelvsyc@shaw.ca> wrote:
>
>> 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,

Mostly quick hacks, CSS test suites and doubtable use of HTML as a
copy&paste meta language surrogating RTF etc.

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

Reads to me like: "I'm lazy, I want to keep it! Some stupid nerds don't
agree with me." Sorry.

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

I hate to have to agree, because it's often responsible for messier UIs.
However, the pre-defined values from HTML (_blank, _parent, _top) don't have
to be kept. They're neither needed by XHTML2 directly nor by XFrames.

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

Currently it has to be information about the author of the current document
or part thereof. I think this is to narrowly defined, too.

> Perhaps someone needs to come up with a vCard XHTML
> module (perhaps somebody already has).

Hm, there's <http://www.w3.org/TR/vcard-rdf>.

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

I think that elements that can be both, block and inline level, are weakly
designed. OTOH an element for longer passages of sourcecode was much missed
and only inadequately faked by "<pre><code>".

I can see a demand for blocksamp too, which would not only allow sample
output in it, but more generally usage examples.

Nevertheless, if I was the [hypothetical] dictator of XHTML2, I'd rename all
blocklevel element names to start with a capital letter. Thus the 'block'
prefix wouldn't be needed anymore:

  8.1. The Address element
  8.2. The Code element
  8.3. The Quote element
  8.4. The Div element
  8.5. The H element
  8.6. The P element
  8.7. The Samp element
  8.8. The Section element

('hr' dropped, because in my book identical to an empty 'Section',
 'pre' ... 'P' or 'Code' with xml:space="preserve", 'h1'-'h6' gone.
 Unsure about 'body', 'table', 'ul' etc.)

>> h1 to h6 Elements:
>
> I agree with deprecating them, but disagree with dropping them.

Good enough for me.

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

I agree, it's most likely identical to "<section/>", sometimes "<p/>" or
"<div/>". Just like 'br' and "<l/>".

> Books often have content that appears to represent a horizontal rule.

Is it really content? I think it is like a blank page, something that can't
be represented with HTML neither.

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

I agree with the idea, but disagree with the conclusion. 'kbd' and 'samp',
like 'address', should be defined in more generality, but needn't be
renamed. 'a' is still short for "anchor", although it's almost ever used as
a link base, not target -- at least since the introduction of the 'id' and
deprecation of the 'name' attribute. I think "<kbd>right mouse click</kbd>"
is totally acceptable.

>> strong Element:
>> It's semantically identical to the em element.  Remove it.
>
> As fantasai noted, STRONG means more <em>phasis.

I believe that subthread definitely has shown that "em em" is not exactly
equal to "strong". If one wanted to remove 'strong', it would be better
mapped to something like '<em weight="strong">', '<em level="2">' or the
like.

>> sub and sup Elements:
>> Presentational.  Remove it.
>
> I used to think that too, and was convinced of the contrary.

Although I wasn't quite convinved, I now believe they provide the most
practical solution. Everything else would just mess stuff up.
But people who write <sup>TM</sup> should be beaten with a stick. (Run
editor of XHTML 1.1, run! 1.0 SE got it right.)

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

Exactly, better remove 'span' in favor of 'a'. They both mean next to
nothing, without an attribute.

Christoph

Received on Monday, 12 May 2003 11:50:07 UTC