Shortcuts toolbar tray does not properly float the "Edit shortcuts" link in Bartik

Started to work on this issue

Attached here is patch for Edit shortcuts link aligned to the right in vertical and horizontal orientation.

From user experience prespective positioning of Edit shortcuts can be missed due to large screen. Adding ux tag

Unassign

Double-height seems caused by the .clearfix class on the tooblar-tray > ul element.
A fix for this, without removing that class from the markup, could be adding a

.toolbar .menu {
display: inline;
}

It seems a better options to actually render the edit anchor before the list of menu items and then float it to the right. (else it will be only patchwork to get it to float correct). Will try to make a patch.

This patch adds a weight to the Edit shortcuts link, this way it will render before the menu itself. After that I float the element to the right instead of left. This way it will render on the same line as the menu without having to change the menu items to inline elements.

Patch works fine in horizontal orientation, but with the vertical one the "edit shortcuts" stays on top.

New patch, this patch doesn't change any module logic, it floats the .menu in shortcut.theme.css (to only apply it to the shortcut menu), next it floats the edit link to the right. This way it has the normal logic without any stylesheets applied and works in the horizontal and vertical orientation.

Tested @richardj patch and it works fine. Only issue I see is when you click the compress arrow that compresses the toolbar and sets it on the left side, the edit shortcuts text looks a bit silly being unaligned. Other then that, great job. #SprintWeekend

I'm not sure abou this, but I think perhaps there was already some css that was supposed to do this, but the class got removed due to a toolbar logic change.

Here's an alternate method that simply removes the ".shortcuts" class, basically accomplishing the same thing.

I think this may be related to the issue here, that was committed:
#1908906: Remove unused code from toolbar_pre_render_item that throws a warning on custom themed tabs

If that's the case, I think the patch in #10 is the way to proceed.

But to remove the logic from the toolbar makes it in the future impossible to override it? (I would say custom admin themes of some sort). I would go with fix #10 were it not that it removes the logic to the function of the menu.

Tested @jessehs patch from comment #10. Patch works as advertised.

In the horizontal menu the edit link appears to the right of the text. In the vertical menu, it appears to the right after the text. I've attached screenshots for both.

Patch was tested on Windows 7 in Firefox 20.0.1, Chrome 26.0.1410.64, Opera 12.15, Safari 5.1.7 and IE 8&9. Themes used were Bartik, Seven and Stark.

Are we sure this is the right solution?

Here is the html from a default install in bartik (where "edit shortcut" is on a new line)...

<div class="lining clearfix"><h3 class="element-invisible">User-defined shortcuts</h3><ul class="menu clearfix"><li class="first leaf"><a href="/node/add">Add content</a></li>
<li class="last leaf"><a href="/admin/content">All content</a></li>
</ul><a href="/admin/config/user-interface/shortcut/default" class="edit-shortcuts">Edit shortcuts</a><div class="toggle-orientation"><div class="lining"><button class="icon icon-toggle-vertical" type="button" value="vertical">Vertical orientation</button></div></div></div>

Here is the html from a default install in seven (where "edit shortcut" is NOT on a new line)...

<div class="lining clearfix"><h3 class="element-invisible">User-defined shortcuts</h3><ul class="menu"><li class="first leaf active-trail"><a href="/node/add" class="active-trail active">Add content</a></li>
<li class="last leaf"><a href="/admin/content">All content</a></li>
</ul><a href="/admin/config/user-interface/shortcut/default" class="edit-shortcuts">Edit shortcuts</a><div class="toggle-orientation"><div class="lining"><button class="icon icon-toggle-vertical" type="button" value="vertical">Vertical orientation</button></div></div></div>

Comparing the bartik output with the seven output it appears that the issue that the ul has the clearfix class applied. The patch in #10 just ensures that the ul is always floated which is not necessary in seven. Perhaps we should investigate what's adding the clearfix in Bartik?

So here's an alternate solution which from the clearfix from the shortcut menu tree using the theme system...

This is not a bartik issue is it?

It only happens for me in bartik and the cause is bartik's implementation of theme_menu_tree() - so I think it is :)

With the fix in #15 admin/structure/views is still broken but this is because views.admin.css contains some far too general css... see below...

/* @group Inline lists */

.horizontal > * {
  clear: none;
  float: left; /* LTR */
}

.horizontal.right {
  float: right;
}

.horizontal label {
  position: absolute;
}

.horizontal .form-item > [class] {
  margin-top: 25px;
}

.horizontal .form-item > [class] + [class] {
  margin-top: 0;
}

/* @end */

Applied patch from comment #15. The clearfix class was removed from the ul. The 'Edit shortcuts' link displayed the same as in the screenshots from comment #13.

Tested on the Bartik, Seven and Stark themes using Firefox 20.0.1, Chrome 26.0.1410.64, Opera 12.15, Safari 5.1.7 and IE 8/9. OS is Windows 7.

I've created a fresh D8 install and can see the issue. I applied the patch in #15 and cleared both the Drupal and browser caches. After logging in I can see the edit shortcuts link positioned as in #13. I've tested both in the Bartik and Stark themes across the main browsers on Win7 as well as Firefox on Ubuntu. Is this an OSX issue or am I doing something incredibly silly?

This was bugging me today, too. Read through the issue, applied #15, and everything worked as advertised (and appeared visually similar to shortcuts in Seven). It's not an OS dependent patch (I use OS X and tested in Chrome / Safari) - maybe just a case of multiple environments or a missed cache clear before testing. Good to go again? : )

And the component for posterity's sake.

And how about a title that makes sense. : )

We need an issue created for #18...

Not sure what you mean... you want someone else to create an issue to address the Views inline CSS and then you'll commit this? Or can you not commit your own patches?

Both... I should not and we've discovered an issue in views css so this needs an issue.

Okay, I've created the follow-up issue: #2031263: Overly broad CSS in views_ui.admin.css interferes with properly floating Toolbar shortcut links. I'm a bit new the core development process so please forgive all the questions, but is it a policy for maintainers not to create new issues like this when they identify them in the course of some other issue? Just wanna make sure I read people right in the future. : )

This issue was RTBC and passing tests on July 1, the beginning of API freeze.

#15 isn't an API change, so removing the "RTBC July 1" tag since it is irrelevant.

Committed/pushed to 8.x, thanks!