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

Re: Bug 8404 -- taking it to the lists

From: Shelley Powers <shelley.just@gmail.com>
Date: Tue, 1 Dec 2009 08:45:22 -0600
Message-ID: <643cc0270912010645v37d180f1i90f7618e296ca12b@mail.gmail.com>
To: HTMLWG WG <public-html@w3.org>
I forgot to add the link to the bug:

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

On Tue, Dec 1, 2009 at 8:03 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> Bug 8404 reads as follows:
>
> 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 a graphic 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. Your examples show a
> poem, 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.
>
> --
>
> After comments regarding ASCII art, I also added pre as an allowable
> graphics element.
>
> I've been told to take this bug to the lists for discussion. Here it is.
>
> I stand by the wording in this bug. I think that in HTML5, we should
> restrict the elements allowed in figure to those that are purely
> illustrative in nature, rather than allowing any form of HTML, and
> that includes tables. By restricting the types of elements allowed, we
> remove the need to repurpose dt/dd in figure, without having to add a
> new element.
>
> Others disagree. We will see if the editor agrees or not. If he
> doesn't agree with me, and marks this as WONTFIX, then I'll write a
> more formal change proposal, or I'll pursue a different bug, such as
> to remove figure altogether.
>
> Shelley
>
Received on Tuesday, 1 December 2009 14:45:57 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:54 UTC