Closed Bug 1786830 Opened 1 month ago Closed 1 month ago

Display container queries on top of rule

Categories

(DevTools :: Inspector: Rules, task)

task

Tracking

(firefox106 fixed)

RESOLVED FIXED
106 Branch
Tracking Status
firefox106 --- fixed

People

(Reporter: nchevobbe, Assigned: nchevobbe)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

We should make sure to handle nested container queries (potentially with media queries)

We already have a mechanism in place to traverse-up the ancestor rules, and detecting that there are container queries is not too hard (see D155469)

The thing that we're missing is a way of getting the container name for the rule.
The spec seems still incomplete on what should be on CSSContainerRule (see https://drafts.csswg.org/css-contain-3/#the-csscontainerrule-interface)
It looks like there's discussion about exposing a containerName property (https://github.com/w3c/csswg-drafts/issues/7190), but it might not be enough for us: it would be nice for the user if there was a quick way of seeing which element is actually represented by the container name.

Emilio, do we have a function today who can give us the container element given a CSSContainerRule ? If there isn't something like that already, would it be possible to add something on InspectorUtils (e.g. getContainerForRule ) ?

Then we could then extract the container name from the container-name property, but again, this is not ideal as container-name can hold multiple name, and we wouldn't know which one was used in the container query. So it looks like we would need both CSSContainerRule.containerName and something like InspectorUtils.getContainerForRule

Flags: needinfo?(emilio)

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #2)

It looks like there's discussion about exposing a containerName property (https://github.com/w3c/csswg-drafts/issues/7190), but it might not be enough for us: it would be nice for the user if there was a quick way of seeing which element is actually represented by the container name.

This is what I suggested in https://github.com/w3c/csswg-drafts/issues/7033#issuecomment-1199808111.

Sebastian

The container element can't be a method that takes only a rule, you also need an element to be contained... We could add such a function, do you have the relevant element on the caller? Also, the container rules fall back to viewport-size when there's no container IIRC, I guess you'd need a way to represent that.

Flags: needinfo?(emilio)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

The container element can't be a method that takes only a rule, you also need an element to be contained... We could add such a function, do you have the relevant element on the caller?

Not at the moment, but I can probably do something to get it, I'll look

Also, the container rules fall back to viewport-size when there's no container IIRC, I guess you'd need a way to represent that.

Oh, so you mean if we have something like:

@container unknowncontainer (max-width: 460px){
  h1 {
    color: cyan;
  }
}

where unknowncontainer isn't defined in any container-name property.
That's good to know, we can probably surface that in the UI, maybe a title saying that there are no container with this name, and that we falled-back to viewport size (the "regular" container will probably be styled differently so we can quickly select the corresponding node in the markup view).

Filed Bug 1787173 to have a simple way to get the container name as a string, so we can use it on a first implementation in the rule view (it also could be useful in the StyleEditor where we want to display container queries in the sidebar )

Depends on: 1787173
Attachment #9291345 - Attachment description: WIP: Bug 1786830 - [devtools] Display container queries on top of rules. → Bug 1786830 - [devtools] Display container queries on top of rules. r=jdescottes.
Pushed by nchevobbe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4c76664026b5
[devtools] Display container queries on top of rules. r=jdescottes.
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 106 Branch
You need to log in before you can comment on or make changes to this bug.