Community
Participate
Working Groups
The text input field for entering a new plugin is causing some wrapping in webkit. Seems fine in FireFox. I couldn't access Orion at all in IE8 ... I'm upgrading to IE9 now - will comment on this bug when I've tested there.
Created attachment 207541 [details] Screenshot on Safari Screenshot attached.
Seems to occur when you shrink the browser such that the top level nav links (the ones in the top right with the search box, etc.) reach the right edge of the toolbar. Currently a table is used for the header layout and the left side doesn't span across the toolbar because there is reserved space on the right for navigation commands. I think this problem has likely been there all along. The best time to fix this would be with the layout/visual design changes in the header planned for 0.4. I'd love to dump that table, but I've not found a way to use just CSS layout that worked across browsers. I'm reticent to use dijit layouts within layouts for the banner but that is another option.
Seems fine in IE9. I guess/hope that we don't support vintage IE? (In reply to comment #0) > The text input field for entering a new plugin is causing some wrapping in > webkit. Seems fine in FireFox. > I couldn't access Orion at all in IE8 ... I'm upgrading to IE9 now - will > comment on this bug when I've tested there.
Interesting. When I made the bug report I studied what Dojo had to offer on the subject, to see if I could propose a quick solution from there. They have a scrolling tab menubar that you can see here: http://dojotoolkit.org/widgets But I couldn't find a reference for a scrolling toolbar in the quick search around that I made. I had a similar problem, though it didn't overlap, with the drawing toolbar in my last project, which kind of remained unsolved ... it just wrapped - I think the default behaviour of Dojo toolbars. I think part of this solution is in understanding the behaviour that we'd like to see - wrapping, scrolling, clipping, limiting, blocking? And then the other part is how to accomplish that - but it might be a nice opportunity to use the HTML5 box model ... especially if we're only targeting modern browsers at the moment. http://www.html5rocks.com/en/tutorials/flexbox/quick/ Anton (In reply to comment #2) > Seems to occur when you shrink the browser such that the top level nav links > (the ones in the top right with the search box, etc.) reach the right edge of > the toolbar. Currently a table is used for the header layout and the left side > doesn't span across the toolbar because there is reserved space on the right > for navigation commands. > I think this problem has likely been there all along. The best time to fix > this would be with the layout/visual design changes in the header planned for > 0.4. I'd love to dump that table, but I've not found a way to use just CSS > layout that worked across browsers. I'm reticent to use dijit layouts within > layouts for the banner but that is another option.
(In reply to comment #4) > Interesting. When I made the bug report I studied what Dojo had to offer on the > subject, to see if I could propose a quick solution from there. They have a > scrolling tab menubar that you can see here: > > http://dojotoolkit.org/widgets > > But I couldn't find a reference for a scrolling toolbar in the quick search > around that I made. > > I had a similar problem, though it didn't overlap, with the drawing toolbar in > my last project, which kind of remained unsolved ... it just wrapped - I think > the default behaviour of Dojo toolbars. > > I think part of this solution is in understanding the behaviour that we'd like > to see - wrapping, scrolling, clipping, limiting, blocking? And then the other > part is how to accomplish that - but it might be a nice opportunity to use the > HTML5 box model ... especially if we're only targeting modern browsers at the > moment. > > http://www.html5rocks.com/en/tutorials/flexbox/quick/ > Finally catching up to this. I agree completely that the first step is to figure out what we want. Today, we basically have a grid, 3 col by 5 rows (the 5th row is the parameter slideout so it's not always there), but we want that flex so that if someone isn't using all their space, someone else could grab it. So in this particular bug, the fact that cell (1, 4) (the toolbar) is butting into cell (3,1) (the primary nav links) really shouldn't matter at all. The reality, though, is that I'm not sure flexbox would do any better for this particular bug, because the problem is that the row 4/5 behavior should really not be related to the columnar distribution in rows 1/2/3. I've been putting off doing anything because I never liked our current approach and I think we are going to redesign the banner anyway (see http://wiki.eclipse.org/Orion/Page_Layout). So my current plan is to live with this bug for a little bit longer and see how we would like to layout the header to address other issues. From there we could then decide what works best. It's some kind of a grid within a grid thing which we could continue to solve with a table model (table or css table-xx) or, once IE10 is out, move to css3 flexbox, css columns, or whatever seems to fit best. I really appreciate your comments, because I started out thinking, "yeah, wait for flexbox" and then I realized that a missing sub-layout is the problem in this particular case. For example if row 4/5 were colspan=3 with a 2-column subtable, I bet it would work as I would like it to, but tables are so embarrassing that I've never even considered a table within a table. (I don't really think CSS display: table-xxx is really better than table, so I consider those the same).
Fixed with the new header layout structure. I abandoned the table, css table-column, etc. in favor good old low tech nested divs and float left/right. Now the toolbar will wrap if needed to fit everything. Another key thing was to have the command service call for a forced layout so that the containing dojo layout widgets would know they had to lay out again.
