New issue
Advanced search Search tips

Issue 899807 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

'Computed' style is cumbersome

Reported by davidmax...@gmail.com, Oct 29

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.20 Safari/537.36

Steps to reproduce the problem:
1. open https://output.jsbin.com/sinuxuh
2. open dev tools
3. select <body>
4. tell me what value is computed for margin-top

What is the expected behavior?
I expect to be able to see the computed values easily

What went wrong?
To be able to see the actual value, I need to switch to the computed tab and filter/look for it in that list.

Did this work before? N/A 

Chrome version: 71.0.3578.20  Channel: beta
OS Version: 
Flash Version: 

It'd be much better to have a column on the right of the 'styles' tab that shows the values for that property from the 'computed' tab.
 
Labels: Needs-Feedback
Owner: l...@chromium.org
Status: Assigned (was: Unconfirmed)
Thank you for the report.  In the case of 'margin-top', the computed value is also shown in the Box Model representation (the orange-yellow-green-blue boxes) shown at the bottom of 'Styles' and the top of 'Computed'.

We can definitely explore better ways to expose this information.

To better help us investigate,
- Could you please elaborate your use case?
- Is this only needed when using complex CSS variables?
- Would you benefit from a more visible/accessible Box Model?
Hrm. Those are good points and questions.

I think it's true that my frustration does indeed come when using CSS variables, as well as env() and calc(). I see your point that the computed values are shown in the 'box model' representation, and that is sure to help. I wonder if my real use-case had many more style rules which pushes the 'box model' below the fold so I can't see it (I forget) - certainly that's not true with the jsbin.

I wonder if I am more used to being able to find these values from hovering over them (as I can in JS code), and I noticed that does work for parts of the expression that are either var(), but it doesn't work for 'env()' or 'calc()'.

So, I guess things could be improved, and perhaps my suggestion of (essentially) combining 'computed' and 'styles' is 'over the top' - it just struck me that the values were actually there on the next tab, when they could be on the same tab...it was almost like I wanted the 'styles' tab to be translucent :) It seemed obvious to just put the computed values on the right of the 'styles' tab....but then they would be in 4 (?) places and perhaps that is too much duplication. Perhaps the 'computed' should be made into 'all computed', and the abbreviated overlaid on the 'styles'?

My 'use case' is developing a PWA to work on notched phones, like iPhone X and Pixel 3 - in my case, I use the developer options to emulate them on a Pixel 2. Getting the padding/etc to work properly on both platforms is very tricky, and there seem to be some bugs when the safe-area values aren't applied when they should be. Of course, this report only applies to Pixel (which is where the bug I'm currently investigating is). Getting chrome dev tools to work with mobile safari would be the biggest help, but that's another story.

In summary...I'm not sure, and am happy for you to consider my feedback and take whatever action you think is best (including none).
> I wonder if my real use-case had many more style rules which pushes the 'box model' below the fold so I can't see it (I forget)

I've experienced this frustration again and indeed it isn't great that I have to scroll down so far to see the box model, or switch to the 'computed' tab. I still think it would be best to see the values on the right side of the rule, but perhaps also the box model is something that could be always shown (I think one view is arranged so that it is always shown?)?

Sign in to add a comment