[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