W3C home > Mailing lists > Public > public-html@w3.org > March 2010

ISSUE-90 Change Proposal

From: Shelley Powers <shelley.just@gmail.com>
Date: Wed, 31 Mar 2010 06:33:33 -0600
Message-ID: <v2r643cc0271003310533sb7194470x97b628ef8655b23b@mail.gmail.com>
To: HTMLWG WG <public-html@w3.org>
Summmary

    Summary: Remove the figure element.


Rationale

The following is the text for the initial bug[1] associated with this Issue:

    Currently the HTML5 specification has an overly broad definition
about what can be allowed in a figure element:


    "The element can thus be used to annotate illustrations, diagrams, photos,
     code listings, etc, that are referred to from the main content of
the document, but
    that could, without affecting the flow of the document, be moved
away from that
    primary content, e.g. to the side of the page, to dedicated pages, or to an
    appendix."


    This is counter to understandings about figure in other businesses and
    environments, where figures are illustrative graphics of some
form. In addition, this
    provides a confusing parallel in functionality between figure and
aside, enough
    so that people are going to have a difficult time knowing which is
which, and
    when to use one over the other. In fact, with this parallelism, we
don't need
    both.


    All assumptions I have read on figure is people assume the element
will contain
    a reference to an image of some form and a caption. Yet caption is optional,
    and it sounds like anything can be included in figure. The
specification examples show a
    poem and a code block, in addition to an image.


    The figure element either should be pulled completely, in favor of the aside
    element, or it needs to have a tighter focus in its definition. It should
    consist of a graphic element, which could be an svg element, a
mathml element,
    an img, an object, or, possibly, a video. It should then have one other
    element, which will be the caption. Since this element won't be a
svg, mathml,
    img, object, or video element, it could be anything, including
just a regular
    paragraph. In fact, a regular element styled using CSS would be the best
    option.


    This change would remove any confusion about this element, and there will be
    confusion. It would also eliminate the problem with having to
create a special
    caption element, just for figure, as discussed in Issue 83.


In a second comment to the bug, I also added the canvas element to the
list of allowable elements. The Editor's rationale for marking the
original bug WONTFIX


    Rationale: I actually agree with Shelley on this, and that's what
HTML5 used to
    say. However, it is one of the very few topics which got a _huge_
outcry from
    Web authors around the Web, demanding that <figure> be allowed to contain
    basically any flow content (including sections, headings, paragraphs, lists,
    etc). That's why the spec says what it does now.


Originally, my interest was only in cleaning up the figure element; to
make it more consistent with standard practice in the print world. The
more closely I examined the element and the discussions about it,
though, the more I felt that we would be better off eliminating the
figure element altogether.

The reason for specialized figure handling in the print world is
because of typographic convention. This doesn't really apply in the
web world, because we have elements that can group, CSS that can
style, WAI-ARIA for accessibility and semantics, as well as other
semantic options. If we want to move the figure away from the text,
but still have the two associated, we can just by linking the two. In
fact, we would have to anyway, because there is no way to associate a
figure element with its text if the two are in separate contexts,
unless they are linked in some way.

There's a good reason for specialized figure handling in the print
world, but not for web pages.  Because we don't have a good
understanding of why we have figure, we can't determine what it should
contain. We only have to look at the discussions about what should be
allowed within the figure element to discover that no one really has a
clear idea of what this element is for, or how it will be used. Well,
other than something with an optional caption, that is tangentially
related to the content of the page (as if "tangentially" has a great
deal of meaning in a web context, considering that anything can be
tangentially related to anything else with the simple addition of a
link).

The figure element, as defined in the HTML5 spec, is also a far
different construct than what was originally intended. The figure
element originated from discussions related to finding a way to attach
a caption to an img element[2], somewhat like the caption we attach to
tables, but allowing markup rather than just text like the table's
caption attribute. I'm not sure at which step in the evolutionary path
it went from a caption to an img, to this all encompassing something
with an optional caption we have today.

I did find emails from Michael Fortin[3][4] and Simon Peters[5][6],
providing use cases for the figure element. Several of the use cases
that Michael pointed out were to Apple online manual web pages. He
classifies the code samples that Apple labels as listings, as figures.
However, the Apple company itself, restricted the use of figure for
illustrative images, only. For tables it used the moniker Table, for
listings, Listing. As such, Apple's own terminology undermines the
credibility of these pages as use cases for allowing actual code
samples as figures. More specific to the point of this change
proposal, if we add a new element for figure, why not for listings,
too? That's also a separate typographical entity in the print world.

Other use cases provided ran the gamut from the pre element for ASCII
art, to actual tables, though we already have a table construct in
HTML. And when we try to limit what's allowed, someone somewhere will
dig up some actual use case online, somewhere, defending the
particular use.

As can be seen, either we allow everything in the figure element in
order to meet all possible sets of existing use cases online, in which
case figure is really nothing more than a variation on the div
element; or we restrict the element to a small subset of allowable
elements, and continually fight the battle of, "Well, what about this?
What about that?" All for an element that, in actuality, doesn't
provide much in the way of semantics or usefulness.

The figure element is really is nothing more than a grouping
mechanism, as was noted back in the beginning of the discussion about
the element[7]. So why don't we use what exists now, rather than
create something new?

I was reminded recently that the WAI-ARIA states and roles are useful
beyond their primary task, which is provide information for screen
readers such as JAWS and NVDA. Other "screen readers", such as search
web bots, like Google's, can also make use of the semantic information
they provide. Among the semantics we can define with ARIA is being
able to assign an image role to a div element, and link the image's
caption to another HTML element.

As an example, in the WAI-ARIA 1.0 specification, there is an image
listing that I modified, below:


<div role="img" aria-labelledby="caption">
  <img src="example.png" alt="Some descriptive text">
  <p id="caption">A visible text caption labeling the image.</p>
</div>


Compare with the figure element:


<figure>
<img src="example.png" alt="Some descriptive text">
<figcaption>A visible text caption labeling the image.</p>
</figure>


There is little different between the two, and the ARIA example has
the added benefit in that it is implemented in many screen readers
today. Best of all, there's nothing about this example that disallows
its use by search bots or other tools and applications, who can then
attach the right caption for the element rather than have to scan the
surrounding text to derive a caption, or using the alt text.

If the figure is located apart from the text that references it,
giving the outer div element an id attribute allows us to link the
figure in the text. If we don't need a physical link, we can use
terminology, such as Figure 1, Figure 2, and relate the text and the
illustration using this approach. There is nothing about the figure
element that changes how the text/illustration are connected—you still
need to link the two, or use the caption, itself, to connect the two.

You don't have to use an img element within the div element. You don't
have to use a div, either. For the pre/ASCII art use case, attach the
role and aria-labelledby attributes to the pre element:


<pre role="img" aria-labelledby="caption">
...
</pre>


It's also a simple matter to style whatever we use, too. For instance,
a CSS setting for the img example could be the following:


[role="img"]
{
  margin: 10px;
  border: 1px solid #ccc;
}

[role="img"] p
{
  margin-left: 20px;
  font-style: italic;
  font-size: .8em;
  line-height: 1em;
}


We could also further annotate the element using one of the three
available semantic annotation technologies available to us: RDFa,
Microdata, and Microformats. In fact, we're overrun with an abundance
of semantic annotation capability—too much so to worry about creating
single purposed elements supposedly for semantic reasons.

Details

Based on the March 4th HTML5 specification, remove Section 4.5.12, on
the figure element. Also remove any additional references to the
figure element. In addition, remove Section 4.5.13, on the figcaption
element, and any reference to it, too.

Impact

Positive

This alternative to figure I've provided in this change proposal is a
frugal one that serves the same purpose for multiple user agents,
multiple audiences, and uses available technology and specifications.
It allows people to create any form of illustration, and ensures
they're accessible.

Removing the figure element and associated figcaption element, helps
trim down the overlarge number of elements that have been added with
HTML5. Each new element we add to the specification has a related cost
when it comes to implementation—not only across browsers, but also
other tools, such as HTML editors, and HTML generation tools.

In addition, encouraging the use of existing HTML, CSS, and ARIA
properties and attributes also encourages reuse over creating new,
which should be a fundamental goal of this group. If there is a strong
rationale for creating something new, and there really isn't a good
alternative, then we can feel justified in creating new elements.
However, in the case of figure, as both Michael and Simon have pointed
out, we've made do with what we have today. We can improve what we
have with the addition of the ARIA states and roles, and ensure both a
semantic and an accessible solution.

Negative

Change will require HTML5 editor time. As far as I know, there is no
implementation of figure in browsers or other tools, and there is no
dependence on it that I can see in web pages. There might have been
some modification to validation tools to support the figure element.

References


[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8404

[2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-November/007859...

[3] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-June/006828.html

[4] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-July/012194.html

[5] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-December/008301...

[6] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-December/008302...

[7] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-June/006822.html


-----------------

Shelley Powers
http://realtech.burningbird.net
Received on Wednesday, 31 March 2010 12:34:03 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:00 UTC