56967 2011-03-23 15:28:34 -0700 Convert summary and details elements to use new shadow DOM 2011-05-17 21:44:33 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) PC OS X 10.5 RESOLVED FIXED P2 Normal --- 51071 58591 58914 59055 59157 48698 1 dglazkov webkit-unassigned arv cmarcelo divya dominicc kenneth lachlan.hunt luiz mathias morrita wilhelmja oldest_to_newest 372492 0 dglazkov 2011-03-23 15:28:34 -0700 Great use case for the output ports. 372512 1 luiz 2011-03-23 16:06:21 -0700 As I just have implemented the previous version I would be very interested in doing this conversion with your revision. May it be? 372513 2 kenneth 2011-03-23 16:08:00 -0700 (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. 372520 3 dglazkov 2011-03-23 16:21:10 -0700 (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. 372544 4 luiz 2011-03-23 16:57:29 -0700 (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. 381251 5 lachlan.hunt 2011-04-07 05:42:40 -0700 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. 385019 6 dglazkov 2011-04-13 11:12:11 -0700 *** Bug 58455 has been marked as a duplicate of this bug. *** 385159 7 morrita 2011-04-13 12:53:18 -0700 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. 385160 8 dglazkov 2011-04-13 12:55:15 -0700 (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. 395333 9 dglazkov 2011-04-29 10:29:15 -0700 This is fixed now, right? 395361 10 morrita 2011-04-29 10:57:28 -0700 (In reply to comment #9) > This is fixed now, right? Bug 59157 is the last bit. 405283 11 luiz 2011-05-17 14:14:56 -0700 may we close it now? 405505 12 morrita 2011-05-17 21:44:33 -0700 (In reply to comment #11) > may we close it now? Hi Luiz, Thanks for your catch! closing now.