Users should be able to inspect CSS rules whose selectors employ pseudoclasses like :active, :hover, :focus, :visited.
Created attachment 97620 [details] [PATCH] Suggested solution, initial version
Created attachment 97621 [details] [IMAGE] Screenshot of the Style Settings UI (slides to and from the right edge)
I need to mention that the UI is still highly debatable, and thus all the new strings have NOT been added to localizedStrings.js.
I'd remove all the borders and use a gray / dark gray background color. Horizontal lines are enough to separate the sections. Look at the Safari Preferences (say Bookmars tab) for inspiration. Or you can make it a bit more web-friendly looking as in Chrome's preferences.
Some comments after applying the patch: - Remove the title - Gear should toggle the settings pane - Speed up animation - There is a nested scrollbar base in docked mode, scrollbar does not disappear on settings close - Esc should close it I was kinda expecting settings to replace the actual section content. That way you would have no scrollbar issues and the UI would be more consistent. You could animate existing section content to height 0 and then roll settings out vertically (as an idea)
(In reply to comment #5) > Some comments after applying the patch: > > - Remove the title Easy to do > - Gear should toggle the settings pane Currently I have a pane cover the entire sidebar and inhibiting user interaction with it while the settings pane is active. Do we want the settings pane to behave exactly as the new styles pane content (i.e. not interfere with other sibling panes and the sidebar in general)? > - Speed up animation Easy to do > - There is a nested scrollbar base in docked mode, scrollbar does not disappear on settings close I never saw this artifact in the docked mode (and I barely understand what it's all about) but I'll investigate. > - Esc should close it Should it commit or cancel the changes made? I know it to be the Apple approach that when a settings window is closed, all tweaked settings get applied regardless. > I was kinda expecting settings to replace the actual section content. That way you would have no scrollbar issues and the UI would be more consistent. You could animate existing section content to height 0 and then roll settings out vertically (as an idea) While learning stuff about the 2D/3D transforms, I found out that 3D transforms do not work in all browser setups (e.g. one article mentions that Chrome currently supports 3D CSS transforms only with accelerated compositing enabled (for which you may need to tweak your browser config)), so I decided to stick to 2D. If you feel a 3D transform is more appropriate in our case, I'm fine with using it instead. But, as we figured during a discussion, a short/collapsed Styles pane does not look like a good candidate for a replacement by the settings pane. In this case we'd need to do something similar to what you suggest above.
Could the settings sheet be made to match the rest of the inspector a bit more?
Created attachment 98169 [details] [PATCH] An iteration after a discussion with pfeldman
Created attachment 98171 [details] [IMAGE] Screenshot for patch 98169 (the pane replaces the style data (and vice versa) when the gearbox 2-state button is clicked)
Still not really a fan of the UI for this
Created attachment 98778 [details] [IMAGE] Settings panel in Opera Dragonfly I can't think of anything more user friendly that this one. Except for I would make it in a settings-per-panel manner. That way options would be both: discoverable and contextual.
I prefer https://bug-62853-attachments.webkit.org/attachment.cgi?id=98171 over what Opera does.
Created attachment 99456 [details] [PATCH] (Wip) Reusing shortcuts help screen, screenshot to follow.
Created attachment 99459 [details] [IMAGE] Screenshot with patch applied. The reasons I like it this way: - It is consistent with the help screen, so no new UI concepts - We tend to get too many "gear" icons all over the place (see Elements panel) - Not always there is a gear icon (Word wrap in DOM view and XHR logging are toggles in the context menus) - Having settings centralized increase their discoverability What do you think?
Created attachment 99612 [details] [PATCH] Wip MacOS looking nice.
Created attachment 99629 [details] Patch
Created attachment 99643 [details] Patch
Created attachment 99644 [details] [IMAGE] Screenshot with patch applied.
Comment on attachment 99643 [details] Patch The change looks good to me. Please make sure that everyone is OK with the design.
Committed r90387: <http://trac.webkit.org/changeset/90387>