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

Re: [Bug 6543] New: Mint a new element for figure captions

From: Leif Halvard Silli <lhs@malform.no>
Date: Wed, 11 Feb 2009 04:45:00 +0100
Message-ID: <499249BC.1010909@malform.no>
To: Robert J Burns <rob@robburns.com>
CC: HTML WG <public-html@w3.org>, Henri Sivonen <hsivonen@iki.fi>, Ian Hickson <ian@hixie.ch>, "Michael(tm) Smith" <mike@w3.org>

Robert J Burns 2009-02-09 09.08:
> ReportedBy: Henri Sivonen On Feb 9, 2009, at 1:17 AM:

>> [..] If <legend> is used, this is a rather notable barrier 
>> for author adoption of <figure> even if the generation of 
>> implied fieldset were removed in a future release.
>> 
>> Furthermore, the <legend> element comes with form-related DOM
>>  baggage: the HTMLLegendElement interface from DOM Level 2 
>> HTML.

Valid also for <details> which also uses <legend> for captions.

<legend> appears difficult to style in WebKit as well - it seems 
to be impossible to select via CSS, just like <caption>.

>> Since the English thesaurus has been exhausted, I suggest 
>> minting a new element name that has some qualifying prefix 
>> for the word "caption": e.g. <figcaption>. (I'm assuming here
>> that <rubric> wouldn't be appropriate.)

Unlike <rubric>, <figcaption> wouldn't work inside <details>.

What about <subject>? (In line with <figure>'s semantics, which is 
to represent content that "can be moved away from the main flow of 
the document without affecting the document's meaning.)

I would also like to suggest that <figure> and <details> should 
have a content elemen - e.g. <content>.  Many would be adding e.g. 
<div> on their own, anyhow. Having a <content> element would make 
it easier to select the content via CSS. Or what are the 
advantages of not having a content element?

> Since it seems "caption" is really the word we're looking for,
>  but legacy parsing wants caption to be properly placed in a 
> table, why not simply make a legacy synonym element  [...]

> <table f > <caption>some caption text</caption> <tr><td><img 
> src='uri' alt='alt text' > </table>

If the Mozilla folks are satisified with new elements,  then I 
would prefer such a solution.

I'm also not sure that <caption> is the best element. I would 
prefer to avoid anything that could make us primarely consider 
<figure> an advanced image presentation element. After all, its 
semantics are content "which can be moved away from the main flow 
of the document without affecting the document's meaning". A 
caption element such as "thema" or "subject" could in my view be 
better than "caption".

However, here is a backward compatible solution that you perhaps 
would not see the need for synonyms for:

<figure>
	<dd>figure body</dd>
	<dt>caption</dt>
</figure>

EITHER: one <dt> could be placed freely before or after <dd>, 
Though for IE 6/7 compatibility, <dt> must be last child;

OR: For maximum IE 6/7 compatibility - and ditto less CSS IE 6/7 
gymnastics: two <dt> elements could be permitted. One as first 
child and one as last child. One of them must be empty. (This 
latter option - two <DT> elements - could, in your words, be 
considered a synonym.)

- CSS gymnastics needed in IE 6/7 to display <dt> as top-caption;
- display:table-caption for all other browsers.
- <dd> to let Firefox 2 contain block elements without workarounds.
-- 
leif halvard silli
Received on Wednesday, 11 February 2009 03:45:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:01 UTC