Open Bug 2051249 Opened 2 months ago Updated 5 days ago

Add devtools support for margin-trim

Categories

(DevTools :: Inspector, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: tlouw, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: margin-trim-m1)

Attachments

(1 file)

No description provided.

Tiaan, is the margin computed value of the children element is impacted by margin-trim, or is it just something that is handled on the element where margin-trim is set?

If the margin computed value of the children is impacted, then when a margin is trimmed, we need to check what is displayed in:

  • the layout panel box model
  • the element highlighter

In the box model UI, if you shift + hover a margin, it should jump to the declaration that sets the margin in the rules view. With trimmed margin, we should make sure this doesn't cause any issues

More broadly, it would be nice to indicate when margin are getting trimmed so users can quickly understand what's happening

Component: Layout → Inspector
Product: Core → DevTools

Setting margin-trim on a container affects the margin of its child. The computed value of margin-top for instance is 0 if they are affected, but still shows 10px if that was set. Shift+hover also highlights margin-top in this case on the child, with no indication that it was trimmed from its parent.

Any ideas how we can show indicate the affected trimming to the user?

Whiteboard: margin-trim-m1

(In reply to Tiaan Louw [:tlouw] from comment #2)

Setting margin-trim on a container affects the margin of its child. The computed value of margin-top for instance is 0 if they are affected, but still shows 10px if that was set. Shift+hover also highlights margin-top in this case on the child, with no indication that it was trimmed from its parent.
Any ideas how we can show indicate the affected trimming to the user?

Not sure yet, we'll discuss it with the team during our next triage meeting

Whiteboard: margin-trim-m1 → margin-trim-m1 [devtools-triage]

Leo has a work in progress overhaul of the box model. If we want to go for a detailed description and not just a simple title / icon, it would be good to wait for the other bug to be resolved.

Flags: needinfo?(lmcardle)

Yes, currently the box model view uses absolute positioning: if we want to move things around, we should probably wait for the conversion to grid. If we just want to add an icon or something simple within the existing layout, it can probably move ahead without.

Flags: needinfo?(lmcardle)
See Also: → 1348335
Whiteboard: margin-trim-m1 [devtools-triage] → margin-trim-m1

(In reply to Tiaan Louw [:tlouw] from comment #2)

The computed value of margin-top for instance is 0 if they are affected, ...

That actually isn't true anymore. Given the CSSWG resolution in https://github.com/w3c/csswg-drafts/issues/11506#issuecomment-5190507939, the computed (and resolved) value is unaffected by margin-trim. This means, the value in the example should still be 10px.

Any ideas how we can show indicate the affected trimming to the user?

(In reply to Nicolas Chevobbe [:nchevobbe][PTO back September 7] from comment #1)

If the margin computed value of the children is impacted, then when a margin is trimmed, we need to check what is displayed in:

  • the layout panel box model
  • the element highlighter

I'd say the Layout panel box model should should be striped when the margin is trimmed, as visual indication, plus there should be a textual note about this as well.

The element highlighter should probably just trim the margin, as that's what authors see on the page, even when the computed value of the margin isn't actually affected. Alternatively, the affected margin could also be striped, making it consistent with the display in the Layout panel. Though that might also confuse people.

In the box model UI, if you shift + hover a margin, it should jump to the declaration that sets the margin in the rules view. With trimmed margin, we should make sure this doesn't cause any issues

I totally forgot about that. Sounds like bug 1536164 and bug 1528288 would improve the UX for this feature. Given margin-trim doesn't affect the value of the set margin, there shouldn't be an issue with that.
But if the info about margin-trim affecting the end result of the margin is exposed in the box model, it should link to the definition of margin-trim.

More broadly, it would be nice to indicate when margin are getting trimmed so users can quickly understand what's happening

I am wondering whether we could use the inactive CSS logic to indicate that the margin-* value set on an element is be affected by a margin-trim. Though that would be something new, as only specific elements in a group of siblings are affected by it.
Optimally, the inactive CSS popup would then link to the related margin-trim property, meaning the container element would have to be selected and then the margin-trim property be highlighted in the Rules view.

Sebastian

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: