On 5/10/03 7:49 AM, "Henri Sivonen" <hsivonen@iki.fi> wrote:
>
> On Friday, May 9, 2003, at 14:02 Europe/Helsinki, Tantek Ãelik wrote:
>
>>> h1 to h6 Elements:
>>> Drop them. The section/h combo has every advantage in terms of
>>> semantics over them.
>>
>> I agree with deprecating them, but disagree with dropping them.
>> They have been tried and true elements that both work and are mostly
>> harmless. I would be in favor of deprecating h1...h6, but certainly
>> not
>> removing them.
>
> I think it is a bad idea to introduce elements into a new namespace
This is the beginning of the flaw in the reasoning.
While XHTML2 may be technically a new namespace, for 99.999% of the web
authoring public out there, it will be the same *conceptual* namespace, that
of "HTML".
I've mentioned this offhand before in this list: if people want to try and
create a brand new super cleaned up and purified language that simply
borrows a few things here and there from HTML, that new language should
*not* be called HTML nor even appear to be.
My understanding is that creating a brand new super cleaned up and purified
language that simply borrows a few things here and there from HTML is *NOT*
the goal of XHTML2, nor part of the HTML working group's charter.
> as
> deprecated. What's the point in introducing something that is marked as
> "should not be used" right away?
Comfort. Adoption. Understanding. Transition.
> Including the h1...h6 elements would add complexity to software that
> needs to deal with XHTML 2 documents.
Hah! Absolutely false. A few lines in a few tables in the code here or
there maybe. But certainly no need for additional complexity in the code.
And more importantly, even if it *did* introduce complexity in the software,
such complexity is *strongly* preferable to complexity in what web
authors/developers have to deal with.
> Consider displaying a meaningful
> outline of a document that mixes h and h1...h6 for example.
There is nothing stopping authors from confusing themselves if they really
want to.
I don't believe XHTML2 recommends mixing the two heading models. I don't
think anyone would recommend that.
Perhaps h1...h6 should be in a separate historical headings module to help
distinguish the two models (and indicate direction).
> I see two reasons for including h1...h6 and neither reason is good
> enough for including those elements, IMO:
Straw man approach.
> 1. Authors who are accustomed to h1...h6 don't want to learn new habits.
>
> I don't think it makes sense to introduce cruft
h1...h6 is not cruft, at least according to *all* HTML standards from the
first HTML[1] through the latest XHTML 1.1[2]. More than 10 years. That's
almost enough reason to simply keep h1...h6 and NOT deprecate them at all.
Perhaps you mean they are cruft because "Their definition is completely
historical, deriving from the AAP tag set."[1]?
> in order to allow
> authors who
> don't want to learn new things to appear as if they were
> buzzword-compliant.
Is this perhaps the real reason? You want to deliberately leave behind
certain classes of authors because their attempt to simply be
buzzword-compliant is somehow offensive. I don't think this is worth
fighting. Such authors will do as they please anyway. Just look at all the
folks sending XHTML 1.1 as text/html.
> If they want to look cutting-edge, there's nothing wrong in
> requiring them to
> learn something new.
Elementary psych. All new is not as attractive as somewhat familiar and
somewhat new (wish I could find the reference - I went to college before
textbooks were hyperlinked). Unless that something new is very very simple
and fits (nearly) seamlessly into what you already know.
> 2. Make it easier to convert HTML or XHTML 1 to XHTML 2.
>
> What's the point in reducing the complexity of a converter
None at all - definitely a straw man.
> to the
> point of
> not actually doing a conversion when the cost is increasing the
> complexity
> of the XHTML 2 UAs?
But this is false anyway, see above.
Thanks,
Tantek
[1]
http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html
[2]
http://www.w3.org/TR/xhtml11/doctype.html