[whatwg] <figure> element feedback

[Ian Hickson]

<figure> was changed some time back to allow any content and to allow the 
legend to be omitted. At the time this was done as part of a content model 
overhaul and so I forgot to respond to some of the <figure> feedback. (I 
haven't quoted most of the feedback asking for this below, since many of 
the same points were made several times.)

On Mon, 27 Nov 2006, Michel Fortin wrote:
> 
> To me, a figure contains illustrative content attached to a document. It 
> may be an image, a code sample, or a snippet of another document used as 
> an example. I think it's important we do not try to narrow too much what 
> can and what cannot be contained in a figure; that's the job of the 
> author do decide.

Done.


> Moreover, I don't think the caption should be mandatory. I know that the 
> primary reason for including a figure element is to have a way to put 
> captions on things, but <figure> as a simple container for illustrative 
> content has value too. For instance, I would gladly use <figure> to 
> denote HTML snippets in the following document of my own website:
> 
> <http://www.michelf.com/projects/php-markdown/concepts/>
> 
> Would this be a valid usage? (Of course, according to the current spec: 
> no. But should it be?)

It's not valid.


> > This one in particular:
> > 
> > > http://politics.guardian.co.uk/homeaffairs/story/0,,1806799,00.html
> > 
> > ...suggests we may want to have multiple <legend> elements per 
> > <figure>, to allow for a caption and photo credit to be given. What do 
> > people think? Would some other way of inline giving photo credit 
> > metadata be better?
> 
> I think that could be useful. But my opinion is that it'd probably be 
> better to find a way to do this in the same manner for table captions 
> too. (A table caption citing the source for its data is quite common.) I 
> think it'd be wiser to do this using inline elements inside <legend> or 
> <caption>.

I haven't added <credit> yet... I'd rather see how <figure> fares as is 
before adding more stuff.


On Tue, 28 Nov 2006, fantasai wrote:
> 
> I'd suggest using <address>, e.g.
> 
>   <figure>
>     <img>
>     <address>Photo by Mariel</address>
>   </figure>
> 
>   <figure>
>     <img>
>     <caption>Carcassonne</caption>
>     <address>Photo by Mariel</address>
>   </figure>

Yeah, that might make sense, even. Right now the content model allows it, 
so long as the <legend> comes last (or first), so feel free to experiment 
with this.


On Tue, 28 Nov 2006, Benjamin Hawkes-Lewis wrote:
> 
> Mere attribution is not "contact information". If all attributions 
> included a link to the creator's or copyright holder's webpage, or an 
> email address, that would work, but there's no guarantee they will. Such 
> usage dilutes the meaning of <address/>.

<footer> could work too, to some extent. I mean, it's not right per spec 
now, but if people experiment with it I'd be interested in hearing of the 
results, they wouldn't certainly influence how the spec develops.


On Tue, 28 Nov 2006, L. David Baron wrote:
> On Tuesday 2006-11-28 01:49 +0000, Ian Hickson wrote:
> >    <figure>
> >      <img ...>
> >      <legend> ... </legend>
> >    </figure>
> > 
> > There are special rules for what to do with 
> > fallback that basically make the caption disappear (though of course this 
> > won't happen in legacy UAs).
> 
> I'm assuming the rules you're referring to are those at: 
> http://www.whatwg.org/specs/web-apps/current-work/#figure0
> 
> Are these rules worth the complexity they add?
> 
> I think in many cases they may actually be harmful.  In particular, 
> authors who aren't thinking much about fallback content may be writing 
> captions that would be the most useful fallback content available.  
> Insisting that those captions not be available when there is no fallback 
> content seems like a bad idea.

This is all gone now.


On Tue, 28 Nov 2006, David Walbert wrote:
> > 
> > This one in particular:
> > 
> > > http://politics.guardian.co.uk/homeaffairs/story/0,,1806799,00.html
> > 
> > ...suggests we may want to have multiple <legend> elements per 
> > <figure>, to allow for a caption and photo credit to be given. What do 
> > people think? Would some other way of inline giving photo credit 
> > metadata be better?
> 
> Yes, I think a separate element for credit would be great. The caption 
> and credit are functionally different. A caption tells the reader why an 
> image has been included in the page; a credit tells where it came from.
> 
> I've done a quick survey this morning of magazines and textbooks around 
> the office, and confirmed my suspicion that typically, caption and 
> credit are displayed and styled separately. I think they would be more 
> often separated on the web if average web design was as careful and 
> competent as average print design. They look the same on the Guardian's 
> website, but most often, the caption is small sans-serif text placed 
> directly under or beside the photo with little margin, and the caption 
> is in larger text slightly farther below the image. If the credit is in 
> the same visual block with the caption, it's often presented in a 
> different font. The photo on this page, rather unfortunately, shows both 
> designs:
> 
> http://www.npr.org/templates/story/story.php?storyId=6545249
> 
> Obviously, styling doesn't determine semantics, but if the design is 
> thoughtful styling does reflect semantics, and the stylistic conventions 
> help readers to process the caption and credit separately as they read. 
> If practical, the same assistance ought to be available to non-sighted 
> readers.
> 
> When there are several images on a page, an author might wish to put all 
> of the photo credits at the bottom so as not to clutter up the 
> presentation unduly, but if the credit were a separate element, that 
> could be done with scripting while leaving the semantics intact.

Thanks for this research. (The page above seems to have changed, sadly.)


> Would the credit element, whatever it is called, be block or inline? 
> Semantically I don't believe it makes much difference. I suppose I'd 
> recommend that it be an inline element inside the <legend>, because then 
> with CSS I could declare it to be display: block and pull it out, 
> whereas if it's a block-level element, there's no easy way to put it 
> back inside the legend.

Interesting idea. Having it be inline in the legend would kind of make 
sense, indeed. If people want to experiment with that, I recommend using 
<span class="credit">...</span> and letting me know how that works out.


On Tue, 28 Nov 2006, Jeff Seager wrote:
> 
> For practical and semantic reasons, photo credit metadata ought to 
> follow the image itself as closely as possible. Copyright laws require 
> artists to "affix" the notice (including the creator's name) to the 
> protected work; not that copyright protection is our concern, but it's 
> an example of practical and essential usage.
> 
> I think the artist's name and copyright notice are worthy "advisory 
> information" to be included in the TITLE attribute of <img>, <embed>, or 
> <object>, and this has been possible for some time. Attribution -- with 
> or without a copyright advisory -- could be styled optionally as part of 
> the <legend>, but I don't think it warrants another instance of <legend> 
> for the same image or object.

That makes sense to me, yes.

Experimenting with putting credit information in the image title="" 
attribute would be another area from which we could learn valuable lessons 
about how we should move forward with this.


On Tue, 28 Nov 2006, James Graham wrote:
> David Walbert wrote:
> >
> > I think that this broad notion of a "figure" is quite clever but 
> > frankly too clever for the typical person using HTML. It requires a 
> > level of editorial decision-making that I fear will confuse more 
> > authors than it helps, and confused authors make a confusing web.
> 
> Broad semantics mean that UAs can do fewer useful things with the 
> information. That dilutes the value of having any semantics at all.

True enough, though in the case of figures, I think the semantics are 
still pretty clear, and the class attribute can be used to narrow it 
further (e.g. for books that want to list "charts" and "tables" and 
"images" in separate indexes).


On Sun, 3 Dec 2006, Simon Pieters wrote:
> 
> If <figure> is intended to be used for thumbnails then we have to allow 
> <a> around the embedded content:
> 
>   <figure>
>    <a href="foo-larger.html"><img alt="..." src="foo.png"></a>
>    <legend>...</legend>
>   </figure>
> 
> Clicking on the image is how most galleries work AFAIK -- the link is 
> mostly not in the caption.

This is now allowed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'