Dropdown action list shows up as a simple list without JavaScript

Ah I get it, these should look like buttons when JS is disabled right? I think we just need to add .js in front of some of the CSS?

Here's a patch for a nicer no-js dropbutton fallback. I added .js before the background and border overrides, so those don't happen when javascript is disabled.

I also added some alignment and margin styles to align the buttons better without javascript. Any opinions on this? I'm pretty sure there's no risk of this bleeding through, but I suppose there might be a cleaner way of doing this.

Disregard the previous patch, I forgot to reset the default ul styles for the fallback (padding, margin and list-style-type). This one should work.

I tested and it looks good for the publishing buttons (the screenshot A).

I just checked how the buttons would be on a view editing page (admin/structure/views/view/content), and there are some problems with the patch (screenshot B) and without the patch (screenshot C), but I don't know if this should be added to this issue or not, because the patch #3 clearly fixes the original problem.

It seems to be a bug with disabled javascript in Views UI. The patch didn't really make the situation worse, it's just broken in a different way now.

Is there already an issue about no-js usability in Views UI? I could take a look at fixing this if no one else is currently working on it.

No, it didn't make it worse, the Views UI without JS just doesn't seem to be fixed. I think it should be fixed in another issue and consider this issue fixed with the patch #3.

No, it didn't make it worse, the Views UI without JS just doesn't seem to be fixed. I think it should be fixed in another issue and consider this issue fixed with the patch #3.

Agreed! Views UI is too complicated, we should manage it on it's own.

Just a few minor code review points:

1. +++ b/core/themes/seven/css/components/dropbutton.component.css
   @@ -25,20 +25,41 @@
   +  list-style-type:none;
   

   This requires a space before the value.

2. +++ b/core/themes/seven/css/components/dropbutton.component.css
   @@ -25,20 +25,41 @@
   +.dropbutton li {
   ...
   +.dropbutton li:first-child {
   ...
   +.js .dropbutton li {
   

   Instead of using 'li' we use the '.dropbutton-action' class. It would be nice to keep it consistent.

Actually the '.dropbutton-action' class seems to be created by JS (when JS is deactivated the dropbutton 'li's don't have it). I don't know if this is normal; so should the '.dropbutton-action' class be there only when JS is activated (and in that case we must use 'li' here and not the class), or should the class be there in all cases ?

Ok, LewisNewman told me that we can keep the 'li' as the '.dropbutton-action' class is created by JavaScript, so this patch adds only a space before the value on the 'list-style-type: none;'.

Look great on my local Mac browsers, but I tried on Android and it needs work on smaller screens where the buttons are not in a row. See screenshot.

(According to the themer sitting to my left, we should: Remove the left margin from all of these buttons and add a margin-bottom.

This patch should get things okay. It only affects layout and adds just the margin-bottom and sets margin-left to zero.

This fixes the problem. I also tested to make sure that there were no regressions to Dropbuttons with JS.

buttons should be 100% on mobiles. Patch is coming.

Looks good - screen shots for iPhone simulator, tested it for different iOS devices too.

Re-roll of #19.

+++ b/core/misc/dropbutton/dropbutton.css
@@ -24,8 +24,10 @@
-.form-actions .dropbutton-wrapper {
-  float: left; /* LTR */
+@media screen and (min-width:600px) {
+  .form-actions .dropbutton-wrapper {
+    float: left;
+  }
 }
 [dir="rtl"] .form-actions .dropbutton-wrapper {
   float: right;

We lost the LTR comment on this line, also I guess this means the selector below it also needs to be moved in to the media query?

Fixes as per #23.

Great, thanks. We just need to take some screenshots of the JS dropbuttons in all the themes to show that it's not broken by these changes.

Hello,

I am making screenshots.

I reviewed the behavior on chrome 40.0.2214.111 (64-bit) and firefox 35.0.1 on mac, on the needed screens. I tested on a local machine and simplytest.me (I verified on both, but screenshots are only for my local environment):

/admin/content
Seven

Classy

Bartik

/node/add/article
Seven

Classy

Bartik

/admin/structure/views/view/content
Seven

Classy

Bartik

Looks all good in D8 8.0.x already. Attached couple of shots.

This should also help #2412945: Determine which additional asset libraries should be in the critical path/loaded i/t header (core/drupal, core/dropbutton)! :)

CSS changes are not frozen in beta. Committed 71a987d and pushed to 8.0.x. Thanks!

This issue introduced a visual regression in the dropbutton for users with javascript enabled. I have opened #2430999: Visual regression in dropbutton to fix this.