Re: Brainstorming - abbreviations

Colin Lieberman wrote
> Interesting - I agree completely that most people don't understand the
> difference between acronym and abbreviation, which is exactly why it's
> silly to have both. However, I think a single element with a simple
> attribute "say me like a word" or "say me like initials" would be
> perfectly clear -- certainly more clear than two elements.

I think most people don't understand because it is rarely explained
clearly.  Ignorance of some is not a good reason to increase work (the
proposition requires more typing to accomplish the same task).  At
worst, under the current system, we have a few mislabeled strings.

Abbreviations and acronyms fill two completely different roles.  Because
of this, having both is not a problem.

> I'm not sure how it confuses semantics: An acronym is a subset of
> abbreviations anyway, so the existing model is muddy. A single element
> for the parent type (abbreviation) that doesn't distinguish is, I
> feel, more semantic. The pronunciation switch is not involved with any
> acronym/abbreviation distinction.

It's not muddy at all.  Even if acronym is a "subset" of abbr (it could
be argued either way), they perform two completely different tasks.  An
abbreviation is a shortening of a word (e.g. vs, cont, mgmt, mr, mrs).
An acronym is a shortening of a group of words to form another "word"
(e.g. RADAR, LASER, NATO, SQL) or shortening to initials (e.g. W3C,
HTML, CSS, eg, ie, LOL, TLA - three letter acronym ;).

Since I write mostly about the web, I use acronym FAR more than I use
abbr (and I use acronym at least 3 or 4 separate times, marking up the
first instance only) and I would bet that most people have more need for
acronym than abbr.  So, the proposition has doubled the work I need to
do just to markup three letters semantically.  It's already annoying
enough.  Let's not make it worse.

Idealistically, the proposition is great.  In practice, I'd probably
quit marking up acronyms altogether out of irritation.  Instead, I'd use
the more traditional method: "HyperText Markup Language (or HTML)"

An optional "pronounce" attribute wouldn't be bad.  However, I don't
know how screen readers would behave.  As of now, do they simply read
the title attribute or do they read the abbreviated text in the element
with the option of reading the title?  If the former, how would it
decide whether to read the "pronounce" or the "title"?

Further, Apple, for example, has hard-coded in some strings that are
said in specific ways (e.g. "iPod" is said "eye pod" where Microsoft's
TTS says "eep odd").  These match typical pronunciations and are
designed to offer a better user experience.  I don't know if other
screen reading
technologies behave this way, however.  If the person doing the markup
pronounces the word in an odd way, it might end up being more confusing.
For example, a guy I knew in college called DR-DOS "Doctor Dos" where
I'd always referred to it as "D.R. Dos" in much the same way people say
"M.S. Dos".  It took me five minutes before I realized what he was
talking about.

The pronounce feature would also have to take into account the nuances
of the TTS engine.  Again, Apple tends to say capital letters as words,
where others say them as letters.  For example, if I wrote "I want BOTH
of them", Apple's would read "I want both of them" where some of the
older Windows TTS would say "I want B. O. T. H. of them."  If, the
acronym is recursive, like PHP or GNU, the pronounce attribute still
might be read differently than how the author intended ("PHP Hypertext
Preprocessor" may be read "P-uh-p Hypertext Preprocessor" instead of
"P.H.P. ...").

Anyway, the pronounce attribute may have problems, but I don't dislike
the idea of it.  I do, however, extremely dislike the idea of joining
abbr and acronym.

-- 
Robert <http://robertdot.org>

Received on Thursday, 15 March 2007 17:52:43 UTC