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

Re: ISSUE-83 ACTION-152 Change Proposal for the use of dt/dd in figure and details

From: Shelley Powers <shelley.just@gmail.com>
Date: Fri, 27 Nov 2009 13:40:54 -0600
Message-ID: <643cc0270911271140u3093ddb8id7f42b382bad6300@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Jeroen van der Gun <noreplytopreventspam@blijbol.nl>, public-html <public-html@w3.org>
On Fri, Nov 27, 2009 at 9:53 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Thu, Nov 26, 2009 at 4:54 PM, Jeroen van der Gun
> <noreplytopreventspam@blijbol.nl> wrote:
>> Hello folks,
>>
>> This proposal lists three reasons for the change. I'd like to point
>> out that I discovered that one of them, the technical failure in IE6
>> and IE7, is actually invalid.
>>
>> The problem is about styles getting leaked to the parent. By putting
>> the figure or details element inside a div element, the closing tag of
>> the div effectively solves the problem. Since this div needs to exist
>> anyway to be able to style the figure or details element (since
>> unknown elements cannot be styled in IE), the only way this problem
>> can occur is if the dd or dt element is styled, but the figure or
>> details element is not. So in reality this IE bug will rarely occur,
>> and even if it does, it is extremely easy to solve.
>>
>> You can read more about this at my blog (test demonstration included):
>> http://blog.jeroenvandergun.nl/7-html5-figure-and-details-do-not-break-in-ie
>>
>> Please take this into consideration before changing the HTML5 specification.
>
> Yup, that seems to work just fine.  It's not *perfect* - the <dt>/<dd>
> elements themselves still have some very slight rendering oddities†,
> but they're minor enough that they won't matter in most cases, and can
> be easily patched up with conditional styles when necessary (they're
> no worse than the rendering oddities we see everyday in IE7 and IE6
> already).
>
> Henry Sivonen says that this is caused by <div> being a scoping
> element.  I don't understand enough of the parsing internals to really
> grasp what this means, but hey, it works!
>
> A note: You do have to attach the styles to the wrapping <div>, not
> the <figure>.  This becomes even more important when you consider the
> footnote to this email.
>
> † The rendering oddities actually seem to be caused by <figure> itself
> - it's possible that IE<8 is still actually creating a non-tree DOM in
> some manner, but the damage is contained by the <div>.  This can be
> avoided entirely by *not* using document.createElement("figure") to
> make IE recognize it.  Instead, just let the legacy IEs do their
> strange double-void-element thing with <figure></figure>.  Attach all
> the styles that *would* go on <figure> to the <div.figure> instead,
> and pair it with a single "figure { display:block; }" declaration
> (otherwise you get an extraneous linebox at the bottom of the
> element).
>
>
> So, in summary:
> 1) Wrap your <figure>s in <div class=figure>.
> 2) Do *not* do the document.createElement() hack for "figure".
> 3) Attach all the styling that you'd like to put on <figure> to the
> div.figure instead.
> 4) Attach a simple "display:block" declaration to figure itself (you
> have to do this anyway for the other browsers).
>
> With these guidelines, you can use <figure> in IE6 and IE7 without a
> problem.  I haven't tested yet, but presumably you can do the same
> with <details>.
>
> ~TJ
>
>


Or we could use a new element, which doesn't require wrapping figure
in a div element, and also satisfy the two other expressed concerns,
too.

Or we could just get rid of both figure and details.

Shelley
Received on Friday, 27 November 2009 19:41:24 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:54 UTC