W3C home > Mailing lists > Public > public-html@w3.org > December 2009

Re: Bug 8404 -- taking it to the lists

From: Jeroen van der Gun <noreplytopreventspam@blijbol.nl>
Date: Wed, 2 Dec 2009 23:44:26 +0100
Message-ID: <9945efe50912021444h5696b087y130e2be21bacc0cd@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, public-html <public-html@w3.org>
2009/12/2 Tab Atkins Jr. <jackalmage@gmail.com>:
> True, *but there is still no need to*.  The image+caption is still a
> valid figure according to the spec.  There is no reason to pursue
> workarounds, as no workarounds are necessary.  Just mark it up as a
> <figure> and be done with it.

There indeed is currently no need to. However, requiring figure
elements to be movable instead of just saying it's a common use,
attaches more semantic information to the element that is useful for
special user agents. Speech synthesizers may for example skip reading
the figures to get faster to the main content. The presence of a
figure element then indicates: you do not necessarily have to read
this now to be able understand the text after it. So you can read the
main content before the figure, if you want to.

Take this Wikipedia page as an example:
By marking the large infobox on the right as a figure, the user agent
knows it can jump over it. (If it does jump over it and then finds a
reference to it in the text, then it can always jump back later.) The
same applies to the photo of the actors and the DVD cover: these do
not have to be viewed before the main content can be read. A speech
synthesizers might e.g. simply beep, indicating that a figure is
available, and skip it unless the user presses a key indicating that
it wants to read the figure now.

The above is only possible if the spec guarantees that figure elements
are movable. So I think it should. (If the browser jumps over critical
parts of the main content with a beep, it will be very annoying.)

Jeroen van der Gun
Received on Wednesday, 2 December 2009 22:45:08 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:04 UTC