[html4all] ACRONYM and ABBR

Robert J Burns rob at robburns.com
Sun Apr 27 08:38:12 PDT 2008


HI Gregory,

I like the wiki article you cite. It has some valuable examples and  
some forward looking approaches.

You won't get any disagreement from me on the need to markup these  
abbreviations and initialisms. In the examples that Leif and I  
discussed (e.g., NATO) it was my contention that this would not need  
markup because it is an abbreviated form that does not share the same  
ambiguities as for instance 'Dr.' in the example you gave. Of course  
this implies that authors and authoring tools need to be careful to  
ensure that any potentially ambiguous abbreviations are marked up  
properly. A look at Wikipedia shows their are indeed some possible  
alternative expansions[1], though wikipedia directs NATO the obvious  
NATO without first using the disambiguation page[2]. My contention  
then is that we should be striving for a situation (with proper UAs in  
place) where NATO for the treaty organization could be authored into a  
document without markup while using NATO for any other meaning would  
need markup. Of course using markup would be the safest approach in  
any event.

The wiki article you cite also nicely complements the work I put into  
the wiki article on definitions and abbreviations[3]. That article  
just cited does not anticipate the need you nicely highlight for a  
cross document referencing approach. However, it does suggest the need  
for the opposite as well: that is a way to scope the abbreviations  
within the same document. This scoping could be especially necessary  
when a page includes multiple articles by separate authors using the  
same abbreviations and defined terms, but in different ways.

Next, I feel strongly that another new element is not needed for this.  
I think a better approach than adding an IABBR element would be to use  
the existing ABBR element and to attach the newly proposed attributes  
to that element. In this way, the type attribute could default to 'non- 
initialism'. While the expressed as could default to  
'character' (perhaps).

I guess this goes a bit against the point that abbreviations are  
abbreviations and initialisms are initialisms, but I do not see what  
might be the problem with treating them all as abbreviated forms  
(though with semantic differences as indicated through the type  
attribute). For me this makes sense even in the abstract. However,  
given the goals of HTML5 I think there are further reasons to avoid  
introducing a new element and using new attributes instead. In terms  
of backwards compatibility with existing user agents, the introduction  
of new attributes has no issues and the attributes get added correctly  
to the DOM in every major browser. On the other hand with new elements  
each of the three or four major browsers handles elements differently.  
These new elements would work in Presto and WebKit and fail in IE and  
Mozilla (until those UAs could be updated). So these element problems  
provide yet another reason to introduce new attributes here rather  
than new element or elements. However, I would say again that I think  
the use of the ABBR element while distinguishing semantics further  
through additional attributes is a nice fit for what you're proposing.

Take care,
Rob

[1]: <http://en.wikipedia.org/wiki/NATO_%28disambiguation%29>
[2]: <http://en.wikipedia.org/wiki/NATO>
[3]: <http://esw.w3.org/topic/HTML/DefiningTermsEtc>


On Apr 27, 2008, at 5:02 PM, Gregory J. Rosmaita wrote:

> aloha!
>
> the "title" element is ESSENTIAL and MUST be REQUIRED for ABBR
> for the #implied mechanism not only doesn't work, it is illogical
> when applied to abbreviated forms, as there are many abbreviated
> forms that share the same combination of letters, but which represent
> completely different words/concepts:
>
> ADA can be expanded to:
>
>  * Americans With Disabilities Act
>  * American Dental Association
>  * American Diabetes Association
>  * American Dietetic Association
>  * the programming language "ADA" (named for Ada Lovelace)
>
> what is needed, therefore, to make "title" an OPTIONAL attribute --
> AFTER the first REQUIRED declaration of an ABBR -- is a FOR/ID  
> mechanism
> for reuse of the expansion for the abbreviated form; moreover, there  
> are
> thousands of acronyms that overlap, as discussed in:
>
> HTML Needs Initialisms:
> http://esw.w3.org/topic/HTML/AbbrAndInitialisms
>
> the same re-use problem applies to DFN as well -- if one encases
> an abbreviated form in an abbr without a title, but encases the
> ABBR in a DFN element, then it is the DFN element that needs a
> reuse mechanism, and the optimal solution is not JUST the use
> of title for both, but a reuse mechanism that is universal, not
> merely document specific...  the first instance of an ABBR or DFN
> MUST be glossed with an expansion via the "title" attribute, as
> well as an ID so that further incidents of the ABBR or DFN can be
> bound to an initial expansion; obviously, a means of referring to
> an external resource containing a site-wide table of abbreviation
> and definition expansions is a superior mechanism and that is the
> issue upon which we should be concentrating...
>
> gregory.
> ------------------------------------------------------
> It is better to ask some of the questions than to know
> all the answers.                      -- James Thurber
> ------------------------------------------------------
> Gregory J. Rosmaita, oedipus at hicom.net
>         Camera Obscura: http://www.hicom.net/~oedipus
> Oedipus' Online Complex: http://my.opera.com/oedipus
> ------------------------------------------------------
>
>
> _______________________________________________
> List_HTML4all.org mailing list
> https://www.html4all.org/wiki




More information about the List_HTML4all.org mailing list