Re: WD-xhtml2-20021211 comments

Alexander Savenkov:
> Hello Christoph,
>
>> 8.1. The abbr element
>> Should the title attribute be used for the spelt out version of the
enclosed
>> term, e.g. for aural UAs, or does it need an extra attribute? I sometimes
>> want to provide also the translation of an abbreviation, but if I put it
>> into the title attribute, a speech synthesizing browser might read both,
but
>> shan't. Example: <abbr title="id est" replace="that is">i. e.</abbr>.

Actually "alt" was introduced for such tasks back when img was still around.

> I'd say this is not a good solution. It's the task of aural UAs to
> generate the correct pronounciation. [...]
> <abbr title="id est" xml:lang="la">i. e.</abbr>

That's what I use with XHTML 1.x now. "i.e." is a common abbreviation in
English that could be spoken out as "that is" or "id est" either way and
should be understood by most people, thus was a bad example. But my main
point is, that I use title on other elements for different tasks than
providing a substitute. It's inconsequent to use it as such on abbr.
New example (in German):
<p xml:lang="de">Die <abbr xml:lang="en" title="Organization of Petrol
Exporting Countries" alt="Organisation Erdöl exportierender
Länder">OPEC</abbr> hat eine Verringerung der Erdölfördermenge
beschlossen.</p>
Although you'd probably rather read "Opeck", but how does a aural UA know
that this is actually an acronym, i.e. an abbreviation / initialism that's
spelled as one single word?
Or imagine abbreviations whose actual meaning is different from the word(s)
you use to substitute it normally:
<abbr title="Union of Socialist Soviet Republics" alt="Soviet
Union">USSR</abbr>
Although you might spell it "Yoo, Es, Es, Ar" as well.

My sole point is that there should be put some more thought into abbr.

> Another example: whenever a clever aural UA comes across
> <abbr title="et cetera" xml:lang="la">etc.</abbr> in the text it
> pronounces "and so on" for an English user, "und so weiter" for you,
> and "i tak daleye" for me. On the other hand if we had set it not to
> change the native pronounciation we all would hear "et cetera".

Actually I'd expect "und so weiter" from <abbr>usw.</abbr> but "et cetera"
from <abbr>etc.</abbr>, at least in German.

>> 8.4. The code element
>
> As for me I see no use for the <pre> element. Poems could be marked
> with <l>s, while pieces of computer code with <code> and appropriate
> style rules.

How to mark-up excerpts from RFCs or Usenet articles, which are written in
well defined, fixed width plain text? Or poems that require certain letters
at certain positions (there are some which create some kind of ASCII art, if
written correctly)?
The need for pre is becoming less, but it's still there.

>> 9.1. The a element
>
> I wonder if the WG would dare to remove the <a> element. Three (3)
> elements carrying no semantics and having the same purpose is
> excessive. I'm talking about <div>, <span> and <a>.

Or at least require the id attribute to resemble its original meaning
"anchor". Or remove span instead and say the a stands for -er- something
different than "anchor".

>> 10. XHTML List Module
>
>> name ist not only a bad choice,

According to
<http://hades.mn.aptest.com/cgi-bin/voyager-issues/XHTML-2.0?id=6196> it's
been renamed to label, already, but wasn't changed in the latest published
WD.

>> Why not use h or caption instead?
>
> Or why not make it an attribute of <nl>?

No. Text to be displayed shouldn't be content of an attribute, but an
element itself. Thus it's even visible after minimal XML parsing, i.e. tag
removal.

Christoph Päper

Received on Monday, 16 December 2002 07:28:51 UTC