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

[Smylers]

Nicholas Shanks writes:

> 2008/4/23 Ian Hickson <ian at 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.

Possibly that would useful for web authors.  But it wouldn't be any sort
of 'validator', since the reason that expansion-less abbreviations are
permitted in HTML 5 is so that abbreviations may be styled in a
particular way (for example with small caps).

That is therefore a valid thing to do whether or not the abbreviation
happens to be expanded anywhere else in the document.  

> > 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?

No; <abbr> with an expansion is useful, particularly for abbreviations
coined by the author which readers may not be in a position to otherwise
know, or to look up elsewhere.  And there are user-agents which make the
expansion available.

> > 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.

That is very methodical; it ensures that every point brought up gets
considered.

> If we want to do this properly we need to ensure we have covered every
> aspect from the beginning.

You want Ian to consider points that haven't been raised?  Surely the
best way of doing that is simply to raise those points?

> Set up a focus group or something :)

What could a focus group say that people can't do here?

> > > 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.

It has?  Please could you give an example of an existing webpage which
successfully uses an <abbr> element without a title and which an
existing user-agent does something useful with that.

> > 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.

Why would a user-agent that isn't speaking need to correctly identify
it?

> And to the person who suggested it be written in lowercase, I
> explicitly said it was a newspaper headline.

That was me.  Sorry, I interpreted that to mean a headline on a
newspaper's website; I hadn't realized you meant transcribing from a
printed newspaper.

> 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).

On that basis one could argue for not transcribing it at all, but
instead including it as a giant image, to avoid any other changes.

Or that headings shouldn't be marked up with <h1> and so on but simply
with by setting the appropriate font, since otherwise a browser may not
style the <h1>s appropriately.

(Conversely, one could argue that what's important is to transcribe the
semantics, and where that includes 'headlines are normal sentences but
the house style is to display them in all-caps' then it's reasonable to
mark them up as I suggested.)

If the aim is simply to reproduce the printed page exactly then the
original doesn't have any out-of-band indication as to whether "BAR" is
a word or an abbreviation (or indeed both, as a pun); why should the web
representation?

Smylers