Bug 78202 - [Shadow]: Expose one ShadowRoot in the Elements panel
Summary: [Shadow]: Expose one ShadowRoot in the Elements panel
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Pavel Feldman
URL:
Keywords:
Depends on:
Blocks: 62220
  Show dependency treegraph
 
Reported: 2012-02-08 21:49 PST by Dominic Cooney
Modified: 2012-02-27 07:22 PST (History)
7 users (show)

See Also:


Attachments
WIP patch based on attachment 120263 (18.29 KB, patch)
2012-02-08 21:52 PST, Dominic Cooney
no flags Details | Formatted Diff | Diff
Patch (30.61 KB, patch)
2012-02-27 06:35 PST, Pavel Feldman
yurys: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dominic Cooney 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.
Comment 1 Dominic Cooney 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.
Comment 2 Dominic Cooney 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?
Comment 3 Hajime Morrita 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.
Comment 4 Pavel Feldman 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.
Comment 5 Pavel Feldman 2012-02-27 06:35:39 PST
Created attachment 129028 [details]
Patch
Comment 6 Pavel Feldman 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.
Comment 7 Pavel Feldman 2012-02-27 07:22:51 PST
Committed r108993: <http://trac.webkit.org/changeset/108993>