Bug 56967 – Convert summary and details elements to use new shadow DOM

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Dimitri Glazkov (Google)]

Great use case for the output ports.

[Luiz Agostini]

As I just have implemented the previous version I would be very interested in doing this conversion with your revision. May it be?

[Kenneth Rohde Christiansen]

(In reply to comment #1)
> As I just have implemented the previous version I would be very interested in doing this conversion with your revision. May it be?

That would be a great fit and I'm sure Dimitri needs all the help he can get porting things over to using the shadow DOM. Let's see what he says.

[Dimitri Glazkov (Google)]

(In reply to comment #2)
> (In reply to comment #1)
> > As I just have implemented the previous version I would be very interested in doing this conversion with your revision. May it be?
> 
> That would be a great fit and I'm sure Dimitri needs all the help he can get porting things over to using the shadow DOM. Let's see what he says.

Happy to get any help I can get.

The challenge right now is that we are missing a piece of plumbing -- the ability to forward child nodes of an element down the shadow DOM subtree. The equivalent bit in XBL2 is http://dev.w3.org/2006/xbl2/#the-content-element.

For example, I imagine we design our implementation like this:

details
   div::-webkit-summary-panel -- represents the panel in which summary is laid out.
      div::-webkit-details-indicator -- represents open/closed indicator of details
      summary
   * -- any other elements.

The divs in this tree will be in the shadow DOM. The summary, although rendered as child of the shadow DOM divs, is actually a direct child of details when viewed from DOM.

Implementing this plumbing will be the first step.

[Luiz Agostini]

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > As I just have implemented the previous version I would be very interested in doing this conversion with your revision. May it be?
> > 
> > That would be a great fit and I'm sure Dimitri needs all the help he can get porting things over to using the shadow DOM. Let's see what he says.
> 
> Happy to get any help I can get.
> 
> The challenge right now is that we are missing a piece of plumbing -- the ability to forward child nodes of an element down the shadow DOM subtree. The equivalent bit in XBL2 is http://dev.w3.org/2006/xbl2/#the-content-element.
> 
> For example, I imagine we design our implementation like this:
> 
> details
>    div::-webkit-summary-panel -- represents the panel in which summary is laid out.
>       div::-webkit-details-indicator -- represents open/closed indicator of details
>       summary
>    * -- any other elements.
> 
> The divs in this tree will be in the shadow DOM. The summary, although rendered as child of the shadow DOM divs, is actually a direct child of details when viewed from DOM.
> 
> Implementing this plumbing will be the first step.

I will be happy to help. I will start looking at these issues tomorrow.

[Lachlan Hunt]

For reference, Opera's experience with attempting to implement this was posted to the WHATWG list.

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-April/031132.html

Our own conclusion at Opera was that depending too heavily on bindings created too many problems, and we came up with a far simpler approach reusing mostly existing CSS infrastructure that actually had several advantages, and significantly minimised the impact that shadow content had upon the layout.  We'd be happy to discuss these issues with you, and of course would ultimately like our implementations to be compatible.

[Dimitri Glazkov (Google)]

*** Bug 58455 has been marked as a duplicate of this bug. ***

[Hajime Morrita]

I just started to investigate this.
I think the first step is to give a shadow element for RenderDetailsMarker.
We can introduce node forwarding mechanism after that.

[Dimitri Glazkov (Google)]

(In reply to comment #7)
> I just started to investigate this.
> I think the first step is to give a shadow element for RenderDetailsMarker.
> We can introduce node forwarding mechanism after that.

Great! Note that my diagram above is wrong. The marker should be in the shadow DOM of the <summary>, because the marker should hit-test as part of it.

[Dimitri Glazkov (Google)]

This is fixed now, right?

[Hajime Morrita]

(In reply to comment #9)
> This is fixed now, right?
Bug 59157 is the last bit.

[Luiz Agostini]

may we close it now?

[Hajime Morrita]

(In reply to comment #11)
> may we close it now?
Hi Luiz, Thanks for your catch! closing now.