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 04:32:03 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1NFKPD-00053g-DN@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8404





--- Comment #37 from Shelley Powers <shelleyp@burningbird.net>  2009-12-01 04:32:01 ---
(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.


-- 
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 04:32:05 UTC

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