Bug 56967 - Convert summary and details elements to use new shadow DOM
Summary: Convert summary and details elements to use new shadow DOM
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 58455 (view as bug list)
Depends on: 51071 58591 58914 59055 59157
Blocks: 48698
  Show dependency treegraph
 
Reported: 2011-03-23 15:28 PDT by Dimitri Glazkov (Google)
Modified: 2011-05-17 21:44 PDT (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitri Glazkov (Google) 2011-03-23 15:28:34 PDT
Great use case for the output ports.
Comment 1 Luiz Agostini 2011-03-23 16:06:21 PDT
As I just have implemented the previous version I would be very interested in doing this conversion with your revision. May it be?
Comment 2 Kenneth Rohde Christiansen 2011-03-23 16:08:00 PDT
(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.
Comment 3 Dimitri Glazkov (Google) 2011-03-23 16:21:10 PDT
(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.
Comment 4 Luiz Agostini 2011-03-23 16:57:29 PDT
(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.
Comment 5 Lachlan Hunt 2011-04-07 05:42:40 PDT
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.
Comment 6 Dimitri Glazkov (Google) 2011-04-13 11:12:11 PDT
*** Bug 58455 has been marked as a duplicate of this bug. ***
Comment 7 Hajime Morrita 2011-04-13 12:53:18 PDT
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.
Comment 8 Dimitri Glazkov (Google) 2011-04-13 12:55:15 PDT
(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.
Comment 9 Dimitri Glazkov (Google) 2011-04-29 10:29:15 PDT
This is fixed now, right?
Comment 10 Hajime Morrita 2011-04-29 10:57:28 PDT
(In reply to comment #9)
> This is fixed now, right?
Bug 59157 is the last bit.
Comment 11 Luiz Agostini 2011-05-17 14:14:56 PDT
may we close it now?
Comment 12 Hajime Morrita 2011-05-17 21:44:33 PDT
(In reply to comment #11)
> may we close it now?
Hi Luiz, Thanks for your catch! closing now.