I don't understand why the "computed" tab has a "Browser styles" checkbox, while for the "Rules" tab we need to go to the options. This looks inconsistent at best. It would be nice to have a generic way to enable options per tab. My own main requirement is to be able to quickly enable/disable Browser CSS rules from either the Rules or Computed tabs.

This would have the advantage of making some options far more discoverable.

I agree with the proposal. It also would make it more consistent with the debugger and style-editor that both have (or will have) options directly inside the panel.

I agree too. CC Darrin in case he has opinions. iOS style is to move all options to the same place (sort of how we used to do it). Android style is to let each application have it's own options (the direction we're going in). iOS style looks at options as things you rarely ever need to change and reduces clutter in a normal app. Android style admits options as a fact of life. Maybe they're both right given differences in demographic, but it seems to me that we're far more to the 'options are a fact of life' end of the spectrum. While we're at it, is "Default color unit [Hex|HSL|RGB|Names]" something that we should move at the same time? It's only used in the inspector AFAIK. I guess we could make use of the same choice in the style editor at the same time, but I'm leaning towards moving this at the same time.

Potential issues with moving options into each tool individually: 1) Some of the options (like default color unit) are not a simple checkbox. This cog + popup is how we are currently doing in-tool options with debugger/style editor and something like this doesn't fit into that UI. 2) It could make it harder to explain to people where a particular option is since they could be in either the tool itself or the options panel. And the thing is that if we can't handle 1 then it exasperates 2, since options per tool are spread into two places. So it would be good to have a way to handle options-per-tab for these more complex values. Maybe there could be a more persistent popup (like is used for the colorpicker) that shows up when clicking one of the cogs to allow more rich contextual controls. And that could load a partial view of the existing options panel page in an iframe so we don't have to wire up the pref changes manually across each tool (some discussion about using options outside of the toolbox with a similar technique was in Bug 964356). I'm also interested in Darrin's thoughts on our options.

How about having some options in both places? The ones the user is the most likely to use (Browser Styles is one of them, there may be others) ?

(In reply to Julien Wajsberg [:julienw] from comment #5) > How about having some options in both places? The ones the user is the most > likely to use (Browser Styles is one of them, there may be others) ? It would be a bad thing if people needed to ask themselves if the 2 checkboxes represented the same thing. I think I'm going to escalate this to a needinfo because I think it's likely that Darrin knows lots about this.

(In reply to Joe Walker [:jwalker] from comment #6) > (In reply to Julien Wajsberg [:julienw] from comment #5) > > How about having some options in both places? The ones the user is the most > > likely to use (Browser Styles is one of them, there may be others) ? > > It would be a bad thing if people needed to ask themselves if the 2 > checkboxes represented the same thing. If they have the same name, and their states is sync-ed, I don't think it's disturbing. But, ok, that's only one advice :)

It's been 1 year, it's still bugging me. Can't we have the same "Browser Styles" checkbox in the "Rules" tab just like we have it in the "Computed" tab, and remove it from the undiscoverable options panel? More discoverable, more consistent, more useful. Should I file a separate bug for this specific issue (and keeping this one for the general issue of having per-panel options) ?

I think this is Patrick's call.

So, I'm uncertain about this one, for several reasons: - I'd rather we work on making the overall toolbox more consistent with regards to how we deal with settings. Right now all panels do things differently, some have in-panel options, none of them have it at the same place, some have options only in the settings panel. So, it'd be good to clean this mess up. But that takes UX discussions and time, and I understand Julien's frustration about this particular option. - If we wanted to make the rule-view and computed-view consistent, we'd need to add the "browser styles" checkbox up there next to the rules filter, but that's somewhat incompatible with the work being done in bug 987365 (see this screenshot: https://bug987365.bugzilla.mozilla.org/attachment.cgi?id=8562599), ccing Gabriel. Maybe we can put them both at the bottom. - Last, my gut feeling (confirmed after discussing with a couple of web devs) is that this option isn't useful to the majority of people using our tools. A lot web developers don't really care that the user-agent style on a table is to have a 2px border and what color it is. A lot of people even use reset CSS to get rid of whatever the browser has set. So I'd be more inclined to remove the checkbox in the computed-view and only have it in the settings panel and/or in an in-panel setting menu (the option would need to control both the rule and computed views at the same time). Overall, adding a setting menu in the inspector with that option in doesn't seem like a huge task at all and would make the inspector more consistent with the debugger, style-editor and performance tool. No need to file a separate bug for this I believe, we only need to find someone who can work on this now.

(In reply to Patrick Brosset [:pbrosset] [:patrick] [:pbro] from comment #10) > - Last, my gut feeling (confirmed after discussing with a couple of web > devs) is that this option isn't useful to the majority of people using our > tools. A lot web developers don't really care that the user-agent style on a > table is to have a 2px border and what color it is. A lot of people even use > reset CSS to get rid of whatever the browser has set. > So I'd be more inclined to remove the checkbox in the computed-view and only > have it in the settings panel and/or in an in-panel setting menu (the option > would need to control both the rule and computed views at the same time). To be clear, right now these are separate prefs and we'll have to make it shared. FWIW, I find it really handy to quickly toggle on and off 'browser styles' in the computed view (probably a bad name for that checkbox) to see the final computed value of any property. Whereas in the rule view I almost never want to change this preference. So sharing it makes things slightly more inconvenient for me, but if that makes things more clear for everyone else then I'd gladly go with the change. > Overall, adding a setting menu in the inspector with that option in doesn't > seem like a huge task at all and would make the inspector more consistent > with the debugger, style-editor and performance tool. > No need to file a separate bug for this I believe, we only need to find > someone who can work on this now. I wonder where the cog would go in this case. We could stick it on the far right (even right of the tab headers), I guess, to be consistent with the other tools.

If I'm the only one wanting this then of course we should not do it ;) That's right usually webdev use a "reset" or "normalize" CSS stylesheet. When I wanted this style is when I worked on RTL stuff, and here it was immensely useful to know what the browser uses. Is it possible to show (by default) those browser rules that are not overriden ? The checkbox would show all of them.

I just created bug 1230488 (before seeing this one), which targets to add all panel-specific options to the related panels. So it might be a meta-bug for this one. I am totally for unifying the UI for changing the settings across all panels, though I believe that should be part of a separate issue (or bug 1230488 may cover that, too). Sebastian

filter on CLIMBING SHOES

Inspector bug triage (filter on CLIMBING SHOES).