253012 - acronym should have "font-variant: small-caps;"

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, defect)

Description

[fantasai]

As suggested in the CSS 2.1 sample HTML style sheet, <acronym> should be given
"font-variant: small-caps;". This is a pretty well-established typographic
distinction. Unlike the sample stylesheet, however, <abbr> should not.

Fix: add
  acronym {font-variant: small-caps;}
to html.css

Comment 1

[fantasai]

Attachment: testcase

Comment 2

[Justin Wood (:Callek)]

Attachment: html.css addition

This does exactly what fantasai suggested.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is this really something that should apply to all acronyms?

Comment 4

[Bill Mason]

(In reply to comment #3)
> Is this really something that should apply to all acronyms?

I would personally argue that there's no reason to.  It may be a
well-established *print* distinction, but it's not a web one.  I can't think of
any site in the wild I've ever seen using it except ones demonstrating the W3C
style sheet.

It sort of smacks of the 1.0 release of Safari, that made all ABBR and ACRONYMs
italic by default.  All that did was force everyone who saw it to add another
rule to their CSS to undo it.

For better or worse, existing UA CSS has set the expectation for the standard
ABBR and ACRONYM font styling to be no styling.  I think it's too late, and
meaningless, to buck that trend.

Comment 5

[Justin Wood (:Callek)]

Its not my call on "if we should" though I added this since it is a new bug with
testcase, cant hurt too much imo, but it is ultimately up to module owner.

Comment 6

[fantasai]

What Safari did was stupid. It had no basis in either print or web typography,
and it adversely affected a lot of pages. ACRONYM is less used than ABBR. When
used correctly, it marks pronounceable acronyms, which should be small-caps by
typographic convention. In the cases where it's used incorrectly, the element's
text is typically all upper-case anyway, so there wouldn't be a noticeable
difference.

Comment 7

[Bill Mason]

(In reply to comment #6)
> What Safari did was stupid. It had no basis in either print or web typography,

What this bug proposes has no basis in existing web typography trends, save one
non-normative sample style sheet.

> and it adversely affected a lot of pages. ACRONYM is less used than ABBR.

Anecdotal evidence suggests the exact opposite, since people use ACRONYM to get
the tooltip in IE that you don't get with ABBR.  See:

http://www.accessify.com/tools-and-wizards/acrobot/why-you-should-use-acronyms-and-abbreviations.asp

http://diveintoaccessibility.org/day_17_defining_acronyms.html

http://www.mezzoblue.com/archives/2003/08/04/conversion/comments/#c000890

> When used correctly, it marks pronounceable acronyms, which should be
> small-caps by typographic convention.

The web is not print is the standard response/cliche one inserts here.

> In the cases where it's used incorrectly, the element's
> text is typically all upper-case anyway, so there wouldn't be a noticeable
> difference.

Right now when it's used, *correctly or not*, it appears with the font
properties it inherits from its surrounding text or that are specifically
assigned to it, and are typically not noticeable as unusual variations from the
surrounding text. What is proposed here is a *noticeable* difference from that
de facto norm/author expectation/standard UA behavior to date (Safari excepted),
and it has not demonstrated that it accomplishes anything to do it.

Comment 8

[Justin Wood (:Callek)]

We already have abbr and acronym stand out from surrounding text, dotted underline.

So far since I wrote the patch my internet browsing has shown no ill-effects of
this change, if it harms some of the top-100 we can just as easily back this out
imo, its a minor change.  And like many other additions/changes in the past,
also a religeous (so to speak) one with some people.  I am ok with whatever is
eventually chosen, but on a personal note I feel this is both needed, and
helpful.  (besides small-caps doesnt make [x] loose semantic value, just makes
it exactly that, small-caps).

Comment 9

[Bill Mason]

(In reply to comment #8)
> We already have abbr and acronym stand out from surrounding text, dotted
> underline.

Which is (1) not the same as changing the font and (2) only applied when those
tags have title attributes.

> So far since I wrote the patch my internet browsing has shown no ill-effects
> of this change, if it harms some of the top-100 we can just as easily back
> this out

No one has claimed it would harm a web site.

> imo, its a minor change.

One could make the same generalization of Safari rendering this tag in italic.

> And like many other additions/changes in the past, also a religeous (so to
> speak) one with some people.  I am ok with whatever is eventually chosen, but
> on a personal note I feel this is both needed, and helpful.

Needed why?  Helpful how?

> (besides small-caps doesnt make [x] loose semantic value,

No one has made that claim.

> just makes it exactly that, small-caps).

By that standard, one could argue for the <BODY> being assigned small-caps by
default.

Comment 10

[Hixie (not reading bugmail)]

I agree that this seems gratuitous, especially given that few authors understand
the distinction between the <abbr> and <acronym> elements, and will thus use
them interchangeably. (This is emphasised further by XHTML2's use of only one
element, and IE6's support for only one element.)

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Per discussion above, wontfix.