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

Patrick H. Lauke writes:

> Smylers wrote:
> 
> > Well it's very close to being useless.  In that if browsers don't do
> > anything with some mark-up, there's no point in having it (and
> > indeed no incentive for authors to provide it).
> 
> Assistive technology is certainly a valid use case here.

Would it work well enough?  Is not being able to distinguish
abbreviations from words a significant problem for developers of such
software?

> > Yes, that is potentially ambiguous.  But it's the same in books,
> > newspapers, and so on, where it turns out not to be much of a
> > problem.
> 
> But books etc don't have any other way of providing
> disambiguation/structure. Under that reasoning, you could argue that
> there's no need for heading elements etc, as simply having text bigger
> works fine in print, so all we need is a font sizing markup option.

Not quite the same, since in order to make the text bigger we obviously
need _some_ mark-up (so there's no advantage in it not being
meaningful).

But here we're discussing having mark-up versus not having any mark-up
at all.

> > What in practice would you expect AT to do with this knowledge?
> > Remember that most abbreviations that aren't being tagged with
> > expansions won't be marked up, so AT is going to have to deal
> > sensibly with that case anyway.
> 
> So you'd prefer hit and miss heuristics over unambiguous
> interpretation?

We're going to have heuristics anyway.  Humans can generally distinguish
abbreviations from words, so it isn't too far-fetched to expect AI to be
able to do likewise.

I can see that unambiguous specification is preferable (if it would
work).  But I don't understand why of all the problems trying to
pronounce human languages correctly this particular one is the one that
gets additional help from HTML.

Smylers

Received on Monday, 21 April 2008 18:09:03 UTC