W3C home > Mailing lists > Public > www-html@w3.org > December 2002

Re[2]: WD-xhtml2-20021211 comments

From: Alexander Savenkov <w3@hotbox.ru>
Date: Sat, 21 Dec 2002 17:22:33 +0300
Message-ID: <19118068802.20021221172233@hotbox.ru>
To: Christoph Päper <christoph@paeper.de>, www-html@w3.org

Just noticed the letter went just to you Cristoph, thus posting it
again for the archive. Christoph, please ignore.

Hello Christoph, everyone,

>>> 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.
Well, the lines you quoted here are actually *yours* :)

>> 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.
I quite agree, but then what you need is to rename the attribute, not
to add another one.

> 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?
Now you employed 'alt'. How can a UA know the 'alt' is in German?
Well, you would say that the <p>'s language shows that. Let's look at
the XML1SE more closely [1]:
"A special attribute named xml:lang may be inserted in documents to
specify the language used in the contents >>>and attribute values<<< of any
element in an XML document."
What about specifying the actual prounounciation, please consult [2].

> 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
> Although you might spell it "Yoo, Es, Es, Ar" as well.
I guess most people actually spell "U S S R". If you pronounce "Soviet
Union" I suggest you use <abbr title="Soviet Union">SU</abbr> in the text.

> My sole point is that there should be put some more thought into abbr.
I disagree and invite you to look at the "i. e." example once again.
It fits you pretty well (imo).

>> 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.
A matter of taste ;)

>>> 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.
I don't think so. If you really need those ascii-poems or passages
from some other fixed-width source use paragraphs and CSS. Even if you
make an excerpt from RFC non-fixed you lose nothing. It's just their
style, not their semantics.

>>> 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.
Reminds me of the form elements. Not a good choice either.

>>> 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.
Why that?

I guess everyone agrees that <name> is too ambigious. However making it
<h> as I see would make it even more confusing. I presume a good
idea is to take your <caption> suggestion both for lists (instead of
<label>) and for objects.

Links: [1] http://www.w3.org/TR/2000/REC-xml-20001006#sec-lang-tag
       [2] http://www.w3.org/TR/1998/REC-CSS2-19980512/aural.html#speaking-props

  Alexander "Croll" Savenkov                  http://www.thecroll.com/
  w3@hotbox.ru                                     http://croll.da.ru/
Received on Sunday, 22 December 2002 05:46:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:01 UTC