W3C home > Mailing lists > Public > public-html@w3.org > September 2007

Re: Proposal for <figure> graceful degradation

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 16 Sep 2007 16:53:30 -0700
Cc: "public-html@w3.org WG" <public-html@w3.org>
Message-Id: <74E94F93-DEE6-4E95-87BA-629CB5844716@apple.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>


On Sep 16, 2007, at 7:31 AM, Lachlan Hunt wrote:

>
> Maciej Stachowiak wrote:
>>    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.
>
> 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.

I acknowledge this, the only reason I think it might be remotely  
workable is that the first few sites I looked at with styled labels  
seem to mostly use "form label" or ".someFormClass label" rules  
instead of just "label". (Or, sadly, they don't use a label element at  
all but instead a <div> or <p>).

> 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.

I think IE will require script-based fixup (or namespace trickery) in  
any case.

>
> This issue may still happen with legend as well, though its likely  
> to be to a much lesser extent because the current limitations with  
> styling fieldset legends mean that fewer styles are typically  
> applied. Although, I do agree the current problems with legend are  
> serious, I think we need more information from browser vendors.
>
> 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]

[...]

> In Safari 3 Beta (Win), the figure's legend element isn't present  
> within the DOM.

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).

Thus, in my opinion, the only reasonable choice is between <label> and  
one or more new elements.

Pro <label> / Con new element:
- Requires slightly less script-based fixup in IE
- Avoids introducing new elements (with some annoying naming choices  
to be made)

Pro new element / Con <label>:
- New elements won't risk colliding with pre-existing styles


Out of the new names, I kind of like figcaption/detailslabel even  
though it's two elements instead of one.

Regards,
Maciej
Received on Sunday, 16 September 2007 23:53:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:49 UTC