Re[2]: Comments on XHTML 2.0 Working Draft

Hello Mark, Jonny, Jonas, everyone,

>> 8.1. The abbr element and 8.2. The acronym element
>> ---------------------     ------------------------ Can someone
>> explain me why there are still two elements for the same purpose? As
>> Steven Pemberton once mentioned 'There is a long dull discussion on
>> what is an acronym and what not'. Was there one?

Mark Gallagher:
> I don't remember if there was one *here*, but there've been many on many
> lists.  Check out <http://www.m-w.com/> and save yourself some time :-).
Not that I wanted to carry on one of those discussions here, I was
simply asking whether this issue has been considered in the WG or not.

> ABBR and ACRONYM serve different purposes, in theory.  An acronym is an
> abbreviation formed of the first letters of a phrase, pronounced as a
> word (e.g. ANZAC, or QANTAS).  So, an aconym is an abbreviation (and
> technically one can use <abbr> to define one), but an abbreviation is
> *not* an acronym.
Exactly, Mark.

First of all, these elements are language dependent: in Russian,
for e. g., there's no distinction between acronyms and abbreviations,
all such words are abbreviations, though there's *another* kind of
abbreviations which is widely used, these are so called
'compounded-abbreviated' words ('kombat' stands for commander of the
battalion). XHTML, to my mind, should make no distinction between
various abbreviation types, otherwise the markup language can be
burdened with language-specific elements (or attributes).

Secondly, I'm not a native speaker, thus (Mark, take no offence)
I am used to normative sources, i. e. Longman's DCE [1] states that
an acronym is 'a word made up from the first letters of the name
of something such as an organisation', an abbreviation is
'1. a short form of a word or expression. 2. the act of
abbreviating something', and to abbreviate is 'to make a word or
expression shorter by missing out letters or (hello, Mark) using
only the first letter of each word'. Russian dictionaries (for
instance, [2]) treat abbreviations likewise.

Summary (for those who skipped the previous paragraph):
1. An acronym is a word made up from the first letters of an
expression (no matter whether you believe it should be pronounceable
or not).
2. Abbreviation is either a short form of a word or an acronym.
3. Therefore, if one of these elements is ever dropped from the spec
for the reason of being presentational let it be 'acronym'.

Hopefully, I persuaded most of you, especially (may I drop dead if
not) the members of the WG.

>> 8.5. The br element
>> -------------------
>> I agree with Jonas here. What's the purpose of having a deprecated
>> element in a document explicitly marked as backwards-incompatible?

Jonny Axelsson:
> The goal for XHTML 2.0 is not to be backwards incompatible, but backwards
> compatibility is is much less important than it was for XHTML 1.0, and 
> should not be used as an excuse not to remove/fix misfeatures just because 
> they have been there before. General backwards compatibility is still 
> necessary, otherwise XHTML 2.0 would not be XHTML, but some other language.
Alright, what's the purpose of the XHTML Host Language document type
conformance definition [3] then? I mean, can you point out at what
exactly prevents the WG from removing 'br' in the subsequent drafts?

Jonas Jurgensen:
>> If backwards compatibility should not be used as an excuse to keep <br>,
>> what *is* the excuse?

Jonny Axelsson:
> This was an argument for deprecation as opposed to removing features
> outright. It is the idea of "fair warning". Noone has said that <br> is
> about to be removed, now we do. Deprecation would make the transition
> easier.
Isn't the 'line' element meant to be this warning? At the same time,
the 'img' element was never deprecated, though you cannot argue it is
much more often used then the 'br' (id est an XHTML 2.0 conforming
agent is more likely to come across 'img' on the Web). The idea of
'fair warnings' appears to be a bit inconsistent.

> There is nothing wrong with the deprecation mechanism, slating something for 
> later removal. Though where we could do so with no harm, features have been 
> removed outright. In the case of the list start and value attributes, 
> deprecated features are back in.
Excuse me, Jonny, do you mean XHTML 1.0 Transitional and XHTML-Mod?
As I see it XHTML 2.0 is based on XHTML 1.1 which is based on
XHTML 1.0 Strict which is free from 'start' on 'ol' and 'value'
on 'li'. If XHTML 2.0 is about to return to these attributes I guess
it's worth writing that it *is* meant to be backwards-compatible and
*is not* meant to use stylesheets.

>> 17.1. The hr element
>> --------------------
>> While it's clearly explained why the 'sub' and 'sup' elements are left
>> in the spec, no reason provided for the 'hr' element. I doubt there
>> are languages using horizontal rule, and since HTML 2.0 [3] I haven't seen
>> any intelligible explanations. I kindly ask you to provide
>> reasoning for keeping 'hr'.

Jonny Axelsson:
> hr is having a precarious existence right now. I suspect a "Save the hr!" or 
> "Kill the hr!" campaign could have an impact (send your campaign funds 
> to...). Is it purely decorational, does it have some semantic meaning as a 
> separator element, or is it simply too convenient or entrenched to remove?
Just to add fuel to the flame (right you are Jonny, fights are
expected), 'hr' seems to be purely presentational no matter what media
you use. Is there a need to remind everyone of the means to avoid 'hr'
usage (read: CSS)? With the introduction of 'section' and other
structural constructs (eliminating the need for 'div's and such), 'hr'
represents an absolute anachronism.

Links: [1] ISBN 0 582 23751 3
       [2] ISBN 5-85270-324-9
       [3] http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/conformance.html#s_conform_document_type

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

Received on Wednesday, 7 August 2002 15:00:23 UTC