Bug 78202

Summary: [Shadow]: Expose one ShadowRoot in the Elements panel
Product: WebKit Reporter: Dominic Cooney <dominicc>
Component: Web Inspector (Deprecated)Assignee: Pavel Feldman <pfeldman>
Status: RESOLVED FIXED    
Severity: Normal CC: apavlov, caseq, dglazkov, morrita, paulirish, pfeldman, silviapf
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 62220    
Attachments:
Description Flags
WIP patch based on attachment 120263
none
Patch yurys: review+

Dominic Cooney
Reported 2012-02-08 21:49:02 PST
Despite r85751 being rolled out (see bug 60160 and bug 62188) a few people are using ad-hoc variants of that patch for development, eg of video text tracks in the video element. I’m filing this bug to move discussion about the evolution of that patch from bug 60160 to here, firstly because bug 60160 is closed, and secondly because ShadowRoot is now available from JavaScript (if the SHADOW_DOM feature is enabled) so we might want to revisit this patch as the basis of accessing author shadows in the Inspector. Note that the Shadow DOM spec has changed since the bug 60160-era and soon elements will be able to have multiple shadow roots attached in a stack.
Attachments
WIP patch based on attachment 120263 (18.29 KB, patch)
2012-02-08 21:52 PST, Dominic Cooney
no flags
Patch (30.61 KB, patch)
2012-02-27 06:35 PST, Pavel Feldman
yurys: review+
Dominic Cooney
Comment 1 2012-02-08 21:52:57 PST
Created attachment 126236 [details] WIP patch based on attachment 120263 [details] This works for inspecting the UA shadows of <video>, etc. in Chromium r120954/WebKit r106990 but the flakiness is considerable. No tests, no ChangeLog, harmful to puppies and children.
Dominic Cooney
Comment 2 2012-02-19 20:34:25 PST
Does anybody have an opinion on these questions regarding multiple shadow roots? Given var b = document.querySelector('body') var s = new ShadowRoot(b); var t = new ShadowRoot(b); var u = new ShadowRoot(b); There are three questions I am wondering about: • When multiple shadow roots are present, should they be presented at the top-level or underneath a "shadows" node, eg. this: V <html> … V <body> V (shadows) > (shadow) > (shadow) > (shadow) > <p>"Lorem ipsum …"</p> Or this? V <html> … V <body> > (shadow) > (shadow) > (shadow) > <p>"Lorem ipsum …"</p> • Should they be presented before the child content, or after it? eg. this: V <html> … V <body> * shadows appear here * > <p>"Lorem ipsum …"</p> Or this? V <html> … V <body> > <p>"Lorem ipsum …"</p> * shadows appear here * • Lastly, should the "youngest" shadow be displayed closest to the child content, or furthest away from it? You could ask this third question as: should the "youngest" shadow be displayed at the top or at the bottom? However I’m going to argue that the question should be one of closer or farther from child content, which means displaying shadow roots oldest-to-youngest if you display them above the light children, or youngest-to-oldest if you display them below the light children. The reason is I think you want to display the youngest shadow closest to the light children. When you are debugging shadow DOM, you will probably want to experiment with how <content> distribution happens. Since younger shadow roots get "first dibs" on light children, I think shadow DOM in the inspector will be easier to use/understand if you put the younger shadow roots in closer proximity to the light children. Unrelated to the question of multiple shadows: • Should "user-agent shadows" (aka built-in shadows) be displayed in the inspector? If so, should they be presented differently somehow? Should they be displayed by default? Should there be an option not to display them? If so, where should it go?
Hajime Morrita
Comment 3 2012-02-19 23:55:25 PST
Interesting point. We should definitely discuss this. > • When multiple shadow roots are present, should they be presented at the top-level or underneath a "shadows" node, eg. this: > > V <html> > … > V <body> > V (shadows) > > (shadow) > > (shadow) > > (shadow) > > <p>"Lorem ipsum …"</p> "shadows" sounds cool. We should have a way to hide them at once. And "shadows" would be one os them. > • Lastly, should the "youngest" shadow be displayed closest to the child content, or furthest away from it? Considering people may want to see what they see visually, yougest-first sounds viable for me. Also, it would be great if we have some visual cue to represent which node is "distributed", that means, a part of final composed tree. Ideally we should have a view for final composed tree. But it would need further investigation. > • Should "user-agent shadows" (aka built-in shadows) be displayed in the inspector? If so, should they be presented differently somehow? Should they be displayed by default? Should there be an option not to display them? If so, where should it go? This is a tricky bit. When people start decorating existing form controls, they would be frustrated if we don't provide this. On the other hand, we should never allow to modify these user-agent trees. If we can make them read-only. it looks ideal for me.
Pavel Feldman
Comment 4 2012-02-25 02:19:40 PST
(In reply to comment #2) > Does anybody have an opinion on these questions regarding multiple shadow roots? Given How often does this happen / you expect this to happen? > > • Should they be presented before the child content, or after it? eg. this: > Given that shadow roots do not happen often, I would put them in front > > • Lastly, should the "youngest" shadow be displayed closest to the child content, or furthest away from it? > This one is hard for me to understand. When you have a list of child nodes (say absolutely positioned), they are painted in the order of appearance in the list. So the order matters for regular DOM nodes, and you expect the last item to be on top of the others. Are you suggesting the opposite for shadow roots? > • Should "user-agent shadows" (aka built-in shadows) be displayed in the inspector? If so, should they be presented differently somehow? Should they be displayed by default? Should there be an option not to display them? If so, where should it go? Definitely OFF by default, probably behind the inspector setting. We use gray background for UA stylesheets to distinguish them and point out that they are read-only. I guess same applies to the user-agent shadows. We will need to introduce a concept of a read-only node in the inspector + make sure $0 does not work for the UA shadows.
Pavel Feldman
Comment 5 2012-02-27 06:35:39 PST
Pavel Feldman
Comment 6 2012-02-27 06:38:53 PST
I uploaded a straw man implementation for shadow roots in the inspector. I'd like to test is using web facing API, but I can't find tutorials on the feature that would work. This makes me think that it is still too early to add support for it in the inspector by default. Anyways, I am all for landing this patch so that the WebKit team could use this experiment. As a follow up, one might want to make nodes under user roots editable.
Pavel Feldman
Comment 7 2012-02-27 07:22:51 PST
Note You need to log in before you can comment on or make changes to this bug.