[whatwg] [html5] Image captions in FIGUREs

[Ian Hickson]

On Tue, 14 Jul 2009, Oldøich Vete¹ník wrote:
> Dne Tue, 14 Jul 2009 02:52:22 +0200 Aryeh Gregor <Simetrical+w3c at gmail.com>
> napsal/-a:
> > On Mon, Jul 13, 2009 at 8:29 PM, Aen Tan<hello at aentan.com> wrote:
> > > I was specifically referring to the LEGEND element.
> > 
> > That seems to work less.  WebKit just removes it from the DOM.  Are 
> > you suggesting that for compatibility, it should be named something 
> > else so that it works at least as well as the other elements?
> 
> Indeed, unless browsers let us style <legend> any way we want (let's say 
> like <span> element), people won't use it (in figures) because it 
> wouldn't be flexible enough.

On Wed, 15 Jul 2009, Aryeh Gregor wrote:
> 
> The element can't be styled in either Firefox 3.5 or recent WebKit 
> because, according to my testing, it simply doesn't exist in the DOM. 
> Any <legend> that's not in a <fieldset> is just ignored during parsing, 
> apparently.

On Wed, 15 Jul 2009, Tab Atkins Jr. wrote:
> 
> On the note of <legend> styling, currently a legend-in-fieldset isn't
> handled by the standard CSS renderer *at all* in FF, last I heard, due
> to the magic inherent in its display:
>   * automatically positioning itself on top of the <fieldset>'s border
> without using abspos (the fieldset would need to be relpos or similar
> to allow this to work) regardless of where in the <fieldset> the
> <legend> appears (this precludes use of margin to pull it upwards,
> because it might not appear as the first child).
>   * hiding the border of the fieldset behind it without hiding the
> background of the fieldset, or any borders or padding of any
> lower-layer elements.

On Wed, 15 Jul 2009, Aryeh Gregor wrote:
> 
> I may have misremembered the results.  I get that in Firefox 3.5 too. In 
> Chrome (Linux dev channel -- presumably applies to recent Safari builds 
> too), I get the legend element simply not appearing in the DOM.

On Thu, 16 Jul 2009, Boris Zbarsky wrote:
> 
> Just as a note, I believe we consider both of these bugs, and plan to 
> change behavior there.

On Thu, 16 Jul 2009, Boris Zbarsky wrote:
> 
> More precisely it's handled as having a special "position" value that 
> you can't override, more or less, and that position value forces 
> float:none and display:block and certain sizing behavior, more or less.  
> All of this is expressed in CSS.  After that you use the CSS renderer...  
> On the other hand, <fieldset> itself is pretty weird in terms of the way 
> it renders; it doesn't use any of the standard CSS box types.  The box 
> type it does use makes certain assumptions about the styling of the 
> <legend>.  All that might get changed, but it only matters for <legend> 
> in <fieldset>.  Current trunk Gecko handles <legend> outside <fieldset> 
> as just another block, in terms of the renderer. How you get such a DOM 
> is a separate issue.  Firefox 3.5 and earlier does weird things for 
> <legend> outside <fieldset>.

My plan here is to continue to wait for a while longer to see if the 
parsing issues can get ironed out (the HTML5 parser in Gecko for instance 
solves this problem for Firefox). If we really can't get past this, we'll 
have to introduce a new element, but I'm trying to avoid going there.

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