[css-nesting] Suggest a way to inspect CSS nesting in browser DevTools

[captainbrosset]

CSS nesting is going to be such a major change to the way we write CSS. In fact, so much that the way we display it in our browser DevTools might need to change too!

The adoption of the feature will not only be driven by its implementation in browser, but also by tooling support to some extent. Code editors, obviously, will need to understand nesting, and help find errors and offer syntax highlighting and code completion. But browser developer tools will also need to display the new syntax to let users inspect their webpages and debug potential problems.

Of course, this isn't something that the CSS WG needs to specify, but I do believe that on top of designing this feature for the best authoring experience, some thoughts should be given to the debugging experience too.

Relatedly, I posted last year about how specs could suggest ways in which UAs could expose more debugging information to end users. This isn't exactly the same here. But the idea comes from the same need of thinking about how end users will inspect and debug web pages written with CSS nesting.

I would love it if various DevTools teams and CSSWG people could discuss and agree on the best way to represent nested rules in DevTools, in a way to makes it easy for people to learn how nesting even works, and reports errors (such as missing & signs).

Pinging a few DevTools peeps here: @janodvarko @nchevobbe @kilian @hashseed @codepo8.

[Kilian]

I would be fantastic if for CSS Nesting, the CSSOM is also updated with awareness of nesting. This hasn't happened with layers and it makes creating devtools/introspection tooling outside of a browsers internals significantly more complex.

In terms of display, deciding which part of the nesting context (e.g. sibling nested selectors) to show and when is going to be the biggest puzzle, though I'm not convinced that there's going to be one ideal way that all devtools teams agree on (and having a few different representations that can converge over time is probably a good thing).

[hashseed]

@hanselfmu @bmeurer

I agree that tooling support is important. Chrome DevTools team is planning to work on tooling support for CSS nesting in 2023. I don't think there is a need for all DevTools teams to agree on the same UX pattern. Competition breeds innovation :)

However, I think interoperability with CSSOM is a completely different issue.

[captainbrosset]

Sure, competition helps move forward, and I don't think we need to agree on what to do. But I wanted to create some space for devtools and csswg folks to talk. There may be opinions on this that need to be heard early.

[hashseed]

Yes, of course. I just wanted to avoid design-by-committee for something somewhat subjective and user-facing as developer tooling UX. Collecting requirements together makes a lot of sense.

[nt1m]

cc @patrickangle @mdubet

[denk0403]

Perhaps I'm lacking creativity here, but assuming the nesting proposal is going with Option 3, I expect the styles pane to behave pretty much identically to what's generated by SCSS, maybe with some added icon to indicate the presence of nesting. This is because the first thing I check for when debugging nested CSS is what my nested selectors were "desugared" into.

So for nested CSS such as the following:

The styles pane should appear as:

In order to assist developers in inspecting how their selectors were desugared, I think it would be best to add context to the Sources panel. Specifically, it would be helpful to see what "&" is equal to at every level of nesting.

I imagine this can either be viewable via a tooltip when hovering over a "&":

Or it can be displayed inline when the line is selected:

[SebastianZ]

I like @denk0403's suggestions but regarding the Styles/Rules panel, I wonder whether completely desugaring actually helps debugging the selectors.

To avoid indentation hell within the panel, this might be ok, though there should at least be a popup showing the original selector structure on hover.

On the other hand, the Sources/Style Editor panel (and also IDEs) should provide a way to display the desugared selectors. This could also be a popup on hovering the inner selectors. Hovering the nesting selector could still only show the parent selector(s) like in @denk0403's mockup. With that, authors would be able to see what's behind the & and also have a way to see the result of their nested rules.

In addition to displaying the parent selectors for the &, I think it would make sense to link to them. So it's easier to debug them, especially in case the related rules are long and/or the nesting is deep.

Sebastian

[tabatkins]

I don't mind the discussion going on here, but this is definitely out of scope for the spec itself, so I'm going to tag it as such and close it. Feel free to continue using this to discuss the tooling issue, if it's useful.