'Computed' style is cumbersome
Reported by
davidmax...@gmail.com,
Oct 29
|
|
Issue descriptionUserAgent: 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.
,
Oct 30
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).
,
Nov 7
> 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 |
|
Comment 1 by l...@chromium.org
, Oct 29Owner: l...@chromium.org
Status: Assigned (was: Unconfirmed)