19.07.2011 06:42, Rick Gordon wrote:
Is there any conventional default for <abbr>? I am thinking there is not,
> though perhaps a case could be made for text-transform:uppercase.
There are several default renderings to be considered, especially if you
are about to use <abbr> for something that isn't an abbreviation and you
wish to prevent any default styling. Although text-transform: uppercase
is not among those that seemed potentially relevant to me, it would be
an understandable (though completely wrong) default rendering feature.
(Who would want <abbr>e.g.</abbr> to be rendered as E.G.?) So abbr {
text-transform: none } could be a useful precaution - perhaps just
hypothetical, but cheap. Now to the things I had in my mind...
1) Several modern browsers draw a dotted bottom border at least if the
element has a title attribute. So it's safest to say
abbr { border: none }
2) Some versions of Safari have been reported to use italics for <abbr>
by default, so add
abbr { font-style: normal }
3) Some old CSS specifications suggest, when describing what they call
default style sheet for HTML 4, the following:
ABBR, ACRONYM { font-variant: small-caps; letter-spacing: 0.1em }
That's nonsense, not implemented in any browser I heard of, and absent
in the CSS 2.1 specification that was eventually approved. But it still
does not hurt to kill it explicitly, just in case some odd browser took
it seriously:
abbr { font-variant: normal; letter-spacing: 0; }
Ultimately, you might even consider using some "overall reset" settings
for any element that you intend to use against its specifications. The
point is that some day someone working on a browser might get a
particular idea of how abbreviations are best rendered and might
implement it as part of the browser's default style sheet for <abbr>. It
might or it might not disturb pages that use <abbr> for abbreviations,
but the odds are much higher that it could ruin the use of <abbr> for
something completely different.
> iBooks
> will ignore font/font-family properties in body-text tags such as
<p>,<li>, etc.
> UNLESS they are properties of a child inline tag OTHER THAN <span>.
Sounds odd, but not completely unexpected, the human nature being what
it is.
So in the service of sacrificing the least needed inline tag for this
> non-semantic hack, I use <abbr>.
Browsers or search engines are not known to pay attention to <abbr>,
except for the possible default styling, so that's in practice fairly
safe, if you just nullify default styling.
But if you intend to style your <abbr> elements (and I wonder why else
you would be using them), there's the problem that IE up and including
IE 6 does not even recognize <abbr> markup, in CSS or otherwise.
Others use <cite>, <samp>, or <acronym>, but to me, each of these
> has default style which must be overridden, and are more semantically
valuable.
They have semantics, but this is mostly just wishful thinking, as
browsers and search engines don't care about it. The <acronym> element
has issues similar to <abbr>. The <cite> element is effectively <i>,
just theoretically with a semantic meaning. The <samp> element may imply
default rendering oddities, including monospace font, and some automatic
translation software treat its content as "do not translate" (a rare
example of applying HTML element semantics, though in a somewhat
doubtful way).
I'd be interested in the opinions of others as to the least offensive
workaround.
I think that if you use the <a> element without href attribute, you can
expect browsers to have no special formatting for it by default. An
element like <a>foo</a> is of course semantically empty, but if iBooks
doesn't know that, <a> might be your man... your element. It's even as
short markup as you can get.
The use of <a> as a general-purpose text-level element might conflict
with style sheets that naively assume that every <a> is a link. But I
don't think this is a problem with _browser_ style sheets - they can be
expected to use :link and :visited instead, or maybe a:link and a:visited.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
______________________________________________________________________
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
