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

[Bug 8404] Refocus the figure element back to being a figure

From: <bugzilla@wiggum.w3.org>
Date: Tue, 01 Dec 2009 01:45:09 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1NFHnh-0003Ot-P3@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8404


Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xn--mlform-iua@xn--mlform-
                   |                            |iua.no




--- Comment #33 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>  2009-12-01 01:45:08 ---
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.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 1 December 2009 01:45:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:30:42 UTC