1150496 - [meta] Better inspector box-model view

Status: NEW

(DevTools :: Inspector, defect, P3)

Description

[Patrick Brosset <:pbro>]

Meta bug to make the box-model tab in the inspector better.
Overall, I think the box-model isn't as used as it could be. For anything related to positions, sizes, layout, it's easier/quicker to read than looking for properties in the rule-view. So, with a little bit more information, it could become really useful.

Here is a list of features this next version should contain:

- Display the z-index.
This is a useful piece of information which could also serve as a way to display/highlight the parent stacking context node.

- Display the box-sizing.
This is definitely a must in the box-model tab, and in fact, the box dimensions that are shown top left in the tab should probably take this into account.

- Display the position (already there).
An idea is that for relative/absolute positions, we could have a button that toggles the Geometry highlighter (see bug 1123851).

- Display the type of box (display property).
Also a useful bit of information to have in the box-model tab.

- For inline elements, display one box-model per line box?
This may be too much, but we have scrollbars anyway! So why not provide this information.

- Display top, left, bottom, right properties.
See bug 940275, also of interest: bug 1139187.

- Allow to quickly calculate the distance between any 2 box-model regions.
Say you want to know how much the content + horizontal padding amounts to. Clicking on any region could start a sort of measuring tool, and clicking again on another region would give the distance between these 2 boxes, annotated with an arrow and label, kind of like a blueprint.

- Only highlight the relevant box-model region on hover.
See bug 938188.

- Fix the box-model legend which isn't visible today.
This is more of a regression than a new feature, but when hovering over regions on the box-model tab, a legend appears in the margin region that says the name of the hovered region. This legend is not visible anymore.

- When editing region sizes in the inplace-editors, the source css rule properties should be changed, not the element.style.

uservoice references:
http://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/5893514-positioning-information-in-box-model-view
http://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/5714404-show-total-dimensions-in-the-box-model

Comment 1

[Jeff Griffiths (:canuckistani) (:⚡︎)]

As an aside, I think we should consider whether the box model view would be more discoverable and these panels more useful if they were combined into fewer tabs. Similar to netmonitor, the inspector has grown sub-panels over time for discrete things.

Comment 2

[Patrick Brosset <:pbro>]

Another uservoice reference: https://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/5974016-inspection-debugging-of-stacking-contexts-for-elem

Comment 3

[Patrick Brosset <:pbro>]

Also: https://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/7423426-position-dependance-tree

Comment 4

[Patrick Brosset <:pbro>]

Filter on CLIMBING SHOES

Comment 5

[Helen V. Holmes (:helenvholmes) (:✨)]

Attachment: better-box-model.png

Here's a first pass at trying to capture all of Patrick's ideas. I didn't understand everything in Comment #0, thought:

(In reply to Patrick Brosset <:pbro> from comment #0)
> - Display the z-index.
> This is a useful piece of information which could also serve as a way to
> display/highlight the parent stacking context node.
Is there a definitive list of everything we'd like to display? Currently the designs have:

- box-sizing
- position
- z-index

Do we want display as well, maybe?

> - For inline elements, display one box-model per line box?
> This may be too much, but we have scrollbars anyway! So why not provide this
> information.
What's per line box? Is this an inception thing? Like, if you have something that's inline-block, you'd display a box-model of the line-block element inside the box-model of the box it was in?
 
> - Allow to quickly calculate the distance between any 2 box-model regions.
> Say you want to know how much the content + horizontal padding amounts to.
> Clicking on any region could start a sort of measuring tool, and clicking
> again on another region would give the distance between these 2 boxes,
> annotated with an arrow and label, kind of like a blueprint.
I think Bug 1263768 might capture this info than we can in the box model are itself, but I did implement

> - Display top, left, bottom, right properties.
> See bug 940275, also of interest: bug 1139187.

> - When editing region sizes in the inplace-editors, the source css rule
> properties should be changed, not the element.style.
Does this affect the UI, or is this a technical detail only? I didn't understand and wasn't sure.

Comment 6

[Helen V. Holmes (:helenvholmes) (:✨)]

Comment on attachment 8761432 [details]
better-box-model.png

I flagged you as well for review on this Tim since you're pretty good at reviewing these sorts of things, but is there someone who the two of you think would be best suited to be additional eyes on these sorts of UI mockups?

I tend to run them past a few designs on the UX team individually, so I'm mostly looking for good technical-UX-weirdness... bugs.

Comment 7

[Patrick Brosset <:pbro>]

(In reply to Helen V. Holmes (:helenvholmes) (:✨)(pls ni?) from comment #5)
> Created attachment 8761432 [details]
> better-box-model.png
This looks pretty cool! I'll take a closer look at it and provide more feedback soon. In the meantime, some comments below.

> Here's a first pass at trying to capture all of Patrick's ideas. I didn't
> understand everything in Comment #0, thought:
> 
> (In reply to Patrick Brosset <:pbro> from comment #0)
> > - Display the z-index.
> > This is a useful piece of information which could also serve as a way to
> > display/highlight the parent stacking context node.
I think it would be helpful to have a way to know which parent element is the z-index relative to. So, maybe next to z-index:0 in the mockup, there would be a link/icon to highlight or select the parent element that defines the stacking context.
In general, z-index isn't the only css property for which knowing what parent it is relative to is useful.
For instance, position:absolute elements are relative to their "positioned" parent. So if in their ancestors, there is an element with position:relative for instance, then the top/left of the absolutely positioned element will be relative to that. So it might be useful to have a similar link/icon next to the "position" in the mockup to highlight/select the positioned parent.
Also, floated elements are "contained" in block formatting contexts. It might also be useful to have a similar mechanism to highlight the context element next to "float" in the mockup.

> Is there a definitive list of everything we'd like to display? Currently the
> designs have:
> 
> - box-sizing
> - position
> - z-index
> 
> Do we want display as well, maybe?
Display would also be helpful here I think. Float as well, if defined.
Basically, anything that may explain the position of the element.
In fact, maybe we should also have something for elements that are direct children of a display:flex or display:grid elements.

> > - For inline elements, display one box-model per line box?
> > This may be too much, but we have scrollbars anyway! So why not provide this
> > information.
> What's per line box? Is this an inception thing? Like, if you have something
> that's inline-block, you'd display a box-model of the line-block element
> inside the box-model of the box it was in?
Not quite, inline elements may wrap on multiple lines in which case, multiple line boxes are created, and each of them has margin, border, padding, content, just like for the box-model of a block element.
So if we wanted to be totally correct for inline elements the tool should really display 1 diagram per line box (if the inline element wraps).
Try this:
- open this url in a tab: 
data:text/html,<div style="width:100px;line-height:3"><span style="padding:5px;border:1px solid red;margin:5px;">this is a long inline element that will wrap on multiple lines and hence will have multiple line boxes
- open the inspector
- put your mouse over the <span> element in the inspector
- you should see that the highlighter creates 8 distinct boxes to highlight each of the line boxes. Margin, border and padding have special rules on line boxes, but they still apply.

> > - Allow to quickly calculate the distance between any 2 box-model regions.
> > Say you want to know how much the content + horizontal padding amounts to.
> > Clicking on any region could start a sort of measuring tool, and clicking
> > again on another region would give the distance between these 2 boxes,
> > annotated with an arrow and label, kind of like a blueprint.
> I think Bug 1263768 might capture this info than we can in the box model are
> itself, but I did implement
> 
> > - Display top, left, bottom, right properties.
> > See bug 940275, also of interest: bug 1139187.
I think we have to be careful about naming here. If I understand correctly, top/right/bottom/left in your mockup highlight distances to other elements close-by. Whereas in CSS, the corresponding properties define an offset for positioned elements with respect to their offset parent only.
Bug 1263768 sounds very useful for something like the measurement tool we already have, but might be misleading for the box-model tool. Users may be confused if "top" is the actual top css property value, or if it's the distance to the next visible neighbor toward the top of the page.

> > - When editing region sizes in the inplace-editors, the source css rule
> > properties should be changed, not the element.style.
> Does this affect the UI, or is this a technical detail only? I didn't
> understand and wasn't sure.
This is only a technical change. Right now when you change a margin in the box-model tab, then the current element's inline style is changed. There are cases when you want this to happen (if you want only this element to change), but there are other cases when you want all elements that match a given selector to be updated.
So this doesn't impact the mockup of the box-model tool, but I'm thinking we might want to have that tool available as an editor for any rule in the css rule-view.

Comment 8

[Tim Nguyen :ntim]

Comment on attachment 8761432 [details]
better-box-model.png

Looks really nice! I really like the fact we're displaying layout related properties, as Patrick says, maybe we should go further with more props (float, display)? And possibly have extra properties for grid/flex layouts, eg. flex-grow,...

About showing the relationship with other elements, that is a good idea, but in the mockup, it seems misleading. The top property calculates the offset relative to the positioned parent element, not the neighbour. Additionally, the offset to sibling elements would usually correspond to the margin, so we would be displaying this info twice. Perhaps it would be more interesting to visualise how the current element interacts with the siblings in case of a float layout, a flex layout or a grid layout.

Finally, I'm not a big fan of using the hand icon for the geometry tool, the current icon is a direct visual representation of what the tool looks like.

Comment 9

[Helen V. Holmes (:helenvholmes) (:✨)]

Attachment: better-box-model.png

(In reply to Patrick Brosset <:pbro> from comment #7)
> For instance, position:absolute elements are relative to their "positioned"
> parent. So if in their ancestors, there is an element with position:relative
> for instance, then the top/left of the absolutely positioned element will be
> relative to that. So it might be useful to have a similar link/icon next to
> the "position" in the mockup to highlight/select the positioned parent.
> Also, floated elements are "contained" in block formatting contexts. It
> might also be useful to have a similar mechanism to highlight the context
> element next to "float" in the mockup.
I've added what this could look like, although I didn't add it everywhere in my mockup where it would make sense because I got lazy.

> Display would also be helpful here I think. Float as well, if defined.
> Basically, anything that may explain the position of the element.
> In fact, maybe we should also have something for elements that are direct
> children of a display:flex or display:grid elements.
What does the box model do when it's an element that's both display:flex and has a flex property? Less of a question for you Patrick, more of a note-to-self of other scenarios this mockup should probably explore...

> Try this:
> - open this url in a tab: 
> data:text/html,<div style="width:100px;line-height:3"><span
> style="padding:5px;border:1px solid red;margin:5px;">this is a long inline
> element that will wrap on multiple lines and hence will have multiple line
> boxes
> - open the inspector
> - put your mouse over the <span> element in the inspector
> - you should see that the highlighter creates 8 distinct boxes to highlight
> each of the line boxes. Margin, border and padding have special rules on
> line boxes, but they still apply.
I'm still not sure I understand everything here—if it's all right, I'm going to ask you to explain it to me on Tuesday?

> > I think Bug 1263768 might capture this info than we can in the box model are
> > itself, but I did implement
> I think we have to be careful about naming here. If I understand correctly,
> top/right/bottom/left in your mockup highlight distances to other elements
> close-by. Whereas in CSS, the corresponding properties define an offset for
> positioned elements with respect to their offset parent only.
Ah, you're right. I tried doing a better job of illustrating this with this mockup now that I believe I understand better.

Comment 10

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to Tim Nguyen :ntim from comment #8)
> About showing the relationship with other elements, that is a good idea, but
> in the mockup, it seems misleading. The top property calculates the offset
> relative to the positioned parent element, not the neighbour. Additionally,
> the offset to sibling elements would usually correspond to the margin, so we
> would be displaying this info twice. Perhaps it would be more interesting to
> visualise how the current element interacts with the siblings in case of a
> float layout, a flex layout or a grid layout.
I tried fixing this if you want to take another look—I definitely was thinking we were trying to show sibling relationships with the box model, not parent/child ones. (Although we might still occasionally wish to show sibling relationships when it comes to floats?)

> Finally, I'm not a big fan of using the hand icon for the geometry tool, the
> current icon is a direct visual representation of what the tool looks like.
Changed this, had forgotten we already had an icon.

Comment 11

[Yura Zenevich [:yzen] (please use "needinfo")]

Hi Helen, sorry if this is the wrong bug, here are some colorblindness validation tools, either native or web, that you might find helpful: 
http://colorfilter.wickline.org/
https://michelf.ca/projects/sim-daltonism/
https://chrome.google.com/webstore/detail/nocoffee/jjeeggmbnhckmgdhmgdckeigabjfbddl

Comment 12

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to yura.zenevich from comment #11)
> Hi Helen, sorry if this is the wrong bug, here are some colorblindness
> validation tools, either native or web, that you might find helpful: 
> http://colorfilter.wickline.org/
> https://michelf.ca/projects/sim-daltonism/
> https://chrome.google.com/webstore/detail/nocoffee/
> jjeeggmbnhckmgdhmgdckeigabjfbddl

Thanks!

Also to keep track of your comments on the designs from last week, suggestions included changing that outer blue color and bumping up the type size to make that last margin area have better contrast.

Comment 13

[Helen V. Holmes (:helenvholmes) (:✨)]

Attachment: better-box-model.png

Clearing Patrick's review while I sort out what this looks like flexbox and grid, but here are some a11y updates and an attempt to sort out how to handle inline-block elements.

Comment 14

[Yura Zenevich [:yzen] (please use "needinfo")]

Comment on attachment 8764240 [details]
better-box-model.png

Big fan! Thanks for including variations of contrast checks! Bigger font is helpful as well with the hover tooltip.