Re[2]: XHTML 2.0 considered harmful

Hello Tantek, everyone,

> On 1/14/03 3:56 AM, "Christoph Päper" <christoph.paeper@tu-clausthal.de>
> wrote:

>> 
>> Tantek Çelik:
>>> 
>>> In case anyone here hasn't seen this yet, if you have any interest in
>> XHTML
>>> 2.0, Mark Pilgrim's frank comments are worth a read:
>>> 
>>>  http://diveintomark.org/archives/2003/01/13.html#semantic_obsolescence
>> 
>> Actually it's full of misunderstandings.
>> The removal of cite (without explanation / alternative) is IMHO an error. I
>> already pointed out my feelings about q/quote and abbr/acronym. I'm happy
>> that img etc. are gone in favor of object. line/l is also much better than
>> br and h+section better than h1-6.

> I too prefer <L> over <BR>, but why not just keep <BR> and deprecate it?
Why not just use HTML or XHTML 1.x? Many authors on this list are
tired of endless deprecations and promises. They are aware of the
"forthcoming lack of support" for XHTML 2 and will use it with care.

> Similarly, add <H>,<SECTION> and deprecate <H1>...<H6>?
> And simply deprecate <IMG>.
What about <IMG>, the HTML 4.01 spec clearly advised you against using
it [1]. There was a warning. Now it's gone, why are you asking for
deprecation?

>> | they told me to use the latest standards available,
>> 
>> The linked W3C document actually says: "Use W3C technologies when they are
>> available and *appropriate* for a task and use the latest versions *when
>> supported*." (Emphasis mine.)
>> 
>> | Not deprecate it slowly over time, mind you, but just fucking drop it.
>> 
>> There's no need for deprecation in a not backwards compatible language.

> And perhaps that is one of the cruxes of the problem.  There have been too
> many statements made of the form "We don't need to worry about FOO because
> XHTML 2.0 is not a backwards compatible language".  These are a few
> examples.  The lobbying to use cumbersome XLink syntax in an end user
> document format is another.  "not backwards compatible" has become the most
> abused cop-out for bad design in XHTML2.0.
Now you're advocating the lack of XLink. May I surmise that the
typical "end user" is not going to edit XHTML 2 by hand? Hand authors
will surely continue writing documents using the new language. What you
call "bad design" is actually good design (see comments above), there
always be a certain number folks who misuse markup. That's not a reason
for spoiling another language.

>> He doesn't seem to have realized that the major problem of XHTML in practice
>> is, that it isn't supported by the major browser.

> Why is that "the major problem"?

>> Thus it's a good thing he
>> returned to HTML4, although for the wrong reasons. He should have read
>> <http://www.hixie.ch/advocacy/xhtml>, too.

> I think he has (go read back entries on his blog).

>>> I think there needs to be a serious reconsideration of XHTML2
>>> as an effort at all.
>> 
>> It should clearly be considered and advertised as a long term project.

> And given lower priority than...

>>> I'd rather see efforts spent on HTML4/XHTML1,1.1,Basic errata
>>> and test suites.
>> 
>> I agree that those shouldn't be considered final; e.g. there should be HTML
>> 4.1 with SHORTTAG NO etc., resembling current browser behaviour like CSS
>> 2.1.
> Precisely.
These definately worth reconsidering, but is this a weakness of the
HTML WG or the W3C Process document itself? According to it the W3C
Recommendation is the final, solid, and *stable* document.
Recommendations never change except for the errata, though some of the
errata (e. g. Ian's findings in XHTML 1.0 SE) is somehow changing the
Recommendation. If by any matter of means the third edition of XHTML
1.0 is going to appear, it will greatly differ from the "first
edition". I'm not touching upon Namespaces and XML here.

>>> [2] XHTML2.0 dumps harmless elements which folks have found
>>> semantically useful.
>> 
>> Which (except cite)? IMHO it's right to drop unneeded elements even if
>> they're "harmless".

> It's harmful to drop harmless elements.  At a minimum it makes sense to
> deprecate them first.
Not quite. At a minimum it makes sense to advise users not to use
them. Which was done in HTML 4.01. It's also harmless to endlessly
burden the language with a bunch of tags "for everyone".

>>> It also dumps the extremely useful 'style' attribute
>> 
>> Except for quick-n-dirty CSS test suites I can't see any use for it.
> Then don't use it.  Plenty of other authors do see a use for it.
If you actually think there's a "plenty" of other authors (strike me
off the list of those), what do you propose? To vote? :) It looks
like the W3C tries to find the *reasonable* consensus, not the one
that completely satisfies everyone.

>> It's
>> fully replacable by id + CSS, too.
> Only superficially.  Using id does not actually capture the full
> capabilities of the 'style' attribute.
That's something new for me, and for most other folks here as well I
guess. What worries me is that you, Tantek, is the author of "Syntax
of CSS rules in HTML's 'style' attribute" [2]. Are you sure you have to
protect your child (which you undoubtedly were hardly working on) if
it's time to sacrifice it in favor of the new tech? No one is
preventing you from using earlier markup languages.

It appears to me that instead of attacking the new language which
finally is going to be free from worn-out (outdated, useless,
stylistic, ...) stuff one have to calm down and count advantages and
disadvantages of backwards incompatibility in the case of XHTML 2.

Links: [1] http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html
       [2] http://www.w3.org/TR/css-style-attr

Kind regards,
---
  Alexander "Croll" Savenkov                  http://www.thecroll.com/
  w3@hotbox.ru                                     http://croll.da.ru/

Received on Tuesday, 14 January 2003 10:39:02 UTC