Closed Bug 956478 Opened 11 years ago Closed 7 years ago

Make Australis widgets implementations consistent

Categories

(Firefox :: Toolbars and Customization, defect)

29 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ntim, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:P5])

I noticed that Panel UI subviews are not consistent at all. First of all, you might notice that the opening the history subview hides the contents of Panel UI Footer, while the Character Encoding subview doesn't. Second of all, the seperators look different across the bookmarks widget, the downloads widget, and other widgets. Maybe a simple framework for panels would be welcomed (containing styles for header, footer, seperators, items/buttons,...), a bit like shorlander's mockups. Last of all, the bookmarks widget is a menu popup, ... , why ? Those inconsistencies create bugs like bug 947586 or bug 946873.
Look at the CSS selector to target panel items : panelview toolbarbutton, #widget-overflow-list > toolbarbutton, .customizationmode-button, #edit-controls:-moz-any(:not([cui-areatype="toolbar"]),.overflowedItem) > toolbarbutton, #zoom-controls:-moz-any(:not([cui-areatype="toolbar"]),.overflowedItem) > toolbarbutton, #BMB_bookmarksPopup > menu, #BMB_bookmarksPopup > menuitem Can't this be merged into : .panel-item ?
Reference for Australis "panel framework" (in case you want to follow my idea) : http://people.mozilla.org/~shorlander/mockups-interactive/australis-interactive-mockups/windows8.html
(In reply to Tim Nguyen [:ntim] from comment #1) > Look at the CSS selector to target panel items : > panelview toolbarbutton, > #widget-overflow-list > toolbarbutton, > .customizationmode-button, > #edit-controls:-moz-any(:not([cui-areatype="toolbar"]),.overflowedItem) > > toolbarbutton, > #zoom-controls:-moz-any(:not([cui-areatype="toolbar"]),.overflowedItem) > > toolbarbutton, > #BMB_bookmarksPopup > menu, > #BMB_bookmarksPopup > menuitem > > Can't this be merged into : .panel-item ? This selector isn't specific to the subview items, though, so... no?
(In reply to :Gijs Kruitbosch from comment #3) > (In reply to Tim Nguyen [:ntim] from comment #1) > > Look at the CSS selector to target panel items : > > panelview toolbarbutton, > > #widget-overflow-list > toolbarbutton, > > .customizationmode-button, > > #edit-controls:-moz-any(:not([cui-areatype="toolbar"]),.overflowedItem) > > > toolbarbutton, > > #zoom-controls:-moz-any(:not([cui-areatype="toolbar"]),.overflowedItem) > > > toolbarbutton, > > #BMB_bookmarksPopup > menu, > > #BMB_bookmarksPopup > menuitem > > > > Can't this be merged into : .panel-item ? > > This selector isn't specific to the subview items, though, so... no? Well, shorlander's mockup does things pretty well for the DOM structure, it's clean and understandable. It's also very easy to style.
Whiteboard: [Australis:P5]
(In reply to Tim Nguyen [:ntim] from comment #0) > I noticed that Panel UI subviews are not consistent at all. > First of all, you might notice that the opening the history subview hides > the contents of Panel UI Footer, while the Character Encoding subview > doesn't. 'Character Encoding' subview does hide it to me, but 'Developer' doesn't. 29.0a1 (2014-01-28), win 7 x64
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Tim Nguyen [:ntim] from comment #0) > I noticed that Panel UI subviews are not consistent at all. > First of all, you might notice that the opening the history subview hides > the contents of Panel UI Footer, while the Character Encoding subview > doesn't. I don't think this is the case anymore, right? > Last of all, the bookmarks widget is a menu popup, ... , why ? Because it was always a menu popup and converting it to a proper arrow panel would be a large amount of work.
(In reply to :Gijs Kruitbosch from comment #7) > (In reply to Tim Nguyen [:ntim] from comment #0) > > I noticed that Panel UI subviews are not consistent at all. > > First of all, you might notice that the opening the history subview hides > > the contents of Panel UI Footer, while the Character Encoding subview > > doesn't. > > I don't think this is the case anymore, right? Still the case.
(In reply to Tim Nguyen [:ntim] from comment #8) > (In reply to :Gijs Kruitbosch from comment #7) > > (In reply to Tim Nguyen [:ntim] from comment #0) > > > I noticed that Panel UI subviews are not consistent at all. > > > First of all, you might notice that the opening the history subview hides > > > the contents of Panel UI Footer, while the Character Encoding subview > > > doesn't. > > > > I don't think this is the case anymore, right? > > Still the case. I don't see any difference between the two subviews' effects on the mainview. Can you post screenshots that clearly show what you mean?
Flags: needinfo?(ntim007)
(In reply to :Gijs Kruitbosch from comment #9) > (In reply to Tim Nguyen [:ntim] from comment #8) > > (In reply to :Gijs Kruitbosch from comment #7) > > > (In reply to Tim Nguyen [:ntim] from comment #0) > > > > I noticed that Panel UI subviews are not consistent at all. > > > > First of all, you might notice that the opening the history subview hides > > > > the contents of Panel UI Footer, while the Character Encoding subview > > > > doesn't. > > > > > > I don't think this is the case anymore, right? > > > > Still the case. > > I don't see any difference between the two subviews' effects on the > mainview. Can you post screenshots that clearly show what you mean? Actually, the issue depends on the menu panel and the subview metrics. Since the subview slides at different positions when clicking different buttons, the subview will hide different parts of the subview footer. All of this depends of where you put the button in the menu panel.
Flags: needinfo?(ntim007)
Depends on: 989821
This is a lot better now, and I don't think it's useful to keep this bug open anymore.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.