[whatwg] Feeedback on <dfn>, <abbr>, and other elements related to cross-references
Smylers at stripey.com
Mon Apr 21 11:08:53 PDT 2008
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
> > 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
But here we're discussing having mark-up versus not having any mark-up
> > 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
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.
More information about the whatwg