LOL, it doesn't support it. It just has some of the strangest HTML parsers ever created.
Okay, that is a bit strange!
Do you notice any differences besides the background color?
Uhm, no. Am I missing something?
err, IE6 / XP shows 2 different background colours, Firebird .7 shows no bgcolor.
Damn, I thought my readers would have read abbr-cadabra.
Nuttin' unusual in Safari.
I guess "abbr" is a red herring here, as - I assume - "abbb" or "baaa" or anything else would do the same. :-)
The fuss and bother over "abbreviation" and "acronym" leaves me indifferent.
People make a distinction on the basis that there are two tags, but then force a meaning on these tags that a careful reading of the spec. shows they were never intended to have. This on the basis that that is the way the words are defined in (some) dictionaries. But I don't interpret, say, the tag "body" in terms of a dictionary defintion of "body", but in terms of how the tag is intended to be used as defined in the spec. For good reason: if I did the former, my pages might not display. Because there is no problem of this sort in the case of two "parallel" tags, people fail to notice that this is what they are also doing in this case. I assume that Microsoft did not bother to implement "abbreviation" because "abbr" - as the spec. intends it to be used - is less likely to be encountered.
Gez Lemon, who knows a lot about screen-readers, says the most popular one works these things out for itself: if it can, it pronounces such a "word"; if not, it spells it out. That would have been better and simpler - let the software take care of it (the programmers have probably given more thought to such problems than us anyway); have one tag only for all sorts of abbreviation as with XHTML2.
I assume that Microsoft did not bother to implement "abbreviation" because "abbr" - as the spec. intends it to be used - is less likely to be encountered.
Unfortunately, the spec got the definitions of abbreviation and acronym confused. Why couldn't Microsoft seek a clarification, or play it safe by including abbr anyway?
Since acronyms are merely a subset of abbreviations, it defies common sense to exclude them from the DOM in the way that Microsoft has. I cannot understand why Microsoft hasn't rectified the situation in one of its releases or service packs. Such an addition would be backward-compatible, so why not just get on with it?
The fact that XHTML 2.0 supports abbr and not acronym is a good thing. It will mean that Microsoft will be forced to implement abbr to render the new language in future browsers. If that happens, it will almost certainly be made available in the rendering of earlier flavors of markup languages as well.
As far as XHTML 2.0 is concerned, I have always thought that abbr should have an optional type attribute. CSS attribute selectors then provide a mechanism for altering aural (and visual) styles to suit any flavor of abbreviation.
As far as XHTML 2.0 is concerned, I have always thought that abbr should have an optional type attribute.
Me too, but not type. type is reserved for specifying mime types (ie: <script type="javascript">). Possibly sort, but that's a little obscure. So I went over to Thesaurus .com, and searched for sort. Anyway, the synonyms it produced:
I've emphasised the ones I believe are suitable candidates.
LOL. I think species sounds pretty cool. Actually, perhaps subset would be appropriate.
Damn, I thought my readers would have read abbr-cadabra.
Ah, the test makes a lot more sense now. The point is that there is no difference.
By the way, guys... mark up your "LOL's" properly, please. <acronym title="Laughing Out Loud">LOL</acronym>
:P
By the way, guys... mark up your "LOLs" properly
I'd prefer:<abbr subset="acronym" title="Laughing Out Loud">LOL</abbr>
#6
Unfortunately, the spec got the definitions of abbreviation andacronym(sic) confused
This totally misses the point - and really I should not have thought it was that difficult to understand!
The tags as used in a language are to be used as defined in the spec. not as defined in (some) dictionaries. This applies to all tags. The point is laboured, but I'm beginning tyo wonder whether it will be understood.
One tag for the purpose will be enough, for the reason I gave.
The tags as used in a language are to be used as defined in the spec. not as defined in (some) dictionaries.
Actually, the HTML 4.01 specification is actually contradictory in its description of what the acronym and abbreviation elements are for. First of all, the spec says the following:
ABBR: Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.).
ACRONYM: Indicates an acronym (e.g., WAC, radar, etc.).
This would actually be an accurate (albeit brief) description of what they are supposed to do. However, the specification then contradicts itself like this:
Western languages make extensive use of acronyms such as "GmbH", "NATO", and "F.B.I.", as well as abbreviations like "M.", "Inc.", "et al.", "etc.".
The assumption that the abbreviation element is less likely to be encountered is curious, given that the reverse is actually true. It may be true in web documents, but only because Microsoft made the mistake of leaving it out of their DOM. Since all acronyms are subsets of abbreviations, it makes more sense to leave out acronyms.
Ironically, the name Microsoft was created from two abbrviations, microcomputer and software.
It will mean that Microsoft will be forced to implement abbr to render the new language in future browsers.
well, there is a lot of things they already should have implemented and didn't, so i fel a little bit more skeptical towards assuming that there might be possibly some sort of development because of a spec that differs from their universe...