- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 25 Feb 2008 22:42:29 +0000 (UTC)
- Cc: whatwg List <whatwg@whatwg.org>, "public-html@w3.org WG" <public-html@w3.org>
Executive summary:
* I've kept <legend> as the way to mark up the title of figures.
See immediately below this summary for details on that decision.
* I've allowed any prose or phrasing content to be put in <figure>
elements.
* I'm made the caption optional.
* I added examples.
The legend issue:
Right now there are 13 different elements in HTML that define areas that
give a title or heading or some such for another area. They all have
issues when it comes to being re-used here. There are also some other
elements we could use. Here's a run-down of the possibilities, and the
reasons why they don't work (I've only given one reason, even if
multiple reasons apply, when the reason is important enough):
<title>
Parsing issues in at least Firefox and Safari:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement('figure')%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%3Cfigure%3E%0A%20%3Ctitle%3Efigure%3C%2Ftitle%3E%0A%20content%0A%3C%2Ffigure%3E
This can't be fixed in the spec.
<caption>
Parsing issues in at least Firefox and Opera:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement(%27figure%27)%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%3Ctable%3E%3Ctr%3E%3Ctd%3E%0Acell...%0A%3Cfigure%3E%0A%20%3Ccaption%3Efigure%3C%2Fcaption%3E%0A%20content%0A%3C%2Ffigure%3E%0A...cell%3C%2Ftd%3E%3C%2Ftr%3E%3C%2Ftable%3E
This can't be fixed in the spec.
<th>
Parsing issues in at least Firefox, Safari, and Opera:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement(%27figure%27)%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%3Ctable%3E%3Ctr%3E%3Ctd%3E%0Acell...%0A%3Cfigure%3E%0A%20%3Cth%3Efigure%3C%2Fth%3E%0A%20content%0A%3C%2Ffigure%3E%0A...cell%3C%2Ftd%3E%3C%2Ftr%3E%3C%2Ftable%3E
This can't be fixed in the spec.
<label>
This would preclude any sane way of putting form controls in
legends, which would be bad.
This can't be fixed in the spec.
<dt>
Parsing issues in at least Firefox, Safari, and Opera:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement('figure')%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%3Cdl%3E%0A%20%3Cdt%3Edt%0A%20%3Cdd%3Edd%0A%20%20%3Cfigure%3E%0A%20%20%20%3Cdt%3Efigure%3C%2Fdt%3E%0A%20%20%20content%0A%20%20%3C%2Ffigure%3E%0A%3C%2Fdl%3E
This can't be fixed in the spec.
<h1>
<h2>
<h3>
<h4>
<h5>
<h6>
<header>
<p>
<div>
All of these are a problem because if we expand <figure> to support
arbitrary prose content, there's no way to tell if a particular one
of these elements is being used as the legend or not.
In addition: <h1>-<h4> would have poor default styling in
legacy UAs. <h1>-<h6> would also complicate the already-complex
outlining algorithm. <h2>-<h6> would, I think, be very confusing to
authors, to the point of canceling out any benefit of <figure> in
the first place. <header>, <p>, and <div> all seem like the wrong
element, conceptually.
<legend>
Parsing issues in Firefox and IE:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement(%27figure%27)%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%3Cfieldset%3E%0A%20...%0A%20%3Cfigure%3E%0A%20%20%3Clegend%3Efigure%3C%2Flegend%3E%0A%20%20content%0A%20%3C%2Ffigure%3E%0A%20...%0A%3C%2Ffieldset%3E
...and the element doesn't appear in the DOM when there's no
<fieldset> in at least Safari and Firefox.
This is quite the messy situation.
I think we should discount <dt>, <h1>-<h6>, <header>, <div>, and <p> right
off the bat, since they would confuse matters greatly. We should similarly
discount <title>, <caption>, <th>, <dt>, and <label>, because the problems
with those can't be fixed.
That leaves <legend>, or inventing a new element. Both options are
unappealing.
One of the advanages with <legend> is that while the parse issues today
are messy, we can fix those (indeed the spec now has them fixed already,
though we might want to consider making <legend> close <p> tags).
A new element would be a neat solution, but frankly I'm out of words to
use, and if we keep adding new ways to mark up titles and captions and
legends and labels, authors aren't going to be able to work out when they
should use each element. Various people suggested various element names in
the e-mails below, but from the names proposed it should be clear that we
are scarping the bottom of the barrel. I'd rather have a cleaner solution
for something that could be with us for years to come.
I think our only option is to use <legend>, and, while in the migration
period, have people use markup like:
<figure>
<legend><span class="legend"> ... </span></legend>
...
</figure>
...with styles like:
figure > legend, figure > .legend { ... }
On Fri, 9 Feb 2007, Michel Fortin wrote:
> > >
> > > With the current state of the <figure> element, you can't do this. I
> > > remember proposing a while ago that <figure> accepts more than a
> > > single embedded elements. That seem to be a good use-case.
> > >
> > > <figure>
> > > <img ...>
> > > <img ...>
> > > <img ...>
> > > <legend>...</legend>
> > > </figure>
> >
> > So, if figure doesn't allow this, how can it be done? With present
> > specs and with future specs? (of course, I'm not talking of rendering
> > but of semantics there)
>
> By improving the current spec, by going back to what you were using with
> HTML4, or by ignoring the spec and doing it anyway. I'm advocating the
> former.
Done.
On Thu, 15 Mar 2007, Lachlan Hunt wrote:
> Colin Lieberman wrote:
> >
> > For the given use case:
> >
> > <header>
> > <h1><img src="/images/logo" alt="Company Name"></h1>
> > <object data="flash"></object>
> > </header>
> >
> > I think <figure> is in appropriate. The spec says: 'The |figure|
> > element represents a paragraph consisting of embedded content and a
> > caption.' and from a semantic point of view, figure seems to connote
> > an illustration or explanatory image.
>
> I thought of using figure, but it currently requires legend to provide a
> caption, but in this case there is no caption. Even if figure were
> allowed to be used without legend, what would be the point? That would
> be no better than just adding an extraneous wrapper <div> around the
> object just to work around the content model restrictions.
The restrictions are gone now. I've also made the caption optional.
> > I have no problems with images remaining inline only.
>
> I think all embedding elements, including img, should be allowed to be
> used in the same places. I consider it a mistake that HTML4 allows
> object to be used almost anywhere, but img only inline.
This is now fixed too.
On Wed, 14 Mar 2007, Michel Fortin wrote:
>
> If <figure> denotes illustrative content, your image then becomes an
> illustration of the subject in the surrounding text. Otherwise, you have
> no way to distinguish images which are meant to be read as part of the
> text -- mathematic formulas embedded as images for instance -- and those
> which are more detached from the prose -- a photo illustrating the
> text's subject.
Indeed.
> I'd like to submit this example of a news article having two pictures;
> both are styled the same, they both have the same purpose
> (illustration), yet one has no caption while the other has one.
>
> <http://www.radio-canada.ca/arts-spectacles/PlusArts/2007/03/13/003-viacom_youtube.asp>
>
> If we say the second picture is a figure, how can we reasonably say the
> first one is not? A table does not need a caption to be a table, and I
> don't think a figure needs a caption to be a figure: it just needs to be
> an illustration of the surrounding subject.
Agreed.
On Wed, 14 Mar 2007, Colin Lieberman wrote:
>
> Great example.
> (http://www.radio-canada.ca/arts-spectacles/PlusArts/2007/03/13/003-viacom_youtube.asp)
>
> My reading is that one would use <figure> as the block-level parent of the
> second image, where the first image could happily be inline.
Both, IMHO, are appropriate for <figure>.
On Mon, 16 Jul 2007, Michel Fortin wrote:
>
> Since I'm not convinced that the current content model for <figure> is
> adequate [1], I decided to dig more examples where figures in HTML pages
> would be hard to fit with the current model. Here are the results.
Thank you hugely for this research! This is very useful. I have updated
the spec to handle these cases, and given examples of some of the key
ones. Let me know if you think anything else deserves an example.
> It could also be useful to allow labeling of subfigures, perhaps like
> this:
>
> <figure>
> <figure><legend>(a)</legend> <img ...></figure>
> <figure><legend>(b)</legend> <img ...></figure>
> <legend>My house seen (a) from the front; (b) from the back</legend>
> </figure>
This is allowed, but I haven't included an example.
On Thu, 16 Aug 2007, Simon Pieters wrote:
> >
> > The spec as it stands now makes a distinction between alt="" and no
> > alt.
>
> How does no alt integrate with the semantics of <figure> in the fallback
> case?
There's no fallback concern anymore. :-)
On Sun, 16 Sep 2007, Maciej Stachowiak wrote:
>
> 1) I propose using <label> for the element that holds the caption of an
> image instead of <legend>. I believe this would allow for easier
> graceful degradation. They seem to be about equally semantically close
> to the word "caption".
<label> unfortunately would preclude putting more than one form control in
a legend, which would be a weird restriction.
> Current browsers handle <legend> that's outside a fieldset oddly:
>
> - Firefox and Safari drop the element entirely from the DOM when it appears
> outside a <fieldset>.
> - Opera puts the <legend> in the DOM as a void element, and inserts its
> contents afterwards.
> - IE adds a void <legend> element and a void </legend> element before and
> after the text.
Opera actually does better than that, but yes, the situation is poor
today. Hopefully it can be improved. In any case, it can be worked around
on the short term with a <span> element as noted earlier.
> <label> doesn't have any of these problems.
It has others. :-)
>
> 3) Lachlan Hunt points out two possible problems with using <label>:
>
> 3.a) It may interfere with assistive technology to have labels that
> don't contain a form control and are not associated with a form control
> via "for". Neither of us was sure if this would be a real problem. If
> anyone could test this, it would be helpful.
>
> 3.b) Authors may have existing styling for label for form control
> purposes that's not specifically scoped via classes, ids or descendant
> rules. In this case, they would have to undo it for figure labels. The
> same issue is possible in theory for <legend>, but the use of <fieldset>
> seems to be relatively rare as it does not fit well with modern
> visual/interaction design.
>
> I think the problems with using <legend> are more serious than either of
> the above problems.
3.c) it would force any form control in a legend (label) to be focused
whenever any part of the legend was clicked. It would break if you had
more than one form control.
I think 3.c is more serious than the (temporary) parsing problems with
<legend>.
> 4) Another alternative would be using a new unknown element. Whipping
> out my thesaurus, I see <rubric>, <inscription>. Another possibility is
> something like <figcaption> (to avoid the problems <caption> would cause
> for figures inside tables), but that wouldn't be a good fit for
> <details>.
<figcaption> and <detailscaption> and so on just seems like it would make
the language really complicated.
We've waited years for <figure>, can't we wait a few more while browsers
get their act together in their parsers?
On Sun, 16 Sep 2007, Ben Boyle wrote:
> >
> > 1) I propose using <label> for the element that holds the caption of
>
> That does sound better than <legend> which really does not mean quite
> the same thing as caption/label (or the intended purpose of the
> element). I don't really care about the implementation issue :)
Actually I think legend is a more accurate name than label for a figure.
But that may be my dialect.
> Check out dublin core: <description> [1] and <title> [2] (already an
> element) jump to mind as good candidates for generic elements of this
> nature. I would support <description> iff it was generic and could be
> used throughout the document to associate any description with its
> container element (e.g. figure, fieldset, table, video, etc.)
Sadly this isn't a description, and <title> has even bigger parsing
problems.
On Mon, 17 Sep 2007, Lachlan Hunt wrote:
>
> I think you're dismissing the pre-existing styling issue too quickly. It
> needs to be as easy as possible to migrate existing sites to HTML5 in
> the future, so we need to consider what kinds of issues authors will
> face in practice.
>
> A lot of authors style labels in a variety of non-trivial ways to
> achieve various form layouts, This often includes, among other things,
> floating, margins, padding, text alignment, colours, cursor pointers,
> etc. and writing styles to undo all of them in the figure case is not
> really that trivial in all cases.
It's true that this would cause issues with <label>.
> Since in IE, the label wouldn't be a descendant of the figure element,
> the labels could not be selected using the selector:
>
> figure label { ... }
>
> It would require the use of an additional class name or containing
> element, or for the DOM to be fixed up with a script.
Well we're going to need this anyway.
> Is it possible for browsers to fix their handling of legend, so that it
> appears in the DOM when used outside of fieldset? Maciej indicated in
> IRC that this may be done as a way to avoid other problems. [1]
> [1] http://krijnhoetmer.nl/irc-logs/whatwg/20070916#l-65
>
> <othermaciej> <legend> is given special rendering behavior in a
> <fieldset> that can't be expressed with CSS
> <othermaciej> browsers probably ignore it in other places as a way to
> avoid causing problems with that in other places
>
> When <figure><legend> occurs within a fieldset, the legend element is also
> given that special styling. [2]
> [2] http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Afigure%20%7B%20display%3A%20table%3B%20background%3A%20lime%3B%20%7D%0Afigure%20legend%7B%20display%3A%20table-caption%3B%20text-align%3A%20center%3B%20caption-side%3A%20bottom%3B%20background%3A%20yellow%3B%20%7D%0Afigure%20legend%3Afirst-child%20%7B%20caption-side%3A%20top%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cfieldset%3E%3Clegend%3EFieldset%3C%2Flegend%3E%3Cfigure%3E%3Cimg%20src%3Dimage%3E%3Clegend%3ECaption%3C%2Flegend%3E%3C%2Ffigure%3E%3C%2Ffieldset%3E
>
> >
> <fieldset>
> <legend>Fieldset</legend>
> <figure>
> <img src=image>
> <legend>Caption</legend>
> </figure>
> </fieldset>
>
> In Firefox 2 and IE7, the legend element does not occur within the
> figure and it is given the special default styling.
>
> In Safari 3 Beta (Win), the figure's legend element isn't present within
> the DOM.
>
> In Opera 9.5, the legend element is a child of figure, but it's given
> the special styling and author styles are limited, as usual.
>
> Additionally, in Firefox, if the fieldset doesn't have its own legend,
> the figure's legend is visually moved to the top of the fieldset, to the
> normal position.
Yeah, it's a big mess. (<figure> inside <fieldset> will happen rarely,
though, so that particular issue isn't a big deal.)
> For figure captions:
> * <figcaption>
> * <cap>
> * <capt>
> * <cptn>
> * <description>
> * <desc>
> * <tag>
> * <tagline>
> * <caption2>
>
> For details:
> * <detailslabel>
I'm really worried about adding more elements. We already have so many
that mean "caption". People will just get more and more confused.
On Sun, 16 Sep 2007, Maciej Stachowiak wrote:
>
> I'm sure it's possible to fix this. But it seems to me that a new
> element will not encounter these problems at all and so will work back
> to even older browser versions (Safari 2, Firefox 1.5, etc). So a new
> element seem to be better than <legend> with almost no disadvantages
> (just the relatively minor one of introducing more new elements).
I'd agree, if it wasn't for the sheer number of elements we already have
for this very semantic.
On Mon, 17 Sep 2007, Philip Taylor wrote:
>
> Looking at the contents of the <style>s and <link
> rel="...stylesheet...">s from 1024 pages listed on dmoz.org, of which
> 884 were downloaded with no errors or timeouts, of which 559 had some
> CSS (not counting style="..."): 35 had rules involving "label"; roughly
> half of them were just "label", and roughly half had "something label"
> or "label.something".
>
> So, about 3% of people using CSS on sites like what dmoz.org is
> representative of, multiplied by the fraction that want to use
> <figure>+<label>, would have to make changes (perhaps just modifying
> their CSS to say "form label { ... }").
Interesting.
On Sat, 7 Apr 2007, Henri Sivonen wrote:
>
> A strict reading of the transparent content models of <video> and
> <audio> means that when used as the embedded content child of <figure>,
> <video> and <audio> also need exactly one embedded content child. This
> means that an embedded content fallback is mandatory (telescoping
> terminated e.g. by <img>).
>
> Is this intentional or does the transparent part mean transparent *or
> empty*? If it indeed is intentional, it should probably be noted
> explicitly.
This is fixed now, right?
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 25 February 2008 22:42:53 UTC