Dropbutton style update for Seven

Maybe this should happen here: http://drupal.org/node/1899236

After much work I’ve completely re-written the JS for this in #1899236: Add new Splitbutton render element to eventually replace Dropbutton. I think it’s now ready to be made into a patch, but I would love some help with JS and PHP.

b

I'm concerned about the progress of #1899236: Add new Splitbutton render element to eventually replace Dropbutton and the reliance on some hardcore PHP hacking to get the correct output. It's really important that we get all buttons in core looking consistent.

I think it's better to split to issue into two. Let's implement the updated styling here and come back to deal with the tricky stuff in #1899236: Add new Splitbutton render element to eventually replace Dropbutton.

Here's the latest patch, we'll need to remove the functional changes.

Sending for test.

aaaa

I decided it was easier to start again, written on top of #1986074: Buttons style update.

Here's a first shot at a CSS only patch. It would be nice to create a primary and small variant, seeing as we can't easily reuse all the button classes in #1986074: Buttons style update.

...

1. Dropbutton doesn't have the styling between the text and the dropdown, see dropbuttons.png
2. Buttons on views administration page have become unreadable, see buttons-views.png

I just committed #1986074: Buttons style update which now makes the node add/edit form look like this:

Because that's rather wonky-looking, and because that's a very frequently-visited page, I'd love this patch to make it in by the next alpha (Dec. 16). Tagging such. Go, emma, go! :)

Working on this today :)

10: dropbutton-style-1989470-10.patch queued for re-testing.

10: dropbutton-style-1989470-10.patch queued for re-testing.

10: dropbutton-style-1989470-10.patch queued for re-testing.

This was as far as I could get for now. I focused on the styling for the normal buttons, not the primary ones.

Patch doesn't apply :(

+++ b/core/themes/seven/css/components/dropbuttons.css
@@ -0,0 +1,259 @@
+  border-radius: 20em;
...
+  border-radius: 20em;
...
+  border-radius: 20em;
...
+  border-radius: 20em;

Also, despite having this radius defined four times (twice for 2 selectors), all dropbuttons are square when I tested it

Ok... this was hard work but I think it's almost there. The issue I kept banging my head against only seems to appear on the views listing page and I can't see what is affecting it.

It would be good to get some other eyes on it while I dunk my head in ice cold water.

I found some problems in Chrome (Mac) but those look like cross browser issues to me.

First thing is publish button on create node page looking bad.

Second problem is dropdown button on Content Types page. First the label of button is cut because the parent table doesn't have enough space for operations column. I'm not sure if this is reported as a bug in separate issue?
Moreover the button is pushed down and after expanding it unfolds to the right not left (I've seen it does unfold to the left correctly on views edit pages). This might also be a separate issue I'm not sure :)

I'll try to figure out what's causing this now.

@LewisNyman that double border bit is happening due to position: absolute vs position: static.

No double border with this:
.js .views-edit-view .dropbutton-widget { position: static; }

Though changing that won't help because the widget will want to expand the cell's width with position: static; Maybe a suggestion is to use box-shadow to emulate a border outside of the box... or there may be a box-sizing property that could help here too.

@philipz i'm on chrome and ff mac and I don't see that issue in your screenshot, may want to clear caches and the like? The expanding left vs right issue should be fixed with split button but that's a different issue, the positioning of the button affects which way it will expand.

In addition to those, this is definitely not going to fly (from the node form):

When I apply the patch on simplytest.me I see this?

Hm. Well that's definitely much nicer than what I see. :D I even tried private browsing. I'll futz with my local and see what's going on. This is Firefox on OSX, fwiw.

I was testing and making screenshots from #23 on latest 8.x dev but you were right about cache. I though I cleared it but maybe I did not. Anyway now I confirm I see publish button exactly as #26. Looks great :)

Unfortunately buttons on Content Type page, Languages page or Text formats and editors page all look like below. Does this patch deal with that?

Combined three screenshots:

I can confirm that; even in English, this looks wrong, e.g. on admin/structure/types:

Node form looks good though. :D

Another screen that be lookin' funky is the configuration synchronization screen:

OK I've tested it more and it seems the overflow: hidden on dropdown labels (when folded) is caused by

.js .dropbutton-widget .dropbutton {
  overflow: visible;
}

in /core/themes/seven/css/components/dropbuttons.css
I don't know if this is really needed somewhere else? I think visible overflow on buttons is bad in any case possible.

Regarding buttons shifted down it is NOT happening on Views admin listing page for example and it is because the td has vertical-align: top. This (almost) fixes the problem for other admin listings like Content Types page. This needs change in /core/themes/seven/style.css so it might need more testing.

After couple of changes and I've got this looking like this (in attached screenshots).
There's one change in core/modules/views_ui/css/views_ui.admin.css to fix a little glitch on view edit page.

Please ignore this patch #32. Needs more work. Sorry for the noise I will test future patches better :)

Tested this one on Views list/edit pages, admin list page (Text formats and editors) and node create page. This is based on #21.

35: dropbutton-style-1989470-34.patch queued for re-testing.

Hey nice work :) This is looking very close. Even the views edit page looks great!

The only thing I could spot is that the primary border is missing from the toggle. I found it was a position static being set in misc/dropbutton.css. This patch overwrites that.

That was not easy to see ;) Now it looks really nice. As always clearing caches and refreshing browser couple of times was necessary.

Hm. A fail in ThemeHandlerTest sounds like it could be legit, but let's re-test and find out...

39: dropbutton-style-1989470-38.patch queued for re-testing.

It seems that there is a test that checks the stylesheets loaded in the Seven info file actually exist.

Awesome, this is soooo close!

Checked node form, manage fields page, views UI, and config page in Firefox, Chrome, and Safari. Looks awesome in all three!

The only thing that seemed odd to me is that on some tables, e.g. the Manage Fields page and the Configuration Synchronization page, have what look like EXCEPTIONALLY LARGE DROPBUTTONS relative to the size of other things, esp. when they have add actions there, like:

But other places these look like I would expect (i.e. relative to their current size), like the Views main listing:

If it's possible to tweak this quickly, I'm happy to RTBC and commit this. If it's possible to do by Monday, it could go into alpha7 and that would be amazing. :D If not, no worries, we can catch it next time...

Also, this is off-topic (I think), but what's the plan for these "kinda sorta not really actually a dropbutton" buttons on the Views UI? They do look exceptionally odd now that the rest of the buttons on this page look so slick.

Is there a reason we don't convert those to standard dropbuttons as well?

Once again, apologies if any visual inconsistencies are down to caching issues. :( Not marking "needs work" for that reason.

Please try this one. It should fix different button size problems.
There's still quite some mix of too many buttons styles in many different files like views_ui styles, buttons styles and dropbuttons styles. I'll dig into that some more next week.

Yeah, I'm fine pushing that to a follow-up, I was just making sure it was intended to get looked at at some point.

@philipz can you please post interdiffs for every patch? Comparing the two side-by-side is difficult for reviews and posting an interdiff is trivial for patch rollers.

Also screenshots help.

Thanks klonos!

We spent a long time making sure these buttons looked right the first time, and when used in listings, I think this is a visual regression. The text is not vertically centered like it used to be, and the button just looks too big for the font.

There's a reason Views had a different size: it looks silly to have huge buttons in line with normal sized text.

Also this one is completely different from the rest...

Make sure to "drush cc all" and triple clear caches, or else test on simplytest.me. That's not what the Views UI looks like here, it looks more like the 2nd screenshot of #47. (Of course, it's possible that *I* only double cleared cache on my own local and am in the wrong here! ;))

@tim.plunkett sorry for not posting interdiff. You definitely need to clear cache as @webchick said.

If we can I'd like to include changes to Views UI into this issue. It's a lot of work and extra code to make Views UI look as it used to and one of the aims of the style guide is bring more consistency to the whole admin interface. If we can fix all concerns raised by @tim.plunkett and other Views maintainers without actually writing any Views specific CSS that would be great.

If Views requires a smaller text size button the best way would be to create that variant globally the same way we do for regular buttons: .button--small. Maybe that is better in a follow up because requires changing mark up.

Yeah, I guess my only feeling is that right now the node form (an extremely user-facing form) looks pretty nasty with only 1/2 of its buttons converted to the new style, and so I'd love to see this in sooner than later. So if we can get Views UI to look passable here, I'd prefer deferring "UBER AWESOME" to a follow-up. But let's see what Tim says.

Testing the latest patch now, stay tuned...

Ok this actually looks quite fine to me, but should probably get another review by someone who parses CSS. :)

My concerns about the inconsistent size of dropbuttons are fixed:

And Views UI looks like this which, apart from the top-left pseudo-dropbutton stuff, looks fine to me:

The caveat, of course, is by not fixing the pseudo-dropbuttons here, we are doing to Views UI what we did to the node edit form, which is make it look pretty awful and half-done. However, since Views is a less-frequently-accessed page than the node form (at least by *most* people :D), I'd be ok with this as a stop-gap. But assigning to Tim Plunkett to see what he thinks.

This last attempt is based on #46 again + only one change from #48. Nothing more.
I've removed changes to views admin ui files witch makes buttons on view edit page smaller and nicer again.
Also I'm not sure why but now action buttons on node form have correct font-size without overriding made in #48. Maybe some other patches went in and fixed it? Anyway it's good that this is not needed in this patch anymore.

Here's last patch based on #46 + interdiff and screenshots. Tested this in FF, Crome and Safari. Except smaller buttons on view edit page everything else looks like @webchick's screenshots :)

@philipz: #2157113: The "insert/edit image" BUeditor button still pre-fills the file url as http://drupal.org/files/

In HEAD, the dropbutton links are still clearly links, since they have blue text and match the other links.
With this patch they are black text, which is not as accessible.

The zebra striping and borders have been removed, making it harder to see where one clickable area begins and the other ends. The rounded corners are also not correct in the Views UI.
HEAD:
PATCH:

Furthermore, the expanded dropbutton is broken now. I tried this in a fresh install in incognito mode after clearing every cache possible.

In HEAD the buttons do not affect their container when expanding, here they force other columns to resize, as well as the rows to grow to fit. This was done purposefully after extensive accessibility and UX testing, so this is a regression.

HEAD:
PATCH:
The shifting of the columns can't really be shown with an image, but the row shifting can. Both are very disorienting, and we worked hard to prevent that the first time around.

In all honestly, I don't see why the dropbuttons need to change. Only the node form doesn't match other buttons and is used alongside them, but that is one-off code. That code was added much after the dropbutton code, and did not have any actual UI review or review from the VDC team (who moved dropbutton in from CTools).

The dropbuttons used on listing pages like admin/structure/types, or in the Views UI, are fine as is.

I would like to see this issue rescoped to fixing the node/add/% button, and that way avoid need for further UX/a11y testing (the tag I added can be removed if that is agreed upon).

In fact, the dropbutton is supposed to just be a variant of #theme => links.

The node form is a complete abuse of dropbuttons, and is the reason it looks so bad.

#1751606: Move published status checkbox next to "Save", under the commit message of "Issue #1751606 follow-up by sun, swentel: Various fixes for content creation page." (not even the actual commit for the issue but a follow-up!) introduced a whole form_pre_render_actions_dropbutton(), in order to trick buttons into looking like dropbuttons.

The buttons in the top right of the Views UI that look off that keep being mentioned but pushed to a follow-up, those are the only other place that dropbuttons are used for non-links, but with a completely different implementation.

So please, leave the dropbutton for actual links alone, and let's undo the damage done with the node/add form, form_pre_render_actions_dropbutton, and non-link dropbuttons.

Hm. I'm not sure I totally agree with that. Or at least, when I look up the "drop button" / "split button" pattern on e.g. Google Image search I get pictures like:

http://i.msdn.microsoft.com/dynimg/IC155322.png — Microsoft

http://getbootstrap.com/components/#btn-dropdowns — Twitter Bootstrap

These are very similar to the designs in the Seven Style Guide, and "buttonish", not "linkish." The Seven Style Guide was also developed in concert with the Drupal UX team, so presumably they made it not look like links on purpose?

Or, put another way, is there any other application other than Drupal that styles dropbuttons the way HEAD does?

"Add" etc. in Views as well as "Manage fields" and such initiates an action, so to me buttons are appropriate there.

However, the points about not stretching the table row, losing the zebra striping, etc. are all totally valid.

From the original CTools docs:

The dropbutton menu will show up as a button with a clickable twisty pointer to the right. When clicked the button will expand, showing the list of links.

If that was improperly named, then we inherited the bad naming. But it has always been for a list of links.

Everyone has agreed that the node/add button needs to be fixed. But it is a list of buttons, not a list of links.

I agree with @tim.plunkett that we could leave the dropbuttons as they are.

I'll focus on fixing current problems with 'droplinks': labels being cut and links expanding in wrong direction. This is a big thing because it looks bad now. This often is worse in languages other than english where many words are longer. I found issue on that problem that is not moving forward #1890266: dropbutton text fails to retain .dropbutton-widget width.

The main aim of the style guide is to provide consistency, not just make things look better. When Bojhan or myself have presented the style guide this is the picture we usually show that justifies it.

Everyone has agreed that the node/add button needs to be fixed. But it is a list of buttons, not a list of links.

It doesn't actually matter whether the html tag is a link or a form button, it's how we represent these elements to the user.

The comments raised in #61 are all perfectly valid and actionable but I them frustrating because both Ry5n and myself spent a lot of time implementing the original style guide design for dropbuttons in #1899236: Add new Splitbutton render element to eventually replace Dropbutton which would fixed all these problems but I never received any support or feedback from the VDC team. It's a shame we are in the situation where we have to compromise the design in this issue.

Actually that issue received direct criticism. That counts as feedback too.

I've gone through the regressions raised and had a go at fixing them. Mainly on the views/content type listing pages. There is still a few glitches on the Views edit pages on dropbuttons that are just one button(?) or dropbuttons that have two items in them. I'll try and get to that this even unless you have any spare time @philipz.

OK I will look into those glitches later today.

@LewisNyman I think I fixed issues on Views edit pages you mentioned.
Also I've added right margin to buttons in tables so they fit better in operations column - they didn't it chrome without this margin.

The layout shifting and bottom left corner glitch are gone, but the zebra striping/boring is still missing

Do you think the hover effect on the links is enough or should we add the separating lines as well? I'm not fussed either way but if we can solve the problem with less all the better.

Are we talking about zebra striping like the one in Views edit page on buttons in three columns?
There it is applied but it's not looking very good. The style guide does not show any example of this striping and the current HEAD dropbuttons do not have any zebra striping too but they do have separating lines.

I would go here with the separating lines only unless this is accessability requirement.

Turns out the zebra striping came from an overly broad selector in the views admin CSS. I've also added the separating borders in this patch so we can make a decision with a full view.

I really like how this looks now! Also I didn't find any problems in Firefox, Chrome and Safari.

75: dropbutton-style-1989470-75.patch queued for re-testing.

I'll do the re-roll the patch.

Re-rolled #75

Looks good. I tested in FF and Chrome and found one thing only: right border radius on hover.

Changed tags

I'm working on it

I have fixed the dropdown's borders issue. Have a look at the following screenshot:

Notice that i have also removed the outline because it was causing extra borders when the dropdown was expanded.

Tested in FF & Chrome. Everything looks good now.
I'm not setting it as RTBC yet as at least one or two people should look on it :)

Since we're losing the zebra striping, we need someone to do an a11y review (WCAG AA, specifically), because it's not really obvious which one you're hovering over.

Otherwise, this looks fine.

The color contrast looks fine, but without a mouse the tab order really makes it look like you can't click on the buttons.

You can, but it's only at the end of the page after everything else.

There is a a slight effect over the Preview button (like there is with the mouse) but no noticeable over the Save and ... button. When you press enter on the down arrow (there is no indication that you are over it, you just have to guess) it works as expected.

The tab order is wrong and there is no way to tell you are focused on the new drop-down.

About text formats & Text format - are actually in the wrong order too, and that should be changed, but it's a much less serious accessibility issue.

It should be Text format -> About text formats -> Save and publish -> down arrow -> Save as unpublished -> Preview -> Create new revision

Thanks Mike, how about this?

Some of this might be bigger than the Dropbutton style update. However there still is no indication that the down arrow has focus. Also, it's probably better to follow the mouse over design change when that does provide a clear pattern that works well (although not for the arrow).

The use of underline is a good addition, particularly when the drop button is open.

The use of underline is a good addition,...

and/or we could have the active link text be bolded while the other option(s) are regular text. That would help a bit more to distinguish the active/current menu. I'm not sure if that might cause a width/size shift though.

However there still is no indication that the down arrow has focus.

This should be fixed now. Also removed .first classes in favor of :first-child.

we could have the active link text be bolded while the other option(s) are regular text

The buttons' text is bold already without hover so first this requires to change buttons to normal weight.
I tested this idea and as you expected the button's width shifts.

Is the tab order problem going to block this patch from RTBC?

I think that tab order can be a new issue.

Why would we introduce an accessibility regression for the sake of a minor design tweak?

I applied @LewisNyman & @philipz's patch at the same time right now. The patch in #89 looks like it has the focus that is required. I've just included some shots of the various states of the button using keyboard focus. Seems like this nails it.

I'd assumed that @philipz was just building on #89 and would also include the same effect on focus. It didn't.

I was building on #89 and the changes were very minor. More precisely I added :focus rules to dropbutton-action and dropbutton-toggle elements which were not present in patch #89.
The screenshots you've included look exactly like I've seen after applying patch #92.
I'll check again but are you sure you didn't cross/mix the patches? :)

@philipz Not sure why they didn't behave the same. Maybe there was a bug when I installed it on SimplyTest.me. I do wish that SimplyTest.me had a summary of what was submitted so that one could more easily double check after the install is up and running. It seems to be bust right now though.

Ultimately, as long as that behavior is there, then it should be fine.

I just confirmed the interdiff.txt in #92 is correct. The patch in #92 should have the improvements from #82.

92: dropbutton-style-1989470-92.patch queued for re-testing.

The patch in #92 works properly, including the focus behavior.

Found two minor problems.

1. The webkit focus outline is added to the dropdown arrow on focus; this is undesirable AFAIK. Setting outline: none on that element fixes it.
2. When using the keyboard to navigate: if I tab onto the dropbutton, the primary action gets a different shade of blue — this is great. When I then tab to the dropdown arrow, then that shade moves here — even better! If I now press enter to show the other actions, the dropdown arrow expands to make room for the other actions, and focus remains on the dropdown arrow. I'd expect that different shade to persist, but it does not. As a keyboard navigation user, I'm now lost: I don't know which thing has focus anymore.
3. When using the keyboard to navigate: if I tab onto the dropbutton, the primary action gets a different shade of blue — this is great. However, once I've toggled the dropdown arrow to show all available actions, then *none* of the actions get that shade anymore, not even the primary action. The underline helps, but it's an inconsistent UX, especially combined with point 2.

I realised half way through this patch why there were no background styles on hover/focus, the shapes of the inner buttons are tricky to manage. Anyway I've been over the dropbuttons on the content creation page, views listing table, and views edit page. and ended up having to rewrite quite a bit of the styling. I also realised that we were missing the active styles! That's the best part!

I realise the CSS for this is seriously WET, this issue was only intended to be a stop gap to get the dropbuttons consistent with the regular buttons before we do a proper clean up of the mark up in #1899236: Add new Splitbutton render element to eventually replace Dropbutton

Oh noes, sorry about that! :( I can confirm that the problem I described in #106 has been fixed, but I'm afraid this now needs CSS review again.

+++ b/core/modules/views_ui/css/views_ui.admin.theme.css
@@ -1128,6 +1128,7 @@ div.messages {
+  width: auto!important;

@@ -1135,6 +1136,9 @@ div.messages {
+  width: auto!important;

EEK!

That was naughty and I am sorry.

Patch applies well and seems to be ok (see screenshots).

Just fixed some missing periods and indentation (see interdiff.txt).

110: dropbutton-style-1989470-110.patch queued for re-testing.

Reroll. Knocked out by #2194807: Remove obsolete CSS for language admin form

Ok, now applies and looks perfect! Let commit this asap :)

1. +++ b/core/themes/seven/css/components/dropbuttons.css
   @@ -0,0 +1,290 @@
   +/**
   + * Reset styling for all elements.
   + */
   +.js .dropbutton .dropbutton-action > * {
   

   Um what?

2. +++ b/core/themes/seven/css/components/dropbuttons.css
   @@ -0,0 +1,290 @@
   +/**
   + * Copied styling for .button.
   + */
   +.js .dropbutton-multiple .dropbutton-widget {
   

   Do you mean copied from? Also why wouldn't we just use .button in the markup, instead of duplicating the CSS that will absolutely diverge the next time someone messes with the .button style?

3. +++ b/core/themes/seven/css/components/dropbuttons.css
   @@ -0,0 +1,290 @@
   +  background-image: -webkit-linear-gradient(top, #fcfcfa, #e9e9dd);
   +  background-image:    -moz-linear-gradient(top, #fcfcfa, #e9e9dd);
   +  background-image:      -o-linear-gradient(top, #fcfcfa, #e9e9dd);
   +  background-image:   linear-gradient(to bottom, #fcfcfa, #e9e9dd);
   

   This indentation is whack.

4. +++ b/core/themes/seven/css/components/dropbuttons.css
   @@ -0,0 +1,290 @@
   +
   +/**
   + * Rare instances when a dropbutton is actually just a button.
   + * Copied from Seven's buttons.theme.css.
   + */
   +.dropbutton-single .dropbutton-widget {
   +  border: 0;
   +}
   

   I don't see how this is "rare". And again with the copy/paste

5. +++ b/core/themes/seven/css/components/dropbuttons.css
   @@ -0,0 +1,290 @@
   + * Copied styling from .button--primary.
   + */
   +.js .form-actions .dropbutton .dropbutton-action > * {
   

   Seriously? Why bother using a *cascading* stylesheet if we just copy everything every time?

@tim.plunkett - I assume you meant to change the status too.

Suggesting changes is good. Thanks for posting your concerns. "Um what?" really isn't all that helpful.

@tim.plunkett Yep, there's a really good reason why we're copying CSS instead of reusing it. We tried fixing all the problems with dropbutton in one with #1899236: Add new Splitbutton render element to eventually replace Dropbutton and that didn't work out very well, it was very difficult to fix every implementation of dropbutton in core. This consistent with the approaches we have taken in other style guide issues.

The markup is already bad, it's easier to work with it here and fix the markup that already exists in a follow up issue. Webchick has highlighted that the inconsistency between buttons is a high priority. We already have #2160481: Componentize the dropbutton CSS as a follow up. I'm happy to make more before this gets committed.

I've changed the indentation for the gradient CSS. Which technique is more readable is debatable. It would be nice if we could give specific guidance in our CSS standards.

I think the last thing to do here is provide before and after screenshots of the Views UI in Bartik and Stark, since this changes views_ui.admin.css and views_ui.admin.theme.css (which are not Seven specific).

+++ b/core/modules/views_ui/css/views_ui.admin.theme.css
@@ -1116,15 +1116,8 @@ div.messages {
-.dropbutton-wrapper {
-  font-size: 11px;
...
+.js .dropbutton-wrapper .dropbutton .dropbutton-action > * {
+  font-size: 12px;

@@ -1133,8 +1126,9 @@ div.messages {
-.views-display-top .dropbutton-wrapper a {
-  font-size: 12px;
+.views-display-top .dropbutton-wrapper .dropbutton-widget a {
+  font-size: 11px;

@@ -1142,13 +1136,16 @@ div.messages {
 .views-ui-display-tab-actions .dropbutton-wrapper li a,
 .views-ui-display-tab-actions .dropbutton-wrapper input {
...
-  font-size: 12px;
+  font-size: 11px;

+++ b/core/themes/seven/css/components/dropbuttons.css
@@ -0,0 +1,290 @@
+.dropbutton-single .dropbutton-action a {
...
+  font-size: 14px;
+  font-size: 0.875rem;

The different font sizes were odd before, but now seem even more arbitrary.
This isn't an actionable comment per se, just pointing out that I'm more confused now than I was before :)

Aha that's a good point, I went though and removed those redundant/inconsistent font size declarations and everything still looks fine. I also noticed a rounded corner issue that was ccaused by the font size change and a text alignment issue on one views dropbutton that uses input elements.

Here are some before/after screenshots:

+++ b/core/modules/views_ui/css/views_ui.admin.theme.css
@@ -1142,13 +1141,15 @@ div.messages {
-  font-size: 12px;

I was looking for screenshots of the Views UI in Bartik and Stark, not just Seven, since you're making changes to a module here.

Ok, I added that font size declaration back in, I may of removed it by mistake.

Lots of screenshots!

Are we RTBC worthy? :)

Seems ok for me except a little hover on the node creation page. Here is a patch

Before

After

The patch in #123 did not apply. It needed a re-roll, because there was a new css file (dialog.theme.css) added to .info and test code. Here is a re-roll, it applied without errors and dropbuttons look delicious.

Since it's a re-roll, still needs review.

And here is the patch i forgot to attach to #124.

Reviewing in progress...

1. +++ b/core/themes/seven/css/components/dropbuttons.css
   @@ -0,0 +1,292 @@
   +
   

   please delete or add related comment

2. +++ b/core/themes/seven/css/components/dropbuttons.css
   @@ -0,0 +1,292 @@
   +
   

   please delete or add related comment

3. +++ b/core/themes/seven/css/components/dropbuttons.css
   @@ -0,0 +1,292 @@
   +     -moz-transition: all 0.1s;
   +       -o-transition: all 0.1s;
   +          transition: all 0.1s;
   

   is this indentation compliant with the coding standards?

4. +++ b/core/themes/seven/css/components/dropbuttons.css
   @@ -0,0 +1,292 @@
   +     -moz-transition: none;
   +       -o-transition: none;
   +          transition: none;
   

   is this indentation compliant with the coding standards?

Tested the patch, works fine, attached screenshots (*_before_after.png)

Almost done :-)
Needs minor modifications, related with Coding Standards compliance.

I am not sure what you mean by "please delete or add related comment" but i added a @file comment to the beginning of the new css file and removed couple empty lines where they made no sense to me according to this doc: https://drupal.org/node/1887862 Also according to this doc it seems the funky indentations are standard so i kept those.

Thanks for the tidy ups. Always good to have more eyes on code. I applied the patch and had a quick double check. Assigning to Tim to make sure his concerns have been address.

The font sizes are still affected for non-Seven themes. Clarifying the title (it's already against that component specifically).

You can see that the "View Page" dropbutton is big enough to overflow its container, and that the "Add" dropbuttons are much bigger.
Bartik before:

Bartik after:

One additional thing I noticed:

--- a/core/misc/dropbutton/dropbutton.css
+++ b/core/misc/dropbutton/dropbutton.css

--- /dev/null
+++ b/core/themes/seven/css/components/dropbuttons.css

All of the files in core are "dropbutton", singular. The new file is "dropbuttons", plural.

picking up, doing re-roll plus implementing stuff from #132.

Implementing stuff from #132. File name changed to singular, views ui font-size declaration reverted to 11px and overriden in Seven theme dropbutton.css.

Interdiffs are useful...

The problem wasn't the font-size actually.

1. +++ b/core/modules/views_ui/css/views_ui.admin.theme.css
   @@ -1116,25 +1116,24 @@ div.messages {
   +.js .dropbutton-wrapper .dropbutton .dropbutton-action > * {
   ...
   -.dropbutton li > * {
   ...
      padding: 0.2em 0.75em;
   

   Because the selector is changing, this is now overriding the 0.5em defined in dropbutton.theme.css

2. +++ b/core/modules/views_ui/css/views_ui.admin.theme.css
   @@ -1116,25 +1116,24 @@ div.messages {
   -  line-height: 1.4555;
   

   This needs to come back, the only line-height declaration is now in Seven only, so Bartik inherits a 20px line-height.

I was starting to fix things proposed in #135 when i realised that changing the filename from plural to singular (renaming dropbuttons.css to dropbutton.css) broke the whole thing. When using dropbutton.css as file name, the file does not get included into the html output. Dropbuttons at node forms for instance completely lack styling. Maybe i am just unaware of something new coolness in D8, but if i rename the file to something other than dropbutton.css and change seven.info.yml accordingly, suddenly the stylesheet gets in and node save dropbutton looks sexy again.

I am more than happy to work on it but need guidance.

The proposed filename is: dropbutton.component.css
I will rename the file and also fix other concerns from #135. Also will do my best to provide an interdiff this time ;)

Fixes concerns from #135 and renames dropbutton.css in seven theme to dropbutton.component.css.

Views UI Stark

Views UI Bartik

Views UI Seven

Setting to needs review.

I don't know if this inside the scope for this issue, but a smaller version of the Dropbuttons is missing. Inside the Views UI the buttons are too big and cause overlaps:

Apart from that: awesome Work!

Thank you for reviewing. I think it is totally inside the scope. However, i think it works well for me.

And this is a hacked version where i used the inspector to put more words in that h3 and besides the button overlapping with it (which is normal) it still looks ok to me.

Keeping on needs review.

When did the text get so big again? :(

The longer this drags on, the more I don't understand what we're gaining here.

I think it was just a misunderstanding of the feedback. We have some new contributors so let's try and be patient.

I'll take a look at this.

Sorry, i was messing around with font size because i had the suggestion in person at #drupaldevdays. I tried now and it looks like removing the font-size from dropbutton.compontent.css and setting it to 11px in views_ui.admin.theme.css is what is needed.
I assign it to me.
Sorry for messing it up.

Here we go, font-size removed from seven and set to 11px in views_ui.admin.theme.css

Thanks Aboros! I'm stuck for time today.

I checked 8.x without the patch. The overlap with the header also happens there

So it is not introduced by this patch. Not to hold things up, it should be posted as an issue for Views.
Also the questions if the buttons are too big for the views UI should probably be a followup.
There may be other places in different UIs that need fine-tuning.

Sure as long as we aren't breaking anything or making it worse then we can move other problems to another issue.