Open Bug 1014279 Opened 10 years ago Updated 2 years ago

Help developers with margin collapsing

Categories

(DevTools :: Inspector, enhancement, P2)

enhancement

Tracking

(Not tracked)

People

(Reporter: canuckistani, Unassigned)

References

Details

(Whiteboard: [polish-backlog][difficulty=medium])

Attachments

(2 files)

From feedback: http://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/5894749-make-collapsing-margins-visible-and-show-from-whic "When inspecting HTML elements, CSS margins which collapsed should be highlighted with a new color. It also would be nice if it was possible to show some information about the elements involved and which the margin of which element is visible." ( 37 votes currently ) Related MDN article: https://developer.mozilla.org/en-US/docs/Web/CSS/margin_collapsing
What do you think would help with this? I'm assuming the suggestion is to change the color of the region of the box model highlighter overlaid on the element. Should this also happen in the layout view of the inspector? I wonder if we could add some sort of patterned overlay or vertical arrows on top of the current color for the collapsed margin(s). > When negative margins are involved, the size of the collapsed margin is the sum of the largest positive margin and the smallest (most negative) negative margin. I'm not sure how to best display negative margins anyway, but when looking into this I think I found a bug with the box model highlighter. Jeff, can you see if you are able to see the box model highlighter on the first <p> tag in the result here: http://jsfiddle.net/bgrins/SD7Vh/
Flags: needinfo?(jgriffiths)
OS: Mac OS X → All
Hardware: x86 → All
Version: 30 Branch → Trunk
I can't see the highlighter at all for the first p tag: http://note.io/RXi2mw Interesting! Chrome does work here: http://note.io/1qY2oaB If I were to suggest an aproach to solving this, it would be to at least do what chrome does, it's not surprising.
Flags: needinfo?(jgriffiths)
Depends on: 1014619
Whiteboard: [devedition-40]
Setting devedition-40 bugs to P2, filter on C17C996C-A0BE-4153-8057-FAB642D0746D
Priority: -- → P2
(In reply to Jeff Griffiths (:canuckistani) from comment #2) > I can't see the highlighter at all for the first p tag: > http://note.io/RXi2mw > > Interesting! > > Chrome does work here: http://note.io/1qY2oaB If I were to suggest an > aproach to solving this, it would be to at least do what chrome does, it's > not surprising. This might have changed recently, because I can see the highlighter. The negative margin on the fist p tag isn't being highlighted (or it is, but it's not visible because in content), but chrome does the same, and I have no idea how we could display the negative margin here.
Whiteboard: [devedition-40] → [devedition-40][difficulty=medium]
(In reply to Patrick Brosset [:pbrosset] [:patrick] from comment #4) > (In reply to Jeff Griffiths (:canuckistani) from comment #2) > > I can't see the highlighter at all for the first p tag: > > http://note.io/RXi2mw > > > > Interesting! > > > > Chrome does work here: http://note.io/1qY2oaB If I were to suggest an > > aproach to solving this, it would be to at least do what chrome does, it's > > not surprising. > This might have changed recently, because I can see the highlighter. The > negative margin on the fist p tag isn't being highlighted (or it is, but > it's not visible because in content), but chrome does the same, and I have > no idea how we could display the negative margin here. It looks to me now like we're at least at parity, so I'd be fine with dropping this from devedition-40 - it feels like a more complete solution requires some UX input. Opinions?
Flags: needinfo?(pbrosset)
Flags: needinfo?(bgrinstead)
I agree that we are at parity. I still think we should improve how we display this, and the highlighter-specific bits will probably be generally easy given all the work that's been done on the highlighter APIs. But, unless if Patrick already has an idea how to visualize this, we will need UX help for how to show this (which going to be part design and part understanding the intricacies of the spec).
Flags: needinfo?(bgrinstead)
The thing with showing the negative margin by using the same strategy we have today to show regular margin, is that it's bound to hide some of the other box-model regions, and that's a problem. So we'd have to find a very subtle way to display the negative margin region by, maybe, just using an arrow or something. And for this, I agree we need to think some more and probably involve UX too. Collapsing margin is yet another non-trivial thing to highlight. It would require checking the margin of the next and previous siblings, and checking the distance that separate them from the highlighted element (unless we had a new magical platform API that told us whether a margin would collapse), and somehow also highlighting the margin of those sibling elements, maybe also with an arrow that says "collapsing" or something.
Flags: needinfo?(pbrosset)
Whiteboard: [devedition-40][difficulty=medium] → [polish-backlog][difficulty=medium]
Inspector bug triage (filter on CLIMBING SHOES).
Severity: normal → enhancement
Product: Firefox → DevTools
Attached image collapsed margin highlight (deleted) —

I was thinking of this recently and just wanted to add some relevant work that we started on (but had to shelve away for now).

It seems we should allow hovering over and selecting a space that is the margin of an element.

The collapsed margin could be emphasized like in this mockup.

Making it possible to select elements when hovering over their margin area would be great.
I'm wondering what would happen when clicking right where 2 (or more) margins do collapse. Which element would you select then?
I don't think there's a way DevTools can decide for the user. So perhaps presenting the user with a list of collapsing elements is the way to go.

Depends on: 1668265
No longer depends on: 1668265
Attached image image.png (deleted) —

I'm wondering what would happen when clicking right where 2 (or more) margins do collapse. Which element would you select then?
I don't think there's a way DevTools can decide for the user. So perhaps presenting the user with a list of collapsing elements is the way to go.

One solution: pick the 'prevailing ' element on regular click, and right-click for the list. Attached is my old mockup for this :)

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: