Re: [whatwg] Feeedback on <dfn>, <abbr>, and other elements related to cross-references

2008/4/23 Ian Hickson <ian@hixie.ch>:

>  Summary: I've made the title="" attribute on <abbr> optional again.

Maybe we need a smart validator that maintains a set of abbreviations
it comes across, if an <abbr> with no title attribute is encountered
that isn't in the set of already seen abbreviations, a message is
displayed to the web developer saying the new abbreviation should have
a title.
This would apply to acronym plurals with -s too because UAs might use
similar string hash matching heuristics to expand repetitions of
acronyms.

Once we get outside English's simple case system this will begin to
break down however, as genitive and demonstrative and other cases will
produce different element content.

>  On Mon, 21 Apr 2008, Smylers wrote:
>  >
>  > Why should HTML 5 bother to solve the very narrow case of disambiguating
>  > words from abbreviations, but not solve it more generally to include the
>  > other cases?
>
>  Indeed.

This is a good point. Smylers, do you think we should remove abbr
altogether and leave solutions to ambiguity problems to something
other than HTML?


>  On Mon, 21 Apr 2008, Patrick H. Lauke wrote:
>  >
>  > Assistive technology is certainly a valid use case here.
>
>  Why? It doesn't seem to be the case to me that people using ATs are any
>  less able to work out what an abbreviation is than anyone else.

I think the point is that written and spoken language are not the same.
If I see "etc." written down, I read it as "et cetera" in my mind's
voice, sometimes even as "blah blah blah"!

This usage has nothing to do with disambiguation, and is only
concerned with text-to-speech (even if that speech is unspoken). As
such, these kinds of abbreviations should not be marked up IMO, but
left to the synthesizer's lexicon.


>  On Mon, 21 Apr 2008, Nicholas Shanks wrote:
>  >
>  > We need to go through this more methodically before making a decision. I
> > hope the following aids matters.
>
>  More methodically than
>
>    http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014470.html
>
>  ...? I'm not sure exactly what you have in mind! :-)

What I meant was you were just addressing people's points as they came
up. If we want to do this properly we need to ensure we have covered
every aspect from the beginning.
Set up a focus group or something :)

> > Situations where expansions of abbreviations are needed:
> > It should not
> > be required that the user screw around looking for the acronym with a
> > dotted underline.
>
>  Abbreviations are no more special here than any term of art.

except that HTML in is past incarnations provided a solution. The
difference has already been created. we just have to decide where to
go from here. Maybe we could remove it?! That way abbreviations and
other jargon are on a level field again. I'm not suggesting new
<jargon> element though.


>  I didn't expect any autoexpading at all. Ever, even with <abbr> present
>  with a title="" attribute. Why would one want that?

Well you should expect it. Lots of people *may* want that from time to
time (me included, and I do not require ATs). It depends on the
document i'm reading.

>  That would be really annoying.

To you perhaps, when you already know what's being referred to. I'll
betcha there's been times when you wished someone would stop writing
in an overly shorthand form.

>  We have acronyms and abbreviations for a reason -- to make
>  things shorter! :-)

Not so. In our case it may be to make the written word shorter.
Sometimes it's for marketing reasons, to make things more memorable,
or humorous. And shorter isn't always better, especially in spoken
content.

For the record I pronounce "i.e." as individual letters. I realise it
stands for /id est/, but I would never consider it as an abbreviation
for some English term like 'that means' or 'that is to say'.

>  It's quite obvious that the "BAR" in "RAISE THE BAR" is not an acronym.

Only if you know English. ('you' being the User Agent who has to
decide how to expand/pronounce it). It is not reasonable to expect
UAs, other than perhaps TTS engines, to correctly identify this. And
to the person who suggested it be written in lowercase, I explicitly
said it was a newspaper headline. You should not change the case of
printed material when transferring it to electronic form,
reproductions should be faithful to the original, and use uppercase
characters rather than style transformations (since they might not get
applied).

>  > Erroneous expansion of non-abbreviations that match a previously defined
>  > abbreviation is I think the hardest thing to avoid.
>
>  Why would the user request expansion of non-acronyms?

The user would say "Hmm, not following this essay very easily. Dear
web browser, please expand all acronyms for me."
The UA would then have to decide what is or is not an acronym, if they
are not marked up, this makes the job more error prone and results in
a poorer user experience.

>  Why does probibiting <abbr>...</abbr> without title="" prevent UAs from
>  searching previous <abbr> elements?

In this instance i was referring to use of acronyms without any <abbr>
being allowed.
Now that you have reallowed title-less abbrs, this point is moot.

>  > a) Documents will either mark up every acronym with an <abbr title=…
>  > > tag—user agents that expand these by default (primarily aural as I
>  > understand it) will appear very verbose—or,
>
>  User agents that expand abbreviations by default are poor, IMHO.

Your opinion is respected, but is not unique.
And 'by default' can mean on a per document basis (rather than a
pre-abbr-element basis).

>  > b) Documents will only mark up the first occurrence. UAs that do not
>  > process subsequent occurrences of the abbreviation (currently all of
>  > them), will suffer from lack of definitions.
>
>  I don't follow this. Why would documents only mark up the first one?

because people can't be bothered typing <abbr title="International
Space Station"> every time they want to use abbr. again, moot as
@title has been made optional.

>  > Using <a> to achieve referencing is a very bad idea, as it will pepper
>  > documents with little blue underlined words and will and up far more
>  > distracting than useful to users. Designers will also hate it, so it
>  > will end up not being used at all.
>
>  That doesn't really seem to follow my experience with the Web. In
>  particular, the HTML5 spec has links all over the place for
>  cross-references, and it works great.

You aren't a designer. You are a technical author. There are
marketeers who want their websites to look good, rather than be
useful. :-)
These people won't accept this, even if they had a semantically-minded
coding guru to make the site.

-- Nicholas.

Received on Wednesday, 23 April 2008 17:37:36 UTC