Re: ISSUE-90 Change Proposal

Thanks for providing a Change Proposal for this issue! The chairs  are  
reviewing Change Proposals to ensure that they meet the required  
structure. Here is our feedback on this Change Proposal (actually the  
version subsequently uploaded to the wiki):

(1) This Change Proposal includes all of the required sections with  
appropriate content. The Rationale and Details sections seem sufficient.

We believe this Change Proposal is well-formed and ready for  
consideration by the Working Group.

Regards,
Maciej


On Mar 31, 2010, at 5:33 AM, Shelley Powers wrote:

> 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 Tuesday, 6 April 2010 20:21:12 UTC