Reduce the dependency on JavaScript for the toolbar to display properly

The one thing I will ask you all to consider is that much of the redundant CSS is there to give sensible styling to IE8, since it doesn't understand media queries. It was written before be had modernizr in core, so perhaps we could eliminate much of it by adding a few feature tests and keying the CSS off those classes.

Maybe we could do something with CSS :target and anchor tags to do the show/hide of the trays?

Oh, and the "sensible styling" for IE8 has been torn to shreds by bit rot. The non-js version should probably just be the IE8 version as well for what it's worth.

Sorry for the long absence here. We've finally gotten through the bulk of issues with in-place edit and this has popped to the top of my queue again.

Thank you everyone for that patches this far. Here are a few comments.

+++ b/core/modules/toolbar/css/toolbar.base.cssundefined
@@ -225,3 +213,61 @@ html.js .toolbar {
+
+/** ¶
+ * If toolbar was not processed, show
+ * first tray on tab hover and hide elements
+ * that don't work, like buttons.
+ */
+html:not(.js) .tray,
+html:not(.js) .tray.vertical {
+  top: 0;
+  display: block;
+  width: 35px;
+  height: 39px;
+  opacity: 0;
+  border: none;
+  -webkit-transition: opacity 0.25s;
+  -moz-transition: opacity 0.25s;
+  -ms-transition: opacity 0.25s;
+  -o-transition: opacity 0.25s;
+  transition: opacity 0.25s;
+}
+html:not(.js) .tray:after {
+  content: '';
+  border-color: transparent transparent #fff transparent;
+  border-style: solid;
+  border-width: 5px;
+  display: block;
+  position: absolute;
+  bottom: 0;
+  left: 50%;
+  margin-left: -5px;
+}
+html:not(.js) .tray .lining {
+  position: fixed;
+  top: 0;
+  left: 0;
+  overflow: hidden;
+  margin-top: 39px;
+  width: 100%;
+  height: 0;
+}
+html:not(.js) .tray li {
+  float:left;
+}
+html:not(.js) .tray:hover {
+  opacity: 1;
+}
+html:not(.js) .tray:hover .lining {
+  height: auto;
+}
+html:not(.js) .tray li button,
+html:not(.js) .tray .toggle-orientation,
+html:not(.js) .tray:hover ~ .tray {
+  display:none;
+}
+html:not(.js) #toolbar-tray {     left: 97px; }
+html:not(.js) #toolbar-tray--2 {  left: 189px;}
+html:not(.js) #toolbar-tray--3 {  left: 310px;}

I wish we could use :not(), but it is not supported by IE8.

http://caniuse.com/#search=%3Anot

For this issue, the primary purpose of support a no-js presentation is to at least make the experience on IE8 and its ilk acceptable. We do this so that if the JavaScript evolves past IE8's abilities, we won't have broken the experience for the unfortunates who are still stuck with Internet Exploder.

Also, we can't target the trays by their machine-generated IDs, e.g. #toolbar-tray--2 because these values are not stable. They are used by the JavaScript and the association between tab and tray is made automatically.

updated patch

I'm taking the approach that we don't need to provide the full toolbar experience of trays to a non-js UI. We're approaching D8 from the perspective of progressive enhancement, not complete feature fidelity even in User Agents that don't provide basic feature support. Without the trays, when a user clicks on the Menu tab or the Shortcuts tab, they are taken to the page for this menu item. That is perfectly acceptable. This is why those elements are anchor tags instead of buttons. Sure, it's more clicking. But more clicking is what you get when JavaScript is turned off. JavaScript enhances the experience. It makes things faster and more efficient.

So I've hidden the trays by default. They stay hidden without JavaScript. The top bar is available and its position remains static. A user can click Admin and get to the /admin path. All of the admin links are available from there. The same is true for the Shortcut and User tabs.

I was able to remove all of the .js class scoping declarations.

Positioning of the toolbar must be static without JavaScript, because we use JS to determine how far to pad the top of the body from the top to accomodate the visual space that the toolbar consumes. A position of fixed or absolute pulls the toolbar out of the document flow, so we need JS to calculate its height and adjust the page contents placement.

I coded and tested with the following combos in mind:

no-JS/no-MediaQuery - IE8 without the ie8 module

In this case, the user simply sees the black administration bar, there are no trays. Menu items are found by following the admin menu tree.

no-JS/MediaQuery - Chrome with JS disabled

In this case, the user simply sees the black administration bar, there are no trays. Menu items are found by following the admin menu tree.

JS/no-MediaQuery - IE8 with the ie8 module

In this case, the user simply sees the black administration bar, there are no trays. Menu items are found by following the admin menu tree.

JS/MediaQuery - Chrome

Only when JS is enabled and media queries are supported does the user get access to the the full flexibility of the toolbar layout and positioning. In order to reduce the subtle complexities between JavaScript and CSS, the CSS is now driven from classes added to the page by the toolbar JavaScript. The JavaScript is driven from event handlers bound to window.matchMedia checks fed by breakpoint configurations. So now, the placement of the breakpoints can be adjusted t through configuration rather than overriding CSS.

I was able to greatly reduce the size and complexity of toolbar.module.css. Although I had to add some JavaScript, those changes will be incorporated into the patch posted by droplet in #1860434-39: Refactor the Toolbar JavaScript to use Backbone; fix several poorly functioning behaviors. I will rerolling that patch after this one, based on this one.

Rerolled because of #2015789-71: Remove language_css_alter() (RTL stylesheets) in favor of HTML 'dir' attribute.

@georgestephanis, that's a legit point in #25, but it's not germane to this issue. I'd leave a comment in #2015789: Remove language_css_alter() (RTL stylesheets) in favor of HTML 'dir' attribute.

What we want to test in this issue is that the toolbar works in the following scenarios:

• no-js/no-media-query - IE8, JavaScript disabled
• js/no-media-query - IE8, js
• no-js/media-query - Chrome, JavaScript disabled
• js/media-query - Chrome

And in each of those 4 states, that the toolbar displays well in the following viewport size ranges:

• narrow - single column, no overlap with content, menu scrolls with page
• standard - horizontal bar, vertical tray, both scroll with content
• wide - horizontal bar, horizontal tray, both are fixed to the viewport; horizontal bar, vertical tray, both are fixed to the viewport, tray scrolls internally.

@ekl1773 noted that the toolbar break in IE8- without JavaScript. Further investigation revealed that this is because the HTMLShiv isn't loaded with JS, so the <nav> around the toolbar is prematurely closed by IE. Not much we can do about this, since a lot of stuff in our themes break without the shiv. I don't consider this an issue. Ancient browser? No JavaScript? Ya, the internet is going to look broken. Note, this is just the experience for authenticated users with permission to use the toolbar on IE8- with JavaScript turned off. It's still usable, just not pretty.

Without JS on IE8-, using a div element instead of a nav element

Without JS on IE8-, using a nav element instead of a div element

We're not going to sacrifice semantic HTML for this extreme and fading corner case.

This issue is a dependency for:

#1938044: Prefix all toolbar classes to prevent theme clashes
#1860434: Refactor the Toolbar JavaScript to use Backbone; fix several poorly functioning behaviors

a little grammar fix

Rerolled on current HEAD (e0f675f3b24735df93b03a6983aa7cfc23235322)

No code was changed in this patch. There were many conflict with the change from [dir=rtl] to [dir="rtl"]. This can be set back to RTBC once it comes back green. See #33.

This was committed: 1cb65032844cb12907ed484e3c17ded1528ea44f

Updated the dependent patches in the chain above this one.

#1938044: Prefix all toolbar classes to prevent theme clashes
#1860434: Refactor the Toolbar JavaScript to use Backbone; fix several poorly functioning behaviors