Open
Bug 1364088
Opened 8 years ago
Updated 1 year ago
Cannot distinguish between commented-out and overridden CSS rules in Page Inspector
Categories
(DevTools :: Inspector: Rules, enhancement, P3)
Tracking
(Not tracked)
NEW
People
(Reporter: jelwray, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(4 files)
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170504105526
Steps to reproduce:
In the Page Inspector, if you inspect some html e.g.:
<p class="green" id="blue">What colour is the text?</p>
That has the following CSS rules applied:
<style>
#blue {
/*color: blue; */
}
.green {
color: green;
}
p {
color: red;
}
</style>
Actual results:
Then in the inspector, the rule for #blue is shown as overridden or commented-out in the same way as the p rule
Expected results:
The inspector should ideally show a difference between commented-out and overridden rules. Otherwise it makes it hard to debug a stylesheet that has commented-out rules because they show up the same as overridden rules in the inspector.
Firebug does it a clearer way I think.
Please see attached doc for more details.
Updated•8 years ago
|
Component: Untriaged → Developer Tools: CSS Rules Inspector
Comment 2•8 years ago
|
||
Thank you for the report.
(In reply to Jeremy from comment #0)
> Actual results:
>
> Then in the inspector, the rule for #blue is shown as overridden or
> commented-out in the same way as the p rule
There is a small difference in fact, maybe not obvious enough though:
- overridden declarations have a line through them
- commented out declarations have both a line through them *and* the checkbox to enable them is visible and unchecked.
This is an important difference because unchecking the box next to a declaration disables it (comments it out, really). So, when the rule-view sees that a declaration is already commented out in the code, it shows it as a disabled declaration: with the checkbox visible by default, unchecked, and with a line through it.
> Expected results:
>
> The inspector should ideally show a difference between commented-out and
> overridden rules. Otherwise it makes it hard to debug a stylesheet that has
> commented-out rules because they show up the same as overridden rules in the
> inspector.
>
> Firebug does it a clearer way I think.
>
> Please see attached doc for more details.
I don't have MS word unfortunately, and I tried to open that docx file with 2 different programs, but couldn't see the screenshot of Firebug's rule-view.
Could you please attach the Firebug screenshot here directly as an image rather than a doc?
Note that Chrome DevTools shows commented out declarations like Firefox DevTools. So at least we're consistent with that.
Maybe we could make it better, maybe graying out the property name and value would help. But I'd really like to see what Firebug does in this case.
Flags: needinfo?(jelwray)
Comment 3•8 years ago
|
||
DevTools bug triage (filter on CLIMBING SHOES).
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Ah yes I see what you mean I hadn't realised the checkbox enabled by default means it's a commented out declaration, that's useful to know, and that you can enable it as well - good stuff. I have attached a graphic showing how it is shown in PI vs. Firebug. As a suggestion, I wonder if commented out declarations could behave as they do now, with the addition that the declaration is shown commented out (as it is in the source), maybe in faint grey, I will try to attach a graphic to show what I mean. Cheers for your reply! EEK! Can't see how to add attachment?
Flags: needinfo?(jelwray)
Comment 7•8 years ago
|
||
(In reply to Jeremy from comment #6)
> Created attachment 8867093 [details]
> Suggestion for how PI could show a commented-out declaration
Oh this looks good to me. The addition of /* and */ before and after the disabled/commented-out property is a great idea I think.
Updated•6 years ago
|
Product: Firefox → DevTools
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•