W3C home > Mailing lists > Public > www-html@w3.org > January 2003

Re: ABBR support (was Re: Promotion of XHTML)

From: Tantek Çelik <tantek@cs.stanford.edu>
Date: Tue, 07 Jan 2003 09:58:20 -0800
To: Sander Tekelenburg <tekelenb@euronet.nl>, <www-html@w3.org>
Message-ID: <BA4054EE.1EC5D%tantek@cs.stanford.edu>

On 1/7/03 8:03 AM, "Sander Tekelenburg" <tekelenb@euronet.nl> wrote:

> 
> [Changed the Subject header to allow those who weren't intereted in this
> sidestep to kill this thread. Sorry. I should have done this right away.]
> 
> At 04:16 -0800 UTC, on 1/7/03, Tantek Çelik wrote:
> 
>> On 12/31/02 6:10 PM, "Sander Tekelenburg" <tekelenb@euronet.nl> wrote:
> 
> [...]
> 
>> There is no normative (nor even informative) default style sheet rule for
>> ABBR in the HTML4.01 spec.
> 
> True. That applies to just about everything in the HTML 4.01 spec. At best,
> it points to the odd common use. (Like presenting H1 really, really big. How
> imaginative... ;))

Indeed.  However, there are instances where there are specific enough
presentational instructions in HTML4.01 as to consider them an implied
informative default style sheet - where present we have tried to follow
those.

> 
> [...]
> 
> [IE 5.x Mac]
> 
>> so thus we didn't small-caps ABBR (however we did for ACRONYM
>> which results in an "Economist" like styling of ACRONYMs).
> 
> Hm... I never saw that happen, so now that you mention this, I experimented a
> bit more. It turns out IE indeed transforms the text to small-caps, but only
> when the original text is normal. When the original is in capitals, IE does
> not change it to small-caps. That must be why I never noticed this before.
> 
> I don't find anything in CSS 2 that says capitals are not to be transformed
> to small-caps. I suppose this is a bug then?

"don't find anything in ABC ... that says DEF are not to be XYZ ..."

that statement simply means that a UA is free to optionally do XYZ to DEF
because ABC doesn't prohibit it.

it DOES NOT mean that a UA is _required_ to do XYZ to DEF because ABC
doesn't prohibit it.

Proof:

analogous example to your statement:

  I don't find anything in CSS2 that says that all elements should not be
given a default color of orange.  I suppose it is a bug then that UAs don't
make all elements orange.

second example:

  I don't find anything in CSS2 that says that all elements should not be
given a default color of maroon.  I suppose it is a bug then that UAs don't
make all elements maroon.

obviously UAs cannot both be required to make all elements orange, and make
all elements maroon, thus there is a contradiction, and the "double negative
implies a positive" reasoning in the statement is flawed.  UAs are not
required to do either.  There is no such bug.


Sorry for the drawn out discussion of this, but this kind of logic flaw has
been coming up a lot it seems in recent www-* discussions (see recent "XBL
considered redundant" thread - but only if you have _lots_ of time to read
posts which are sometimes both of a 10 yr. old maturity level and
semi-psychotic).  Simply put, you can't prove such a negative statement, you
can only prove the absence of the respective affirmative statement.  Like
this:


What there _is_ in CSS2 is this (sorry I should have given the URL earlier):

 http://www.w3.org/TR/REC-CSS2/sample.html

<blockquote>

 ABBR, ACRONYM   { font-variant: small-caps; letter-spacing: 0.1em }

</blockquote>

For capitals to be transformed to small-caps, there would also need to be a
declaration of "text-transform:lowercase", which is not present in the above
style rule.  You might say that lack of that declaration is a bug in CSS2.
If you believe that to be the case, could you say so in a post to www-style?


> 
> [...]
> 
>>> I suppose that in the strictest sense, you could therefore say Mac IE 5.x
>>> supports <ABBR>.
>> 
>> Precisely.
> 
> Hehe :)
> 
>>> However, when you consider this sentence from the HTML 4.01
>>> specs "The ABBR and ACRONYM elements allow authors to *clearly indicate*
>>> occurrences of abbreviations and acronyms.", [emphasis mine] then maybe it
>>> becomes a bit of a stretch to say that Mac IE 5.x supports <ABBR>.
>> 
>> Not at all.   From your quote:
> 
> [...]
> 
> Yes, I see your point, and I agree that the HTML specs are often poorly
> worded and thus way too open for interpretation, which often leads to
> nit-picking over what was meant (which I'd like to avoid).

In this case it is not a matter of poor wording - it is a matter of no
wording.  There is _no_ wording about the specifics of the default
presentation of ABBR and ACRONYM elements.  There is _no_ such wording to
misinterpret.

> But when I stumble
> upon a case like this, I ask myself why the authors of the spec would have
> bothered to add an ABBR element at all then?

Because semantics and presentation are not the same thing.  HTML defines the
ABBR element so that authors can semantically enrichen their document with
it.  There are many many things that UAs can do with those semantics,
special styling being only one of them.  The other typical example given is
that search engines do special things with such elements that have
predefined semantics.


> After all, following your
> interpretation, why not simply tell authors to use SPAN CLASS="abbr"? Equally
> meaningless. 

A tag is given meaning by the prose of the specification.  Absent any other
source of meaning for the tag, that is all the meaning that the tag has.

There are no specific normative (or even informative) values for the class
attribute that are assigned any meaning in HTML, thus any such specific
values are normatively "meaningless" as you say.  If well chosen however,
they can help provide a small level of informal meaning, just like new XML
tags can.

> Why would the authors of the spec have bothered to create an
> element for this? The only answer that makes sense to me, is that they meant
> for user agents to apply a style to ABBR. They just forgot to mention it ;)

No, semantics != presentation.  And presentation != semantics.

> (Yes, I'm aware that with ABBR, users can apply a User Style Sheet, which
> wouldn't work well at all with author defined classnames. But how many users
> will bother to learn CSS? Plus, the HTML 4 spec doesn't speak of "allowing
> _users_ to [etc]", but of "allowing _authors_ to [etc]".)

User style sheets are intended not only for users themselves to write style
sheets, but for users to be able to _reuse_ user style sheets written by
other users who have bothered to learn CSS.  You don't have to know CSS to
use a user style sheet.  Just how to download a style sheet and set your
UA's preferences to point to it.

Tantek
Received on Tuesday, 7 January 2003 12:42:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:53 GMT