While I somewhat agree with this bug, the fact is that <figure>  as it is defined  can only be used as a paragraph level container.

It sounds as if you think that the whole point with <figure> is that it can be used for to provide a caption for other elements. 

If this is the case, then a) it shoul dnot be limited to paragraph level, b) <figure> should probably be renamed or at least it should be made very clear what the real purpose is.

The current definition of figure is far too easily confused with aside.

Talking about "the side of the page" in the figure element definition confuses it with the aside element. 

Why does placement need to be mentioned at all?

I suggest deleting:

"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."

The current definitions of the aside and figure sound almost identical, except that figure has a caption. They are not only uncomfortably generic but also dangerously close in meaning, which adds complexity and ambiguity. Bad complexity leads to frustration, wasted time and wasted money.

Developers will tend to confuse the two elements and use them incorrectly. It will present a challenge for educators to teach the difference.

Bruce has mentioned that his view is figure is:

> 1) illustrative and 2) "typically referred to in the main article/ section".
> Aside is tangential,
> figure is integral.
http://lists.w3.org/Archives/Public/public-html/2010Jun/0171.html

If that is true, it would be a way of differentiating the two.

Some developers may want more choices and complex levels of control. But they don't want the complexity that entails elements that are ambiguous, error prone, or difficult to learn.

I don't really understand the problem here. Figures (<figure> in HTML) are very similar to sidebars (<aside> in HTML) in print — both are typically offset from the main prose such that they can be moved around a little (or even a lot) without changing the meaning of the document, the main difference is that figures typically are referenced from the main prose while sidebars typically are not, and figures typically are for units of content (an image, a table, a listing) whereas sidebars tend to be prose. This is exactly what the spec says. Both of these are generalities, though, with exceptions. The text in the spec says all this. Where's the problem?

(In reply to comment #3)
> I don't really understand the problem here. Figures (<figure> in HTML) are very
> similar to sidebars (<aside> in HTML) in print — both are typically offset
> from the main prose such that they can be moved around a little (or even a lot)
> without changing the meaning of the document, the main difference is that
> figures typically are referenced from the main prose while sidebars typically
> are not, and figures typically are for units of content (an image, a table, a
> listing) whereas sidebars tend to be prose. This is exactly what the spec says.
> Both of these are generalities, though, with exceptions. The text in the spec
> says all this. Where's the problem?

You have an incorrect understanding of the difference between figures and sidebars in print. 

Figures are illustrative, which is why they are referenced in the text. They are a visual illustration, regardless of what edge case you may find. Book publishers tend to have specific requirements for figure content. For instance, O'Reilly insists that the figure contents be a PNG or a TIFF. 

Sidebars are text that contain information that's tangential to the current discussion. They are a way of providing a section of information that is of interest in the section, but not essential to the section. They may be anecdotal, or provide a history or other information that is interesting, but not necessary. They are given a title, and are rarely referenced in the text. The section should be short--preferably, to fit within a page. 

Some book publishers like sidebars, but may don't. You have to use with extreme caution, because they can be distracting. Figures, on the other hand, are encouraged because they can be clarifying. 

Tables are also another offset item. I've heard the term "floating block" used for these items, but the publishers I've written for just use table, figure, sidebar, block quote, code, etc.
  
Typographically, they are offset, but only because the person creating the layout needs to be able to position the items because they don't split as cleanly as text and are handled as a solid block. Unlike a web page, a printed page is not malleable. 

People have been confused about the difference between figure and aside. They seem to be interchangeable in the spec, which undercuts their supposed semantic value. Considering all the discussions lately about incorrect use of table summary, or longdesc, etc, I would think you'd want to ensure there is no confusion as to the use and purpose of figure and aside. 

If the differences between the items are as vague as you say, based purely on structure of content, and not purpose of content, then you should consider eliminating one or the other.

http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0013.html

The bug triage sub-team thinks the HTML A11Y TF does not need to formally follow this bug. Original submitters or other interested parties may choose to continue to push this issue on their own. Notes from the sub-team may follow in a separate comment.

Bug triage sub-team says not accessibility, perhaps an authoring tool issue

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: see comment 3.

So I think the original point here was that <figure> provides a means to group an image and a caption together. There is no point in limiting the scope to only cases where the <figure> is not the primary content in the page because such a limitation will be ignored in practice. It is also not clear what value it would bring and, in some cases would be downright odd. For example consider a scientific article that provides captioned <figure>s in the main article, but where each image links to a page displaying only the image+caption, but at a larger size. Requiring that authors use different markup for the same content in these two situations seems perverse.

> There is no point in limiting the scope to
> only cases where the <figure> is not the primary content in the page because
> such a limitation will be ignored in practice.

I agree entirely, but nothing in the spec limits <figure> in this way, so it's unclear to me what is being requested here.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: I don't understand. Could you elaborate?