I forgot one other allowable element in figure for the graphic: the canvas element. 

So, the list would include svg, math, canvas, img, object, video. 

Anything else, such as code blocks, has other formatting options. And that includes using the aside for other content. 

PRE elements should be allowed as the subject of FIGURE, for at least one
use-case: ASCII art.

Consider a piece of software that generates HTML versions of RFCs, using the
RFC plain text document as input. There are many RFCs where ASCII art is used
to depict some aspect of the standard in question. FIGURE is the closest
semantic element to this usage.

In academic writing, a table is not traditionally considered a figure; when a list includes both, it is usually identified as "figures and tables", and tables and figures are numbered separately. Equations are also not traditionally considered figures and are also numbered separately, so if the <figure> content model is restricted, perhaps it should not include <math>.

However, a figure may include multiple logically independent images, so multiple figure content elements should definitely be allowed. Likewise, sometimes figures have text identifying the separate image pieces, such as (a) and (b) which are referred to in the figure caption.

I also looked for examples of code listings being treated as figures. It seems like this is relatively uncommon -- code listings are more commonly included inline between paragraphs, or marked distinctively from figures. But I did find a few examples of code listings as figures. In particular, the USENIX 1998 Technical Conference Proceedings include several papers which have source code snippets labeled as figures. I also found at least one example of an ordered list as a figure. I even found an example of a table marked as a figure. I also found a number of programming books that lay out source code examples just like figures, but say "Listing" or "Example" instead of "Figure". I could not find an example of an equation marked as a figure by itself, but I did find numerous examples of plots of functions annotated with an equation. It seems that, to accomodate the realities of academic writing, <figure> needs to have a very generous content model.

Re ASCII art, I saw some figures in linguistics textbooks I've had on hand that could have been rendered as "Unicode art", i.e. Unicode text (to include phonetic alphabet characters and arrows) in a <pre> element.

This page includes a number of examples of figures, tables and equations: http://www.uefap.com/writing/function/chart.htm

It includes an example where source code is presented as a figure (Example 12). It also includes some examples where a figure has multiple images with individual labels, such as Example 7.

I would expect a <figure> to be able to contain a <table> instead of an image. They may be labeled differently, but in scientific literature tables are presented in exactly the same way as graphics; both will be numbered, both may have a long explanatory caption, etc. It is overkill to require two entirely different markup structures in order to represent the same structure with one case applying to graphics and the other to tables when the two cases are easily distinguished based on the actual content. 

Tables already have their own means of providing a semantically marked up and distinctively presented caption, namely the <caption> element. So what's the use case for putting a <table> in a <figure>? That being said, it seems that <figure> has to allow almost anything to account for the variety of uses in academic literature. I'm not sure if banning tables specifically is worthwhile. I could certainly imagine a figure containing a table and something else, or a table containing images.

Looking at another mark-up language known for being far more restrictive then HTML, Docbook http://docbook.org/tdg/en/html/figure.html we find that figure can be considered to contain almost everything, EXCEPT a formal table or formal equation. Seems reasonable then to allow almost any content except for a table or math element. 

However, if there is a wish to be less restrictive then allowing math or table doesn't seem horrible.Docbook allows for informal equations or tables in a figure. As HTML reasonably lacks formal and informal forms of table or math it seems reasonable to allow both in a figure. For example a figure might contain a graph, with a corresponding equation or table as part of the figure.

(In reply to comment #8)

> 
> However, if there is a wish to be less restrictive then allowing math or table
> doesn't seem horrible.Docbook allows for informal equations or tables in a
> figure. As HTML reasonably lacks formal and informal forms of table or math it
> seems reasonable to allow both in a figure. For example a figure might contain
> a graph, with a corresponding equation or table as part of the figure.
> 

I think the HTML equivalent of a DocBook informal table would be one with no <caption>. I think all HTML+MathML equations would be the equivalent of DocBook informal. So they should probably both be allowed.

(In reply to comment #2)
> PRE elements should be allowed as the subject of FIGURE, for at least one
> use-case: ASCII art.
> 
> Consider a piece of software that generates HTML versions of RFCs, using the
> RFC plain text document as input. There are many RFCs where ASCII art is used
> to depict some aspect of the standard in question. FIGURE is the closest
> semantic element to this usage.
> 


I don't think the pre element adds an undue burden. Again, it's something that wouldn't be used for caption, and we could then reserve another element or elements as caption, without having to create a new element, and without having to re-purpose dt/dd.

(In reply to comment #6)
> I would expect a <figure> to be able to contain a <table> instead of an image.
> They may be labeled differently, but in scientific literature tables are
> presented in exactly the same way as graphics; both will be numbered, both may
> have a long explanatory caption, etc. It is overkill to require two entirely
> different markup structures in order to represent the same structure with one
> case applying to graphics and the other to tables when the two cases are easily
> distinguished based on the actual content. 
> 


Perhaps because of my experience writing tech books, but tables are usually references as Table 1, Table 2, while code examples are Example 1, and figures are Figure 1 and Figure 2, and so on. I didn't think that scientific publications were that different. At least not the ones I can recall. 

We have an element for tables. We don't need another element for tables.

(In reply to comment #5)
> This page includes a number of examples of figures, tables and equations:
> http://www.uefap.com/writing/function/chart.htm
> 
> It includes an example where source code is presented as a figure (Example 12).
> It also includes some examples where a figure has multiple images with
> individual labels, such as Example 7.
> 


Yes, but Example 12 is using an image that is a code snapshot. The same with multiple figures -- is it multiple images, or one image file with multiple images?

Again, I have to refer back to the book publication industry: a figure contains one image, and one caption. If you need multiple images, you either have multiple figures, or one figure that has one image file that contains multiple images. 

During the discussions on what to use for caption one thing came through as pretty universal: everyone seemed to assume figure would have an image. I think anything else is, as you've said, pretty unusual.

(In reply to comment #5)
> This page includes a number of examples of figures, tables and equations:
> http://www.uefap.com/writing/function/chart.htm
> 
> It includes an example where source code is presented as a figure (Example 12).
> It also includes some examples where a figure has multiple images with
> individual labels, such as Example 7.
> 

I looked at the examples again, Maciej, and I noticed that the author is referring to Table 2.1 and so on. If we expand the semantics of figure to include code blocks, tables, and so on, then it really isn't a figure. If it becomes too general, than I'm not sure it's even useful. 

(In reply to comment #12)
> (In reply to comment #5)
> > This page includes a number of examples of figures, tables and equations:
> > http://www.uefap.com/writing/function/chart.htm
> > 
> > It includes an example where source code is presented as a figure (Example 12).
> > It also includes some examples where a figure has multiple images with
> > individual labels, such as Example 7.
> > 
> 
> 
> Yes, but Example 12 is using an image that is a code snapshot. 

It's an image of some code on the Web page. I doubt it was typeset as an image in the textbook that example was taken from. In the computer science papers I looked at, it was even more clear that the figures containing source code were typeset as text. And in HTML, it would certainly be preferable to use formatted text instead of an image of text for such a figure.

> The same with multiple figures -- is it multiple images, or one image file with multiple
> images?

I expect the way it was typeset was with multiple images and text. Some of the examples I found in textbooks certainly looked that way. And in HTML, you would want to actually mark it up that way, in preference to putting text inside an image.

> Again, I have to refer back to the book publication industry: a figure contains
> one image, and one caption. If you need multiple images, you either have
> multiple figures, or one figure that has one image file that contains multiple
> images. 

As I mentioned before, I saw a number of examples in textbooks and scientific papers which did not match that exact pattern.

> During the discussions on what to use for caption one thing came through as
> pretty universal: everyone seemed to assume figure would have an image. I think
> anything else is, as you've said, pretty unusual.

I think it would be highly surprising if it were incorrect to use <figure> to mark up the figures that actually appear in academic papers. <figure> should at the very least allow the kind of content that people use in figures in print.  For better or for worse, that includes source code, lists, multiple images with text, and sometimes even tables.

Even with unusual content, <figure> has a valuable semantic use, as often one wishes to extract a list of tables and figures from an article or book.

(In reply to comment #13)
> (In reply to comment #5)
> > This page includes a number of examples of figures, tables and equations:
> > http://www.uefap.com/writing/function/chart.htm
> > 
> > It includes an example where source code is presented as a figure (Example 12).
> > It also includes some examples where a figure has multiple images with
> > individual labels, such as Example 7.
> > 
> 
> I looked at the examples again, Maciej, and I noticed that the author is
> referring to Table 2.1 and so on. If we expand the semantics of figure to
> include code blocks, tables, and so on, then it really isn't a figure. If it
> becomes too general, than I'm not sure it's even useful. 
> 

Yes, that page has example of both figures and tables. It seems to be the usual practice to consider tables distinct from figures, and the examples there follow that convention. But it seems reasonably normal to treat a source code snippet as a figure.

I think examples from academic writing (where the distinction of what is and isn't a figure is carefully considered and made very clear) are more relevant than specific people's opinions of what should be allowed in a figure.

I should note by the way that I was in agreement with Shelley's opinion that a figure can only be an image  until this morning when I studied a large number of examples from the various science, engineering and social science textbooks I have around, as well as samples of academic papers, and practical programming books. Seeing how figures are used in practice convinced me that they need a very broad content model.

(In reply to comment #11)
> (In reply to comment #6)
> > I would expect a <figure> to be able to contain a <table> instead of an image.
> > They may be labeled differently, but in scientific literature tables are
> > presented in exactly the same way as graphics; both will be numbered, both may
> > have a long explanatory caption, etc. It is overkill to require two entirely
> > different markup structures in order to represent the same structure with one
> > case applying to graphics and the other to tables when the two cases are easily
> > distinguished based on the actual content. 
> > 
> 
> 
> Perhaps because of my experience writing tech books, but tables are usually
> references as Table 1, Table 2, while code examples are Example 1, and figures
> are Figure 1 and Figure 2, and so on. I didn't think that scientific
> publications were that different. At least not the ones I can recall.

On page 84 of Practical RDF, there are three tables in a figure. Now I admit
they are reasonably graphical tables, but could be done using HTML tables and
CSS or easily as SVG or a PNG.

On page 381 of Painting the Web there is a chart/table of web safe colors in a
Figure (9-21). It would be reasonable to represent this as either a table or
svg, or img in HTML. Page 386 has another Figure (9-25) Font compatibility
table from AMPSoft. 

I'd agree that figures are more graphical in nature then an aside, or a table.
But that doesn't mean that the graphical representation can't be partially
tabular or textual.

(In reply to comment #16)
> I should note by the way that I was in agreement with Shelley's opinion that a
> figure can only be an image  until this morning when I studied a large number
> of examples from the various science, engineering and social science textbooks
> I have around, as well as samples of academic papers, and practical programming
> books. Seeing how figures are used in practice convinced me that they need a
> very broad content model.
> 

I don't think it's a good idea, though, to allow the exceptions to guide what is default behavior. 

Remember there's nothing with refocusing figure back to images that doesn't preclude people also including an HTML table when they need a table. But they would embed the table directly in the content, rather than a figure. 

As the publication you showed demonstrated, figures are treated separately from code examples, and from tables. By simplifying figure, we're not precluding people from using what has existed for years: tables and code. 

Even if HTML5 ends up being adopted by ePub, which we assume will happen someday, most book authors would not put an HTML table within a figure. Figures would be considered images. In fact, images are always considered references to external files (currently, JPEG, PNG, GIF, and SVG). 

In point of fact, HTML tables are a bit of a problem with the ebook industry, but the tools are improving. And code samples have their own elements, with their own captions, and their own reference: Example 1, Example 2, and so on.

So I don't think that restricting figure to svg, canvas, img, object, video, and pre, would be an onerous burden on the scientific book community. I believe that allowing anything in figure, with the confusion about the name I've seen demonstrated this last week, and then repurposing dt/dd and forcing wrapping with a div element because of limitations of IE6/IE7 is more of a burden.

(In reply to comment #17)
> (In reply to comment #11)
> > (In reply to comment #6)
> > > I would expect a <figure> to be able to contain a <table> instead of an image.
> > > They may be labeled differently, but in scientific literature tables are
> > > presented in exactly the same way as graphics; both will be numbered, both may
> > > have a long explanatory caption, etc. It is overkill to require two entirely
> > > different markup structures in order to represent the same structure with one
> > > case applying to graphics and the other to tables when the two cases are easily
> > > distinguished based on the actual content. 
> > > 
> > 
> > 
> > Perhaps because of my experience writing tech books, but tables are usually
> > references as Table 1, Table 2, while code examples are Example 1, and figures
> > are Figure 1 and Figure 2, and so on. I didn't think that scientific
> > publications were that different. At least not the ones I can recall.
> 
> On page 84 of Practical RDF, there are three tables in a figure. Now I admit
> they are reasonably graphical tables, but could be done using HTML tables and
> CSS or easily as SVG or a PNG.
> 
> On page 381 of Painting the Web there is a chart/table of web safe colors in a
> Figure (9-21). It would be reasonable to represent this as either a table or
> svg, or img in HTML. Page 386 has another Figure (9-25) Font compatibility
> table from AMPSoft. 
> 
> I'd agree that figures are more graphical in nature then an aside, or a table.
> But that doesn't mean that the graphical representation can't be partially
> tabular or textual.
> 

Gavin, those are images of tables, pulled into the book as either TIFs or PNGs. 

The data is not accessible as a table.

If you all want to include JPEGs of tables in img elements, that's cool. You can put anything you want into an image file.

(In reply to comment #17)
> (In reply to comment #11)
> > (In reply to comment #6)
> > > I would expect a <figure> to be able to contain a <table> instead of an image.
> > > They may be labeled differently, but in scientific literature tables are
> > > presented in exactly the same way as graphics; both will be numbered, both may
> > > have a long explanatory caption, etc. It is overkill to require two entirely
> > > different markup structures in order to represent the same structure with one
> > > case applying to graphics and the other to tables when the two cases are easily
> > > distinguished based on the actual content. 
> > > 
> > 
> > 
> > Perhaps because of my experience writing tech books, but tables are usually
> > references as Table 1, Table 2, while code examples are Example 1, and figures
> > are Figure 1 and Figure 2, and so on. I didn't think that scientific
> > publications were that different. At least not the ones I can recall.
> 
> On page 84 of Practical RDF, there are three tables in a figure. Now I admit
> they are reasonably graphical tables, but could be done using HTML tables and
> CSS or easily as SVG or a PNG.
> 
> On page 381 of Painting the Web there is a chart/table of web safe colors in a
> Figure (9-21). It would be reasonable to represent this as either a table or
> svg, or img in HTML. Page 386 has another Figure (9-25) Font compatibility
> table from AMPSoft. 
> 
> I'd agree that figures are more graphical in nature then an aside, or a table.
> But that doesn't mean that the graphical representation can't be partially
> tabular or textual.
> 

PS These tables are not treated as tables, they're are treated in the book as graphics. 

I think you all are mixing up representation with function here. 

And if you want to put tables into the content, you can. Use the table element. Leave figure for figures. 

Notice that in the two examples you referenced, that I refer to the figures as figures? But the few tables I used (I don't use a lot of tables in my books, they're a pain to format), I reference as Table...

(In reply to comment #18)
> (In reply to comment #16)
> > I should note by the way that I was in agreement with Shelley's opinion that a
> > figure can only be an image  until this morning when I studied a large number
> > of examples from the various science, engineering and social science textbooks
> > I have around, as well as samples of academic papers, and practical programming
> > books. Seeing how figures are used in practice convinced me that they need a
> > very broad content model.
> > 
> 
> I don't think it's a good idea, though, to allow the exceptions to guide what
> is default behavior. 
> 
> Remember there's nothing with refocusing figure back to images that doesn't
> preclude people also including an HTML table when they need a table. But they
> would embed the table directly in the content, rather than a figure. 

I think if you're converting an article from some source form (say LaTeX or DocBook) to HTML, then you should be able to use <figure> for anything that was a figure in your source format.

> 
> As the publication you showed demonstrated, figures are treated separately from
> code examples, and from tables. By simplifying figure, we're not precluding
> people from using what has existed for years: tables and code. 

Indeed, tables are usually (though not always) treated separately from images. But I found many examples of source code being presented as a figure and labeled as such.


> In point of fact, HTML tables are a bit of a problem with the ebook industry,
> but the tools are improving. And code samples have their own elements, with
> their own captions, and their own reference: Example 1, Example 2, and so on.

That's not always the case. I've never seen the Example 1 / Example 2 numbering in a computer science paper, but I have seen Figure 1 / Figure 2 used to label code samples that are out of the normal flow.

> So I don't think that restricting figure to svg, canvas, img, object, video,
> and pre, would be an onerous burden on the scientific book community. 

I think it would. You should be able to convert LaTeX or DocBook to HTML and still be able to generate a valid list of tables and figures from the resulting HTML.

(In reply to comment #21)
> (In reply to comment #18)
> > (In reply to comment #16)
> > > I should note by the way that I was in agreement with Shelley's opinion that a
> > > figure can only be an image  until this morning when I studied a large number
> > > of examples from the various science, engineering and social science textbooks
> > > I have around, as well as samples of academic papers, and practical programming
> > > books. Seeing how figures are used in practice convinced me that they need a
> > > very broad content model.
> > > 
> > 
> > I don't think it's a good idea, though, to allow the exceptions to guide what
> > is default behavior. 
> > 
> > Remember there's nothing with refocusing figure back to images that doesn't
> > preclude people also including an HTML table when they need a table. But they
> > would embed the table directly in the content, rather than a figure. 
> 
> I think if you're converting an article from some source form (say LaTeX or
> DocBook) to HTML, then you should be able to use <figure> for anything that was
> a figure in your source format.

How are DocBook converted to HTML now? There is no figure in HTML4, or XHTML. 

How has DocBook been converted into HTML now?

> 
> > 
> > As the publication you showed demonstrated, figures are treated separately from
> > code examples, and from tables. By simplifying figure, we're not precluding
> > people from using what has existed for years: tables and code. 
> 
> Indeed, tables are usually (though not always) treated separately from images.
> But I found many examples of source code being presented as a figure and
> labeled as such.
> 
> 
> > In point of fact, HTML tables are a bit of a problem with the ebook industry,
> > but the tools are improving. And code samples have their own elements, with
> > their own captions, and their own reference: Example 1, Example 2, and so on.
> 
> That's not always the case. I've never seen the Example 1 / Example 2 numbering
> in a computer science paper, but I have seen Figure 1 / Figure 2 used to label
> code samples that are out of the normal flow.
> 
> > So I don't think that restricting figure to svg, canvas, img, object, video,
> > and pre, would be an onerous burden on the scientific book community. 
> 
> I think it would. You should be able to convert LaTeX or DocBook to HTML and
> still be able to generate a valid list of tables and figures from the resulting
> HTML.
> 


And you can. You can convert images into figures, and tables into tables. 

(In reply to comment #20)
> (In reply to comment #17)
> > (In reply to comment #11)
> > > (In reply to comment #6)
> > > > I would expect a <figure> to be able to contain a <table> instead of an image.
> > > > They may be labeled differently, but in scientific literature tables are
> > > > presented in exactly the same way as graphics; both will be numbered, both may
> > > > have a long explanatory caption, etc. It is overkill to require two entirely
> > > > different markup structures in order to represent the same structure with one
> > > > case applying to graphics and the other to tables when the two cases are easily
> > > > distinguished based on the actual content. 
> > > > 
> > > 
> > > 
> > > Perhaps because of my experience writing tech books, but tables are usually
> > > references as Table 1, Table 2, while code examples are Example 1, and figures
> > > are Figure 1 and Figure 2, and so on. I didn't think that scientific
> > > publications were that different. At least not the ones I can recall.
> > 
> > On page 84 of Practical RDF, there are three tables in a figure. Now I admit
> > they are reasonably graphical tables, but could be done using HTML tables and
> > CSS or easily as SVG or a PNG.
> > 
> > On page 381 of Painting the Web there is a chart/table of web safe colors in a
> > Figure (9-21). It would be reasonable to represent this as either a table or
> > svg, or img in HTML. Page 386 has another Figure (9-25) Font compatibility
> > table from AMPSoft. 
> > 
> > I'd agree that figures are more graphical in nature then an aside, or a table.
> > But that doesn't mean that the graphical representation can't be partially
> > tabular or textual.
> > 
> 
> PS These tables are not treated as tables, they're are treated in the book as
> graphics. 
> 
> I think you all are mixing up representation with function here. 
> 
> And if you want to put tables into the content, you can. Use the table element.
> Leave figure for figures. 
> 
> Notice that in the two examples you referenced, that I refer to the figures as
> figures? But the few tables I used (I don't use a lot of tables in my books,
> they're a pain to format), I reference as Table...
> 

(In reply to comment #19)
> (In reply to comment #17)
> > (In reply to comment #11)
> > > (In reply to comment #6)
> > > > I would expect a <figure> to be able to contain a <table> instead of an image.
> > > > They may be labeled differently, but in scientific literature tables are
> > > > presented in exactly the same way as graphics; both will be numbered, both may
> > > > have a long explanatory caption, etc. It is overkill to require two entirely
> > > > different markup structures in order to represent the same structure with one
> > > > case applying to graphics and the other to tables when the two cases are easily
> > > > distinguished based on the actual content. 
> > > > 
> > > 
> > > 
> > > Perhaps because of my experience writing tech books, but tables are usually
> > > references as Table 1, Table 2, while code examples are Example 1, and figures
> > > are Figure 1 and Figure 2, and so on. I didn't think that scientific
> > > publications were that different. At least not the ones I can recall.
> > 
> > On page 84 of Practical RDF, there are three tables in a figure. Now I admit
> > they are reasonably graphical tables, but could be done using HTML tables and
> > CSS or easily as SVG or a PNG.
> > 
> > On page 381 of Painting the Web there is a chart/table of web safe colors in a
> > Figure (9-21). It would be reasonable to represent this as either a table or
> > svg, or img in HTML. Page 386 has another Figure (9-25) Font compatibility
> > table from AMPSoft. 
> > 
> > I'd agree that figures are more graphical in nature then an aside, or a table.
> > But that doesn't mean that the graphical representation can't be partially
> > tabular or textual.
> > 
> 
> Gavin, those are images of tables, pulled into the book as either TIFs or PNGs. 
> 
> The data is not accessible as a table.
> 
> If you all want to include JPEGs of tables in img elements, that's cool. You
> can put anything you want into an image file.
> 

So we agree they are images of tables in a figure. I guess my question is why should we be limited to using images of tables in figures rather then HTML tables in figures?

(In reply to comment #19)

> 
> Gavin, those are images of tables, pulled into the book as either TIFs or PNGs. 
> 
> The data is not accessible as a table.
> 
> If you all want to include JPEGs of tables in img elements, that's cool. You
> can put anything you want into an image file.

I think it would be a terrible message to send if we tell HTML authors that the only way to include text or tabular data in a figure is to turn it into an image. Text on the Web should be marked up as text whenever possible, even if it is serving a largely graphical purpose. Ditto for tabular data. Turning text or tables into images is bad for accessibility, indexability, find-in-page features, copy/paste. It's an anti-pattern. If restricting <figure> would have this effect on HTML authoring then we absolutely should not do it.

Gavin referenced two figures from my books. 

One figure is a screenshot of the hue chart that you can access from the following web page:

http://www.lynda.com/resources/webpalette.aspx

As you can see, the author created the non-dithering color chart as a single image.

The other figure was a screen shot of the font compatibility table at 

http://www.ampsoft.net/webdesign-l/WindowsMacFonts.html

I'm not adverse to any form of HTML being used as a figure, but I think we need to consider, then, dropping the figure element. I do believe that repurposing dt/dd is a problem. I also believe having to wrap the element in a div element is also a problem. Lastly, most people think of figure as a graphical illustration, and other content, such as a poem, will cause confusion, and most likely result in the figure being use erroneously. 

The existing definition is far too liberal, too open ended. 

We would be better off just getting rid of figure, and use something like:

<div class="figure">
<div class="figurecontent">
...some html content
</div>
<div class="figurecaption">
<p>,,,,</p>
</div>
</div>

Then we can use whatever we want, and we don't have to screw around with misusing semantics.

(In reply to comment #24)
> (In reply to comment #19)
> 
> > 
> > Gavin, those are images of tables, pulled into the book as either TIFs or PNGs. 
> > 
> > The data is not accessible as a table.
> > 
> > If you all want to include JPEGs of tables in img elements, that's cool. You
> > can put anything you want into an image file.
> 
> I think it would be a terrible message to send if we tell HTML authors that the
> only way to include text or tabular data in a figure is to turn it into an
> image. Text on the Web should be marked up as text whenever possible, even if
> it is serving a largely graphical purpose. Ditto for tabular data. Turning text
> or tables into images is bad for accessibility, indexability, find-in-page
> features, copy/paste. It's an anti-pattern. If restricting <figure> would have
> this effect on HTML authoring then we absolutely should not do it.
> 

I think it's equally bad to confuse people who are expecting to see illustrations or other graphical entities in a figure, but what's shown is a poem, a piece of code, an HTML table, and so on. 

What does figure mean? If its nothing more than a title slapped on to a piece of web behavior, then why bother creating the new element? Just use div, it has the same level of semantics. 

(In reply to comment #22)
> 
> How are DocBook converted to HTML now? There is no figure in HTML4, or XHTML.

            <figure>
                <title>Sample Figure</title>
                <informaltable>
                    <tbody>
                        <tr>
                            <td>Cell</td>
                        </tr>
                    </tbody>
                </informaltable>
            </figure>

Becomes

<div class="figure">
    <p class="title">
        <b>Figure 1. Sample Figure</b>
    </p>
    <div class="figure-contents">
        <table id="d0e12">
            <tbody>
                <tr>
                    <td>Cell</td>
                </tr>
            </tbody>
        </table>
    </div>
</div>


I admit to having written code to convert HTML tables into images for use on the Kindle. This was not... ideal.

(In reply to comment #24)
> (In reply to comment #19)
> 
> > 
> > Gavin, those are images of tables, pulled into the book as either TIFs or PNGs. 
> > 
> > The data is not accessible as a table.
> > 
> > If you all want to include JPEGs of tables in img elements, that's cool. You
> > can put anything you want into an image file.
> 
> I think it would be a terrible message to send if we tell HTML authors that the
> only way to include text or tabular data in a figure is to turn it into an
> image. Text on the Web should be marked up as text whenever possible, even if
> it is serving a largely graphical purpose. Ditto for tabular data. Turning text
> or tables into images is bad for accessibility, indexability, find-in-page
> features, copy/paste. It's an anti-pattern. If restricting <figure> would have
> this effect on HTML authoring then we absolutely should not do it.
> 

Another option is to add one more element:

iframe

Then we could define whatever HTML in a separate HTML file, and include it in figure using iframe.

This would allow svg, mathml, img, iframe, object, and video as figure contents. 

Shelley

(In reply to comment #27)
> (In reply to comment #22)
> > 
> > How are DocBook converted to HTML now? There is no figure in HTML4, or XHTML.
> 
>             <figure>
>                 <title>Sample Figure</title>
>                 <informaltable>
>                     <tbody>
>                         <tr>
>                             <td>Cell</td>
>                         </tr>
>                     </tbody>
>                 </informaltable>
>             </figure>
> 
> Becomes
> 
> <div class="figure">
>     <p class="title">
>         <b>Figure 1. Sample Figure</b>
>     </p>
>     <div class="figure-contents">
>         <table id="d0e12">
>             <tbody>
>                 <tr>
>                     <td>Cell</td>
>                 </tr>
>             </tbody>
>         </table>
>     </div>
> </div>
> 
> 
> I admit to having written code to convert HTML tables into images for use on
> the Kindle. This was not... ideal.
> 


Yes, I've been working on converting web pages into ebooks, and tables don't make the conversion with ease. Tables are a pain in publication anyway. Even when I use OpenOffice and a template, I hate working with tables. 

But what you've shown is what I expect: the figure would be converted to a div element, wrapping the contents. Perhaps this is the approach we should adopt, and abandon figure as an element. I've not seen a good argument to keep figure, not if we have to repurpose dt/dd, or wrap the thing in a div element just to make it work in IE6/IE7.

Folks have said, well what about web bots? If we have a figure element, the bot can grab the figure image, and the caption, and use this to build the images directory at Google[1].

Well, when figure has table, a poem, or whatever, how meaningful is this now? Seriously? And the assumption that figure wraps a graphical illustration fully demonstrates how confusing this element will be.

Shelley

[1] http://lists.w3.org/Archives/Public/public-html/2009Nov/0667.html

(In reply to comment #28)
> (In reply to comment #24)
> > (In reply to comment #19)
> > 
> > > 
> > > Gavin, those are images of tables, pulled into the book as either TIFs or PNGs. 
> > > 
> > > The data is not accessible as a table.
> > > 
> > > If you all want to include JPEGs of tables in img elements, that's cool. You
> > > can put anything you want into an image file.
> > 
> > I think it would be a terrible message to send if we tell HTML authors that the
> > only way to include text or tabular data in a figure is to turn it into an
> > image. Text on the Web should be marked up as text whenever possible, even if
> > it is serving a largely graphical purpose. Ditto for tabular data. Turning text
> > or tables into images is bad for accessibility, indexability, find-in-page
> > features, copy/paste. It's an anti-pattern. If restricting <figure> would have
> > this effect on HTML authoring then we absolutely should not do it.
> > 
> 
> Another option is to add one more element:
> 
> iframe

That introduces some serious downsides:

1) Extra network request to load the contents of the <iframe>
2) Extra memory/performance overhead per <iframe> (likely to become very expensive if a document has many figures using this trick.
3) Requires the embedder to determine a fixed size, rather than allowing natural sizing of the figure. (This will go away when/if browsers implement seamless iframes; so far none has).
4) <iframe>s do not work as well as smoothly as in-flow content in many existing assistive technologies.

> 
> Then we could define whatever HTML in a separate HTML file, and include it in
> figure using iframe.
> 
> This would allow svg, mathml, img, iframe, object, and video as figure
> contents. 

I would ask: what semantic benefit is there if <figure> can't contain a table or a code sample, but it can contain an <iframe> containing a table or a code sample? It seems like this doesn't really restrict what <figure> can contain, just restricts the mechanism in an arbitrary and inconvenient way.

(In reply to comment #30)
> (In reply to comment #28)
> > (In reply to comment #24)
> > > (In reply to comment #19)
> > > 
> > > > 
> > > > Gavin, those are images of tables, pulled into the book as either TIFs or PNGs. 
> > > > 
> > > > The data is not accessible as a table.
> > > > 
> > > > If you all want to include JPEGs of tables in img elements, that's cool. You
> > > > can put anything you want into an image file.
> > > 
> > > I think it would be a terrible message to send if we tell HTML authors that the
> > > only way to include text or tabular data in a figure is to turn it into an
> > > image. Text on the Web should be marked up as text whenever possible, even if
> > > it is serving a largely graphical purpose. Ditto for tabular data. Turning text
> > > or tables into images is bad for accessibility, indexability, find-in-page
> > > features, copy/paste. It's an anti-pattern. If restricting <figure> would have
> > > this effect on HTML authoring then we absolutely should not do it.
> > > 
> > 
> > Another option is to add one more element:
> > 
> > iframe
> 
> That introduces some serious downsides:
> 
> 1) Extra network request to load the contents of the <iframe>
> 2) Extra memory/performance overhead per <iframe> (likely to become very
> expensive if a document has many figures using this trick.
> 3) Requires the embedder to determine a fixed size, rather than allowing
> natural sizing of the figure. (This will go away when/if browsers implement
> seamless iframes; so far none has).
> 4) <iframe>s do not work as well as smoothly as in-flow content in many
> existing assistive technologies.
> 
> > 
> > Then we could define whatever HTML in a separate HTML file, and include it in
> > figure using iframe.
> > 
> > This would allow svg, mathml, img, iframe, object, and video as figure
> > contents. 
> 
> I would ask: what semantic benefit is there if <figure> can't contain a table
> or a code sample, but it can contain an <iframe> containing a table or a code
> sample? It seems like this doesn't really restrict what <figure> can contain,
> just restricts the mechanism in an arbitrary and inconvenient way.
> 


I wasn't happy with the use of iframe either. It was another idea.

Frankly, I'm thinking the best thing to do is to remove figure. It is too general to be useful semantically, and people will be confused when figures are used for material that is not graphical or an illustration. And there's nothing in the definition of figure that prevents non-illustrative material. 

You referenced Docbook earlier, but the definition for figure in Docbook is for illustrative purposes. If we don't restrict the elements to those compatible with illustrative purposes, then figure will be misused. People probably won't know when to use aside, and when to use figure. 

Or they won't care, of they'll just use div elements.

Shelley

(In reply to comment #31)
> 
> I wasn't happy with the use of iframe either. It was another idea.
> 
> Frankly, I'm thinking the best thing to do is to remove figure. It is too
> general to be useful semantically, and people will be confused when figures are
> used for material that is not graphical or an illustration. And there's nothing
> in the definition of figure that prevents non-illustrative material. 

Removing figure would best be expressed as a separate bug I think. Would you be ok with closing this one, or do you still think restricting the content model is a good approach?

That being said, I do think <figure> has semantic value. Specifically, extracting a list of tables and figures is a common thing to do with a lengthy illustrated document. Doing that by looking for <figure> and <table> elements seems pretty handy. 

I do think the HTML5 spec should have normative text that <figure> is for illustrative purposes (in the broad sense). This is the purpose of figures and is one thing that distinguishes them from various kinds of asides.

> 
> You referenced Docbook earlier, but the definition for figure in Docbook is for
> illustrative purposes. If we don't restrict the elements to those compatible
> with illustrative purposes, then figure will be misused. People probably won't
> know when to use aside, and when to use figure. 

Print authors seem to know when to use a figure and when to use a sidebar or pull quote. I don't think Web authors will do that much worse. I would guess the most common use in the end will be for images, whatever the validator says.

This bug strikes a chord with my idea to use <object> instead of <dd> for the content of the <figure>.

http://lists.w3.org/Archives/Public/public-html/2009Nov/0676

1. It is in principle OK for me to say that <figure> cannot contain text, as long as <figure> can contain <object>, and <object> itself - like in HTML 4 - can be used as a text container. Such a rule would be very simple and quite logical. In addition to <object>, however, one could also allow those media/forreign content elements that you spoke about. This would be good enough for me.

2. There are firstly two issues at stake with <figure>: caption content and captioned content. The very <figure> element merely keeps the two parts together. In <figure>'s first incarnation, however, it did not have any content wrapping element (<dd>) - it only had a captioning element. Still, that <dd> is meant to contain the content, means that <figure> is able to - itself - create a content unity. You could just lump a few paragraphs together and drop them inside the <dd>, and then <figure> would "figure out" the unity for you. If instead we only permit certain elements as the content element of <figure>, then we make sure that only things that, by themselves, constintute a unity, can be placed inside <figure> and get a caption.

3. In the spec draft, however, <figure> also has another role: it is the root of a new outline (referred to as "sectioning root" in the draft) - same as <td> and <blockquote>. We could, however, remove the sectioning root feature from <figure> itself and say that it is the content element of <figure> that constitute the outline root. This would be in line with how <td> (and/but not <table>!) constitutes a sectioning root. When we look at the elements you proposed as content elements (svg, math, canvas, img, object etx) then it is obvious that they constititute their own outline roots, I think - they are their own separate contexts.

4.  This bug report in reality emphasizes that the purpose of <figure> is to provide captions. (A lone <img> inside a <figure>, without a caption, is meaningless.) The purpose of the very <figure> element is to link the figure caption to the figure content. Adding a caption to an image is an important issue that HTML 4 doesn't solve. But <figure> feels a little bit like a to heavy shot if one need to use both <dt> and <dd>. (Separate issue: And what abou inline images in need of caption text? )

5.  When Maciej explains how tables too belongs in <figure>, then he is in reality emphasizing that <table> needs a generic caption element - the <caption> of the <table> is not good/general enough. In other words: We need a common caption element - or a common way to do captions, if you wish.

6. When your bug report emphasize that a lone <img> should not need to be wrapped inside a another element, like <dd>, then you are in reality emphasizing that <figure> does not itself collect the figure content into a unity - that role is played by the content element of the <figure>: dd in the current draft, and svg, math, canvas, img, object, video etc in your bug report. 

7. Please note that e.g. mathml is a rich language that can even contain xhtml. And so is SVG. Shelley: You spoke about how idiotic it would be if one would misuse <svg> inside HTML in order to be able to operate with namespaces. Well, it is certainly also idiotic if we have to dig into SVG in order to place other things than pure images inside a figure element.

8. If, then, we interpretate <figure> as a semantic wrapper for a caption+content, then other elements that constitute a unity - such a Maciej's <table> - should also be allowed to constitute the content of a <figure>. I don't see, howver, why  <ol>, <dl>, <ul>, <blockquote> could not also need a caption.  But a single <p> could also need a caption now and then. Were do we draw the line? 

All in all and to cut short: 

I would suggest that <figure> can contain a single, un-wrapped "forreign content" element (svg, mathml), or a single HTML media element (audio, video, img, object, iframe) or <blockquote>. But no <pre> or <p> etc, unless it is wrapped inside <object> (or <iframe>). All these elements constitute their own sectioining root (see the HTML 5 draft, section 4.4.11, "Headings and sections" about sectioning roots). (OK, there is no outline inside <img>, but ther may be an imaginary one.) The principle should be: figure can only contain an element that can be said to constitue its own sectioning root.

As a consequence, if you want to place inside <figure> an element that does not constitute a sectioning root, or isn't a media element or isn't a forreign content element, then you must wrap it inside an <object> (or in a separate file, via <iframe>). Thus, if you want to place a table or a list inside a figure, you must wrap it inside <object>, so as to "isolate" the element inside the sectioning root of the <object> element. This way it becomes possible to have two caption elements for a table: <caption> and the caption of the figure, if you so wish.

(In reply to comment #32)
> (In reply to comment #31)
> > 
> > I wasn't happy with the use of iframe either. It was another idea.
> > 
> > Frankly, I'm thinking the best thing to do is to remove figure. It is too
> > general to be useful semantically, and people will be confused when figures are
> > used for material that is not graphical or an illustration. And there's nothing
> > in the definition of figure that prevents non-illustrative material. 
> 
> Removing figure would best be expressed as a separate bug I think. Would you be
> ok with closing this one, or do you still think restricting the content model
> is a good approach?
> 
> That being said, I do think <figure> has semantic value. Specifically,
> extracting a list of tables and figures is a common thing to do with a lengthy
> illustrated document. Doing that by looking for <figure> and <table> elements
> seems pretty handy. 
> 
> I do think the HTML5 spec should have normative text that <figure> is for
> illustrative purposes (in the broad sense). This is the purpose of figures and
> is one thing that distinguishes them from various kinds of asides.
> 
> > 
> > You referenced Docbook earlier, but the definition for figure in Docbook is for
> > illustrative purposes. If we don't restrict the elements to those compatible
> > with illustrative purposes, then figure will be misused. People probably won't
> > know when to use aside, and when to use figure. 
> 
> Print authors seem to know when to use a figure and when to use a sidebar or
> pull quote. I don't think Web authors will do that much worse. I would guess
> the most common use in the end will be for images, whatever the validator says.
> 

No, I don't want this one closed. 

What I stated in this bug is a real concern: figure is ill-defined, and too
generic to be semantically meaningful, and will cause problems later on. How
the contents of figure are defined, repurposing dt/dd is already a problem.

Another option rather than fixing figure is to get rid of it. And I probably
will do a separate bug, since this is the only way to suggest an alternative.
But I want this one kept alive. During the discussion, we may be able to derive a solution to all our concerns. 

There are many, many examples in the literature of code and tables being labeled as "figures".  Here are but two examples obtained with 15 seconds of searching on Google Books:

Code listing as figure:
http://books.google.com/books?id=Za1ypU8u9BAC&lpg=PP9&dq=%22Figure%205%22&pg=PA96#v=onepage&q=%22Figure%205%22&f=false

Table as figure:
http://books.google.com/books?id=Fsz234KPVz8C&pg=PT120&dq=%22Figure+5%22&ei=I4wUS8raFJjQNPHJ2ZQL#v=onepage&q=%22Figure%205%22&f=false

There is no confusion caused by using non-images in figures.  It is a common idiom that people are used to.

(In reply to comment #35)
> There are many, many examples in the literature of code and tables being
> labeled as "figures".  Here are but two examples obtained with 15 seconds of
> searching on Google Books:
> 
> Code listing as figure:
> http://books.google.com/books?id=Za1ypU8u9BAC&lpg=PP9&dq=%22Figure%205%22&pg=PA96#v=onepage&q=%22Figure%205%22&f=false
> 
> Table as figure:
> http://books.google.com/books?id=Fsz234KPVz8C&pg=PT120&dq=%22Figure+5%22&ei=I4wUS8raFJjQNPHJ2ZQL#v=onepage&q=%22Figure%205%22&f=false
> 
> There is no confusion caused by using non-images in figures.  It is a common
> idiom that people are used to.
> 

Actually, there was confusion about what figure contained just this week, in the thread that I linked in an earlier comment. 

It is not a common idiom. And people are confusing illustration and function.

For instance, in the example you displayed from the Dummies book, that was an illustrative figure. The table values themselves were created just for illustration purposes. It was an illustration of a balance sheet. And very likely, when the author created the book, the balance sheet was probably a screenshot, added into the book as a PNG or a TIF. However it was added, though, the data in the table itself, was meaningless -- it existed purely as a demonstration.

As for the code example, it's not a true code examples, of which the book has several. It's an illustration of a common concept of programming. As such, it's not meant as an example for a person to copy and try out. It's meant to illustrate a generic programming concept. 

These two examples work in a hard copy book. A table in a book is only as meaningful on the context of its usage. But in a web page, a table element is supposed to be part of a table model, and part of the DOM. That doesn't match the data in the example you pulled up. 

There's a disconnect here. We look at something like DocBook and it shows tables in a figure. But figure itself is defined as, " A formal figure, generally an illustration, with a title". Whatever is in the figure element is illustrative, a visual aid. It's not meant to have meaning beyond being a visual aid. 

It's the same as when I illustrated how to use a Photoshop dialog in my Painting the Web book. Would you really expect that figure to convert to an HTML form in a web page? Extrapolating that to your example: would you really want the table entries you showed in your example, Tab, to be part of the DOM? It's meaningless data--picked out of the air for illustration purposes. 

Do I want HTML tables in figures? Of course not, because we have nothing in the HTML5 specification that when HTML tables are included in figures, the data contained in the element is illustrative only, so the data and the elements should not be loaded into the page's DOM. 

I appreciate that Maciej brought up the book model in this bug, because it strengthens the argument I have about eBook in the bug related to splitting off section 6, on the browser object model [1]. However, there are constraints with user agents that support a DOM that don't necessarily apply to eBooks, which don't. 

These subtle differences shouldn't be an issue, though, if we respect the environment for each use of HTML. Books don't have a DOM, so people can plunk tables anywhere they want, even in figures. Web pages loaded in browsers, however, are impacted when tables are just plunked in anywhere -- it impacts on the DOM.

When we convert books to web pages that have figures that contain tables, if those tables are illustrative and not data, then they should be added into the page as snapshots, as images. If the tables are data tables, then we shouldn't enclose them in a figure. We should include the table, as is, and reference it as Table 5, rather than Figure 5. 

Because that's what's happening in the examples you provided.

Shelley

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


 

(In reply to comment #33)
> This bug strikes a chord with my idea to use <object> instead of <dd> for the
> content of the <figure>.
> 
> http://lists.w3.org/Archives/Public/public-html/2009Nov/0676
> 
> 1. It is in principle OK for me to say that <figure> cannot contain text, as
> long as <figure> can contain <object>, and <object> itself - like in HTML 4 -
> can be used as a text container. Such a rule would be very simple and quite
> logical. In addition to <object>, however, one could also allow those
> media/forreign content elements that you spoke about. This would be good enough
> for me.
> 
> 2. There are firstly two issues at stake with <figure>: caption content and
> captioned content. The very <figure> element merely keeps the two parts
> together. In <figure>'s first incarnation, however, it did not have any content
> wrapping element (<dd>) - it only had a captioning element. Still, that <dd> is
> meant to contain the content, means that <figure> is able to - itself - create
> a content unity. You could just lump a few paragraphs together and drop them
> inside the <dd>, and then <figure> would "figure out" the unity for you. If
> instead we only permit certain elements as the content element of <figure>,
> then we make sure that only things that, by themselves, constintute a unity,
> can be placed inside <figure> and get a caption.
> 
> 3. In the spec draft, however, <figure> also has another role: it is the root
> of a new outline (referred to as "sectioning root" in the draft) - same as <td>
> and <blockquote>. We could, however, remove the sectioning root feature from
> <figure> itself and say that it is the content element of <figure> that
> constitute the outline root. This would be in line with how <td> (and/but not
> <table>!) constitutes a sectioning root. When we look at the elements you
> proposed as content elements (svg, math, canvas, img, object etx) then it is
> obvious that they constititute their own outline roots, I think - they are
> their own separate contexts.
> 
> 4.  This bug report in reality emphasizes that the purpose of <figure> is to
> provide captions. (A lone <img> inside a <figure>, without a caption, is
> meaningless.) The purpose of the very <figure> element is to link the figure
> caption to the figure content. Adding a caption to an image is an important
> issue that HTML 4 doesn't solve. But <figure> feels a little bit like a to
> heavy shot if one need to use both <dt> and <dd>. (Separate issue: And what
> abou inline images in need of caption text? )
> 
> 5.  When Maciej explains how tables too belongs in <figure>, then he is in
> reality emphasizing that <table> needs a generic caption element - the
> <caption> of the <table> is not good/general enough. In other words: We need a
> common caption element - or a common way to do captions, if you wish.
> 
> 6. When your bug report emphasize that a lone <img> should not need to be
> wrapped inside a another element, like <dd>, then you are in reality
> emphasizing that <figure> does not itself collect the figure content into a
> unity - that role is played by the content element of the <figure>: dd in the
> current draft, and svg, math, canvas, img, object, video etc in your bug
> report. 
> 
> 7. Please note that e.g. mathml is a rich language that can even contain xhtml.
> And so is SVG. Shelley: You spoke about how idiotic it would be if one would
> misuse <svg> inside HTML in order to be able to operate with namespaces. Well,
> it is certainly also idiotic if we have to dig into SVG in order to place other
> things than pure images inside a figure element.
> 
> 8. If, then, we interpretate <figure> as a semantic wrapper for a
> caption+content, then other elements that constitute a unity - such a Maciej's
> <table> - should also be allowed to constitute the content of a <figure>. I
> don't see, howver, why  <ol>, <dl>, <ul>, <blockquote> could not also need a
> caption.  But a single <p> could also need a caption now and then. Were do we
> draw the line? 
> 
> All in all and to cut short: 
> 
> I would suggest that <figure> can contain a single, un-wrapped "forreign
> content" element (svg, mathml), or a single HTML media element (audio, video,
> img, object, iframe) or <blockquote>. But no <pre> or <p> etc, unless it is
> wrapped inside <object> (or <iframe>). All these elements constitute their own
> sectioining root (see the HTML 5 draft, section 4.4.11, "Headings and sections"
> about sectioning roots). (OK, there is no outline inside <img>, but ther may be
> an imaginary one.) The principle should be: figure can only contain an element
> that can be said to constitue its own sectioning root.
> 
> As a consequence, if you want to place inside <figure> an element that does not
> constitute a sectioning root, or isn't a media element or isn't a forreign
> content element, then you must wrap it inside an <object> (or in a separate
> file, via <iframe>). Thus, if you want to place a table or a list inside a
> figure, you must wrap it inside <object>, so as to "isolate" the element inside
> the sectioning root of the <object> element. This way it becomes possible to
> have two caption elements for a table: <caption> and the caption of the figure,
> if you so wish.
> 


Interesting, Lief. There's a lot of truth to what you're saying: we're really looking at being able to encapsulate a caption with an element. 

I think there's also an aspect of removal from the page, though, too. 

But it sounds like you're pretty much agreeing with me, except for the use of pre and p, you are proposing a generic caption element, like I mentioned in the Issue 83 change proposal.

Here is another example of a table as a figure, this time with real data, not fake data meant for illustrative purposes:
http://books.google.com/books?id=QbdMOM89qv0C&lpg=PA555&dq=%22table%20in%20figure%22&lr=&pg=PA556#v=onepage&q=%22table%20in%20figure%22&f=false

I can produce literally tens of examples of these without trying.  This is *precisely* the usage as currently defined in the spec.

I pulled a single programming book out of my bookshelf (one about machine learning) and found dozens of code snippets given and labeled as figures.  The book contains literally hundreds of data tables given as figures (they are labeled as "Table 1.1", etc, but they display identical semantics to the code and diagrams that are labeled explicitly as figures).

Whether or not this is a common idiom is not up for discussion.  It is a plain fact that it is, as literally just a few minutes of searching turns up a large number of examples.

Figures are *not* merely for illustrative purposes, though that is certainly a common use of them.  The current descriptive text in the spec aligns pretty much precisely with the full common usage of figures - as information that is part of the content but can be moved from its document position without affecting the meaning of the document.

(In reply to comment #38)
> Here is another example of a table as a figure, this time with real data, not
> fake data meant for illustrative purposes:
> http://books.google.com/books?id=QbdMOM89qv0C&lpg=PA555&dq=%22table%20in%20figure%22&lr=&pg=PA556#v=onepage&q=%22table%20in%20figure%22&f=false
> 
> I can produce literally tens of examples of these without trying.  This is
> *precisely* the usage as currently defined in the spec.
> 
> I pulled a single programming book out of my bookshelf (one about machine
> learning) and found dozens of code snippets given and labeled as figures.  The
> book contains literally hundreds of data tables given as figures (they are
> labeled as "Table 1.1", etc, but they display identical semantics to the code
> and diagrams that are labeled explicitly as figures).
> 
> Whether or not this is a common idiom is not up for discussion.  It is a plain
> fact that it is, as literally just a few minutes of searching turns up a large
> number of examples.
> 
> Figures are *not* merely for illustrative purposes, though that is certainly a
> common use of them.  The current descriptive text in the spec aligns pretty
> much precisely with the full common usage of figures - as information that is
> part of the content but can be moved from its document position without
> affecting the meaning of the document.
> 

But you're taking these examples out of context. A figure in a book is nothing more than a piece of a page -- it is the context that gives it meaning; that tells the reader whether the data is illustrative or meaningful. 

You're finding examples in books where the figure is a meaningful table. We don't know, though, whether the author used "Figure" for the table, because the book has no concept of a formal Table element, to differentiate the item, or if the table, though meaningful, wasn't a scan from another book that was included, literally, as a figure in the book. 

So how do we differentiate a table that's for illustrative purposes in a figure, from one that isn't illustrative and the data should be parsed and loaded into the DOM? Do we want every table in every figure element to be loaded into the DOM? 

So what is a figure then? If it's not illustration, or not anything special, is it, as Lief stated, nothing more than a way of attaching a caption of to a lump of markup? 

(In reply to comment #39)
> 
> So how do we differentiate a table that's for illustrative purposes in a
> figure, from one that isn't illustrative and the data should be parsed and
> loaded into the DOM? Do we want every table in every figure element to be
> loaded into the DOM? 

Yes! That's superior in nearly every way to using an image of a table. Even if the table is purely for illustration purposes, you still want to be able to do Find in Text on it, to index it in search engines (maybe I remember some memorable entry from one of those tables) to copy/paste bits of the text, and to navigate the table structure in a screen reader (which will likely be a better illustration to a blind person than just alt text).

It's hard for me to believe that making an image of a data table is being seriously considered as a good approach.

(In reply to comment #40)
> (In reply to comment #39)
> > 
> > So how do we differentiate a table that's for illustrative purposes in a
> > figure, from one that isn't illustrative and the data should be parsed and
> > loaded into the DOM? Do we want every table in every figure element to be
> > loaded into the DOM? 
> 
> Yes! That's superior in nearly every way to using an image of a table. Even if
> the table is purely for illustration purposes, you still want to be able to do
> Find in Text on it, to index it in search engines (maybe I remember some
> memorable entry from one of those tables) to copy/paste bits of the text, and
> to navigate the table structure in a screen reader (which will likely be a
> better illustration to a blind person than just alt text).

Not to mention that the text and markup of a table will be smaller to send over the wire, and will give a better visual result when zoomed.

(In reply to comment #40)
> (In reply to comment #39)
> > 
> > So how do we differentiate a table that's for illustrative purposes in a
> > figure, from one that isn't illustrative and the data should be parsed and
> > loaded into the DOM? Do we want every table in every figure element to be
> > loaded into the DOM? 
> 
> Yes! That's superior in nearly every way to using an image of a table. Even if
> the table is purely for illustration purposes, you still want to be able to do
> Find in Text on it, to index it in search engines (maybe I remember some
> memorable entry from one of those tables) to copy/paste bits of the text, and
> to navigate the table structure in a screen reader (which will likely be a
> better illustration to a blind person than just alt text).
> 
> It's hard for me to believe that making an image of a data table is being
> seriously considered as a good approach.
> 

ou want to do searches on junk table entries? 

You want to have search engines return queries based on the junk table entries?

And I'm not sure that folks are going to want a screenreader reading junk data
entries from a table created purely for illustration. Especially a table that
doesn't contain a summary attribute...

But, chances are the tables listed as figures that you'll find with most of
these Google book searches were inserted into the books as images. Screenshots, or scans from applications, or other books.

(In reply to comment #38)
> Here is another example of a table as a figure, this time with real data, not
> fake data meant for illustrative purposes:
> http://books.google.com/books?id=QbdMOM89qv0C&lpg=PA555&dq=%22table%20in%20figure%22&lr=&pg=PA556#v=onepage&q=%22table%20in%20figure%22&f=false
> 
> I can produce literally tens of examples of these without trying.  This is
> *precisely* the usage as currently defined in the spec.

And where do you place the footnotes of that table, so that it fits with what is currently defined in the spec?

I'll answer myself: As currently defined, there is not a single table that can have a figure caption. All figure elements will instead - as currently defined - contain a <dd> where the <dt> is the caption. Those footnotes of that table therefore lands in the <dd> element. And the caption - which is were the word "figure" appears - captions *the unity* of the table and the footnotes.

As I see it now, the figure of that google page should be created like this:

<figure>
    <object>
       <table><tr><td>etc
      </table>
      <div class="footnotes">
         <p id="footnote-1>...</p>
         <p id="footnote-2>...</p>
      </div>
    </object>
   <p><b>Figure 28.2</b> This span table is suitable for ...</p>
</figure>

(In reply to comment #43)
> (In reply to comment #38)
> > Here is another example of a table as a figure, this time with real data, not
> > fake data meant for illustrative purposes:
> > http://books.google.com/books?id=QbdMOM89qv0C&lpg=PA555&dq=%22table%20in%20figure%22&lr=&pg=PA556#v=onepage&q=%22table%20in%20figure%22&f=false
> > 
> > I can produce literally tens of examples of these without trying.  This is
> > *precisely* the usage as currently defined in the spec.
> 
> And where do you place the footnotes of that table, so that it fits with what
> is currently defined in the spec?

<figure>
  <table>...</table>
  <p caption>Figure 1: an illustrative table with content you can copy because the HTML5 spec [1] is so nice as to allow it inside &lt;figure></p>
  <a class="reference" href="http://www.w3.org/TR/html5/">[1]</a><br>
  <small>&copy; Santa Clause. No rights reserved.</small>
</figure>

Yes, I also disagree with the use of dd/dt. I'm not sure we should allow footnotes and other non-content, non-caption markup inside <figure>, but it's not terribly difficult to do if we want it. Perhaps we should mandate that it be marked up with <small>/<aside>/whatever to make it unambiguous which part is the main content.

The concrete proposal in this bug (to either scrap <figure> or limit it to some specific elements) makes little sense, so close this and open new bugs (or write mail) for other concrete proposals.

(In reply to comment #44)
> (In reply to comment #43)
> > (In reply to comment #38)
> > > Here is another example of a table as a figure, this time with real data, not
> > > fake data meant for illustrative purposes:
> > > http://books.google.com/books?id=QbdMOM89qv0C&lpg=PA555&dq=%22table%20in%20figure%22&lr=&pg=PA556#v=onepage&q=%22table%20in%20figure%22&f=false
> > > 
> > > I can produce literally tens of examples of these without trying.  This is
> > > *precisely* the usage as currently defined in the spec.
> > 
> > And where do you place the footnotes of that table, so that it fits with what
> > is currently defined in the spec?
> 
> <figure>
>   <table>...</table>
>   <p caption>Figure 1: an illustrative table with content you can copy because
> the HTML5 spec [1] is so nice as to allow it inside &lt;figure></p>
>   <a class="reference" href="http://www.w3.org/TR/html5/">[1]</a><br>
>   <small>&copy; Santa Clause. No rights reserved.</small>
> </figure>
> 
> Yes, I also disagree with the use of dd/dt. I'm not sure we should allow
> footnotes and other non-content, non-caption markup inside <figure>, but it's
> not terribly difficult to do if we want it. Perhaps we should mandate that it
> be marked up with <small>/<aside>/whatever to make it unambiguous which part is
> the main content.
> 
> The concrete proposal in this bug (to either scrap <figure> or limit it to some
> specific elements) makes little sense, so close this and open new bugs (or
> write mail) for other concrete proposals.

(Please note that I meant the footnotes that are visible in the Google books example. They appear just below the table. And the figure caption text appears below those again.)

I think the current proposal - which relies on <dt> and <dd> - has an important point (hey, it was I who proposed <dt> and <dd>): It _isn't_ the <table> that is being captioned, but the unity of table and footnotes to the table.

When you ask if we should permit "footnotes and other non-content, non-caption markup inside <figure>", then you are actually on the same train as Shelley.

The only truly unambigous thing to do if we want to make it unanmbiguous "which part is the main content" is to stuff table and footones inside a unifying "content element". If the footnotes are not labeled by the caption, then they have nothing to do inside the figure.

(In reply to comment #37)
> (In reply to comment #33)
> 
> Interesting, Lief. There's a lot of truth to what you're saying: we're really
> looking at being able to encapsulate a caption with an element. 
> 
> I think there's also an aspect of removal from the page, though, too. 
> 
> But it sounds like you're pretty much agreeing with me, except for the use of
> pre and p, you are proposing a generic caption element, like I mentioned in the
> Issue 83 change proposal.

We are not far from eachother in how we understand this. The "removal from the page" is, I think, equal to "identifying something as a unity within a larger unity".

I agree with you that the word <figure> probably is connected to illustrations of sorts, in many minds.  But I still think that html tables etc can be presented as a figure - using <object> as wrapper. But even for photos/images, if the photo has some accompanying text, and you want to caption the _unity_ of the photo and that text, then it can be wrapped inside <object>. 

Talking about people's expectations:  Even for images/photos, then <figure> might become misunderstood = not used. For instance, back in 2007, then Maciej (amongst others) many times mentioned Flickr as a usecase for <figure>.  But, talking about my own expecations, then it feels strange to label e.g. a private photo of my parents as a figure just because I want to add a image caption to it.

I indeed think that the main purpose of <figure> is to act as way to add a caption to some unity. Therefore, the name <figure> might be unfortunate. Perhaps we could take the table <caption> as a pattern: It currently permits any kind of mark-up inside (in HTML 4, block elements were forbidden). If we redefine <figure> as as <cap> element (caption element), but permit that the caption may be kept inside a block element - or be written directly in the <cap> element ...

... then the simplest way to add a text to an IMG would become this:

<cap>My parents outside their home.
           <img src="photo" alt="mom to the left, dad to the right in fron of their house" >
</cap>

Or, if I want to place the caption in a block element:

<cap><p>My parents outside their home.</p>
           <img src="photo" alt="mom to the left, dad to the right in fron of their house" >
</cap>

I think that this <cap> element should be transparent w.r.t. whether it is block or inline. If the element used for the caption is a block element, then the <cap> is also a block element. But if the caption text is kept inside a inline element - or if it is written directly inside the <cap> elemetn, then the <cap> is inline and can be placed e.g. inside a <p>, like this:

<p>This summer I visited my parents. 
        <cap style="float:left">My parents outside their home.
           <img src="photo" alt="mom to the left, dad to the right in fron of their house" >
      </cap>
</p>

See example: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/323

(In reply to comment #45)
> (In reply to comment #44)
> > (In reply to comment #43)
> > > (In reply to comment #38)
> > > > Here is another example of a table as a figure, this time with real data, not
> > > > fake data meant for illustrative purposes:
> > > > http://books.google.com/books?id=QbdMOM89qv0C&lpg=PA555&dq=%22table%20in%20figure%22&lr=&pg=PA556#v=onepage&q=%22table%20in%20figure%22&f=false
> > > > 
> > > > I can produce literally tens of examples of these without trying.  This is
> > > > *precisely* the usage as currently defined in the spec.
> > > 
> > > And where do you place the footnotes of that table, so that it fits with what
> > > is currently defined in the spec?
> > 
> > <figure>
> >   <table>...</table>
> >   <p caption>Figure 1: an illustrative table with content you can copy because
> > the HTML5 spec [1] is so nice as to allow it inside &lt;figure></p>
> >   <a class="reference" href="http://www.w3.org/TR/html5/">[1]</a><br>
> >   <small>&copy; Santa Clause. No rights reserved.</small>
> > </figure>
> > 
> > Yes, I also disagree with the use of dd/dt. I'm not sure we should allow
> > footnotes and other non-content, non-caption markup inside <figure>, but it's
> > not terribly difficult to do if we want it. Perhaps we should mandate that it
> > be marked up with <small>/<aside>/whatever to make it unambiguous which part is
> > the main content.
> > 
> > The concrete proposal in this bug (to either scrap <figure> or limit it to some
> > specific elements) makes little sense, so close this and open new bugs (or
> > write mail) for other concrete proposals.
> 
> (Please note that I meant the footnotes that are visible in the Google books
> example. They appear just below the table. And the figure caption text appears
> below those again.)
> 
> I think the current proposal - which relies on <dt> and <dd> - has an important
> point (hey, it was I who proposed <dt> and <dd>): It _isn't_ the <table> that
> is being captioned, but the unity of table and footnotes to the table.
> 
> When you ask if we should permit "footnotes and other non-content, non-caption
> markup inside <figure>", then you are actually on the same train as Shelley.
> 
> The only truly unambigous thing to do if we want to make it unanmbiguous "which
> part is the main content" is to stuff table and footones inside a unifying
> "content element". If the footnotes are not labeled by the caption, then they
> have nothing to do inside the figure.
> 

In your example the footnotes are contained within what I would call "the content", as opposed to "the caption". That example seems fine by me, no objections (except that <object> means nothing and has plenty of parsing quirks, just use <div> instead).

If dd/dt sticks, there is no ambiguity. Otherwise, anything not marked up as the caption is the content. The issue with my example is that it also has some license information which is neither content or not caption. I don't know if it's a good idea and this is certainly not the place to discuss it.

(In reply to comment #47)
> (In reply to comment #45)
> > (In reply to comment #44)
> > > (In reply to comment #43)
> > > > (In reply to comment #38)
> > > > > Here is another example of a table as a figure, this time with real data, not
> > > > > fake data meant for illustrative purposes:
> > > > > http://books.google.com/books?id=QbdMOM89qv0C&lpg=PA555&dq=%22table%20in%20figure%22&lr=&pg=PA556#v=onepage&q=%22table%20in%20figure%22&f=false
> > > > > 
> > > > > I can produce literally tens of examples of these without trying.  This is
> > > > > *precisely* the usage as currently defined in the spec.
> > > > 
> > > > And where do you place the footnotes of that table, so that it fits with what
> > > > is currently defined in the spec?
> > > 
> > > <figure>
> > >   <table>...</table>
> > >   <p caption>Figure 1: an illustrative table with content you can copy because
> > > the HTML5 spec [1] is so nice as to allow it inside &lt;figure></p>
> > >   <a class="reference" href="http://www.w3.org/TR/html5/">[1]</a><br>
> > >   <small>&copy; Santa Clause. No rights reserved.</small>
> > > </figure>
     
     [ snipping my example etc ]    

> In your example the footnotes are contained within what I would call "the
> content", as opposed to "the caption". That example seems fine by me, no
> objections (except that <object> means nothing and has plenty of parsing
> quirks, just use <div> instead).

I don't understand what you mean by <object> "means nothing". It clearly does.  HTML 5 fails to say that it is a sectioning root. But it clearly is. Or else screen readers would generate an outline that differs from the usual browsers.

And to say out in the air that <object> has many parsing quirks is not helpful. I am, in fact, not aware of any parsing bugs for <object> when it is used as a wrapper. OK, of course, i IE6/IE7 there are bugs. But that's the same for <figure><dt><dd></figure> - and the solution there was "use a div".  The solution to IE6/IE7's problem with <object> is the same: Use a div - even a span, depending on.
 
> If dd/dt sticks, there is no ambiguity. Otherwise, anything not marked up as
> the caption is the content. The issue with my example is that it also has some
> license information which is neither content or not caption. I don't know if
> it's a good idea and this is certainly not the place to discuss it.

Regarding the lisence info: this to mee seems like meta info, which should normally go into the caption. E.g. in online newspapers, the name of the photographer often goes into the image caption.

Bert Bos has written about captions: http://www.w3.org/Style/Examples/007/figures 
Bert learns us that HTML3 proposed a <fig> element: http://www.w3.org/MarkUp/html3/figures
And that XHTML2 (at one stage) had a caption element for <object>. 

All these examples talks about adding a caption to an image/graphic. I just mention it "for the record".

(In reply to comment #48)
> (In reply to comment #47)
> > (In reply to comment #45)
> > > (In reply to comment #44)
> > > > (In reply to comment #43)
> > > > > (In reply to comment #38)
> > > > > > Here is another example of a table as a figure, this time with real data, not
> > > > > > fake data meant for illustrative purposes:
> > > > > > http://books.google.com/books?id=QbdMOM89qv0C&lpg=PA555&dq=%22table%20in%20figure%22&lr=&pg=PA556#v=onepage&q=%22table%20in%20figure%22&f=false
> > > > > > 
> > > > > > I can produce literally tens of examples of these without trying.  This is
> > > > > > *precisely* the usage as currently defined in the spec.
> > > > > 
> > > > > And where do you place the footnotes of that table, so that it fits with what
> > > > > is currently defined in the spec?
> > > > 
> > > > <figure>
> > > >   <table>...</table>
> > > >   <p caption>Figure 1: an illustrative table with content you can copy because
> > > > the HTML5 spec [1] is so nice as to allow it inside &lt;figure></p>
> > > >   <a class="reference" href="http://www.w3.org/TR/html5/">[1]</a><br>
> > > >   <small>&copy; Santa Clause. No rights reserved.</small>
> > > > </figure>
> 
>      [ snipping my example etc ]    
> 
> > In your example the footnotes are contained within what I would call "the
> > content", as opposed to "the caption". That example seems fine by me, no
> > objections (except that <object> means nothing and has plenty of parsing
> > quirks, just use <div> instead).
> 
> I don't understand what you mean by <object> "means nothing". It clearly does. 
> HTML 5 fails to say that it is a sectioning root. But it clearly is. Or else
> screen readers would generate an outline that differs from the usual browsers.

"The object element can represent an external resource, which, depending on the type of the resource, will either be treated as an image, as a nested browsing context, or as an external resource to be processed by a plugin." Pretty close to "nothing" in terms of semantics.

But stating "it has no semantics" when your suggestion is "give in semantics X" is of course nonsense, I admit that. I don't think marking up the content rather than the caption makes much of a difference though.

> And to say out in the air that <object> has many parsing quirks is not helpful.
> I am, in fact, not aware of any parsing bugs for <object> when it is used as a
> wrapper. OK, of course, i IE6/IE7 there are bugs. But that's the same for
> <figure><dt><dd></figure> - and the solution there was "use a div".  The
> solution to IE6/IE7's problem with <object> is the same: Use a div - even a
> span, depending on.

If you think <object> is a good idea, take it to the list where more people can see it. I'll try to refrain from any discussing anything but the actual suggestion in this bug.

(In reply to comment #48)
> (In reply to comment #47)
> > (In reply to comment #45)
> > > (In reply to comment #44)
> > > > (In reply to comment #43)
> > > > > (In reply to comment #38)
> > > > > > Here is another example of a table as a figure, this time with real data, not
> > > > > > fake data meant for illustrative purposes:
> > > > > > http://books.google.com/books?id=QbdMOM89qv0C&lpg=PA555&dq=%22table%20in%20figure%22&lr=&pg=PA556#v=onepage&q=%22table%20in%20figure%22&f=false

> And to say out in the air that <object> has many parsing quirks is not helpful.
> I am, in fact, not aware of any parsing bugs for <object> when it is used as a
> wrapper. OK, of course, i IE6/IE7 there are bugs. But that's the same for
> <figure><dt><dd></figure> - and the solution there was "use a div".  The
> solution to IE6/IE7's problem with <object> is the same: Use a div - even a
> span, depending on.

Correction: I know about a single issue show-stopper, that is even a problem in
IE8: When <object> is used inside a <p>, and there is a <p> or (almost) any
other block element inside the <object>, then the <object> doesn't work as a
wrapper inside IE - since then the entire content of the <object> becomes
invisible (unless we use conditional comments or javascript to help it).

However, <figure> will not suffer from this problem, as <figure> is not
permitted inline, e.g. inside <p>. 

If however my idea to change <figure> to <cap> was followed, then then one may
run into this problem, of course. Just support my idea that we need to be able
to  apply captions to inline elments, and then we can discuss _that_ problem.
;-) 

But even in that case, the simple issues of adding a caption to an inline <img>
or even to an inline <table> (wrapped in an <object> - a DIV can't do that!),
there is no problem. (<table> inside <object> inside <p> doesn't suffer from
the parsing issues.)

(In reply to comment #49)
> (In reply to comment #48)
> > (In reply to comment #47)
> > > (In reply to comment #45)
> > > > (In reply to comment #44)
> > > > > (In reply to comment #43)
> > > > > > (In reply to comment #38)

> > > In your example the footnotes are contained within what I would call "the
> > > content", as opposed to "the caption". That example seems fine by me, no
> > > objections (except that <object> means nothing and has plenty of parsing
> > > quirks, just use <div> instead).
> > 
> > I don't understand what you mean by <object> "means nothing". It clearly does. 
> > HTML 5 fails to say that it is a sectioning root. But it clearly is. Or else
> > screen readers would generate an outline that differs from the usual browsers.
> 
> "The object element can represent an external resource, which, depending on the
> type of the resource, will either be treated as an image, as a nested browsing
> context, or as an external resource to be processed by a plugin." Pretty close
> to "nothing" in terms of semantics.
> 
> But stating "it has no semantics" when your suggestion is "give in semantics X"
> is of course nonsense, I admit that. I don't think marking up the content
> rather than the caption makes much of a difference though.

I think my proposal about <object> is in line with HTML 4. If you try to validate a page with the following code

<h1><h2>txt</h2></h1>

then you get this validation message:

 ]]
Line 12, Column 8: document type does not allow element "H2" here; missing one of "OBJECT", "MAP", "BUTTON" start-tag
<h1><h2>txt</h2></h1>
[[


> > And to say out in the air that <object> has many parsing quirks is not helpful.
> > I am, in fact, not aware of any parsing bugs for <object> when it is used as a
> > wrapper. OK, of course, i IE6/IE7 there are bugs. But that's the same for
> > <figure><dt><dd></figure> - and the solution there was "use a div".  The
> > solution to IE6/IE7's problem with <object> is the same: Use a div - even a
> > span, depending on.
> 
> If you think <object> is a good idea, take it to the list where more people can
> see it. I'll try to refrain from any discussing anything but the actual
> suggestion in this bug.

I believe that <object> is in line with that proposal, and that is why I "jumped in" here about it. <object> literally *is* an element that collects something into a figure. 

The actual suggestion of this bug is to refocus figure by only permitting certain elements inside it, namely those elements which can be said to represent something that can be justifyably be perceived as a  figure. Usually <object> has been used to present some graphic to the graphical user agents, while the "fallback" of the <object> has been presented a "the figure" for the rest of the audience. But since the understanding - *today* - finally has become that it is better, more accessible and more practical, to - as often as possible - just show the mark-up to all audiences, instead of showing a graphic to some and mark-up to some others, we can just "turn objeect upside down" and present the "fallback" to all audiences. 

I've sent an email to the HTML WG lists [1] on this item. 

Note, though, that I stand by the original bug, with the addition of the pre element for ASCII art. 

[1] http://lists.w3.org/Archives/Public/public-html/2009Dec/0005.html

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: Rejected
Change Description: no spec change
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.

I am glad the author and I agree, but the potential for this element to cause confusion is enormous. The definition for Figure now is in conflict with how figure has been primarily used in the publication industry.

Even those who have provided suggestions about how to caption the figure have made assumptions that the figure will only contain images, of some form. When people see other content, especially tables, they will no longer understand what figure really is. 

We would be better off without the element at all, and continuing to use the elements we have, then to use an element that has a definition that contradicts assumptions, given its name. And removal of the element entirely could be one of the change proposals attached to this as an issue. 

This bug has been escalated into a tracker issue:

http://www.w3.org/html/wg/tracker/issues/90

Per the proposal at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0245.html, the HTML A11Y TF does not plan to formally work on this issue at this time. This does not mean the TF has no interest in it, but does not have immediate plans to work on it. The TF may review the issue in the future.