From #784626-176: Default all JS to the footer, allow asset libraries to force their JS to the header:

+++ b/core/core.libraries.yml
@@ -43,11 +43,14 @@ domready:
+  header: true

Let's take the drupal and dropbutton hunks out of the patch and open a follow-up to discuss.

This is that follow-up issue.

Files: 
CommentFileSizeAuthor
#13 views-admin-nojs.png42.25 KBManuel Garcia

Comments

attiks’s picture

Post my comment here and not in #784626: Default all JS to the footer, allow asset libraries to force their JS to the header

#177Does this also means it will be outputted on every request?

document.documentElement.className += ' js'; only has to be in the head if a theme uses the js class, any idea if a lot of themes are doing it?

Wim Leers’s picture

catch and I discussed the merits of the .js class being set on the <html> tag by core/drupal (drupal.js).

WimLeers: grep for ".js " in all CSS files. Actually quite a lot of things are using this. Notably: dropbutton.
WimLeers: Actually, 90% is dropbutton, 10% is legacy leftovers
WimLeers: catch: dropbutton is a complex beast. I can only hope the reasoning for this .js selector stuff is doc'd.
catch: WimLeers: this pushes me towards footer for both.
catch: 'cos I don't think either of these have a good reason to be in the header.
catch: and removal of "js" class on <html>?
catch: And they'll encourage bad behaviour.
WimLeers: Hrm, but Jesse sometimes prefers overly specific selectors to be safe. I'll ping her to see if she remembers.

So I pinged Jesse Beach, who helped finalize the dropbutton in its current implementation, to ask about its reliance on the .js class in its selectors. Turns out there's likely no good reason for its reliance on the .js class, it's probably only there due to its Views legacy: https://twitter.com/wimleers/status/558614234851196928

Wim Leers’s picture

document.documentElement.className += ' js'; only has to be in the head if a theme uses the js class, any idea if a lot of themes are doing it?

Well, any Drupal 8 theme that relies on this will be broken for anonymous users anyway then, since no JS is loaded for anonymous users by default. Themes could opt in to this by having their main global styling asset library declare a dependency on core/drupal.
In other words: I think this is a non-issue :)

attiks’s picture

#3 I just saw your tweet, good to know

attiks’s picture

What about html5shiv, looks like it gets attached by Drupal\Core\Render\Elelemt\Html?

Wim Leers’s picture

Yes, html5shiv is loaded on all pages. But it's wrapped in browser comments, which means it's only executed for IE <=8. So, effectively, for 99% of browsers, no JS is loaded for anonymous users.

attiks’s picture

attiks’s picture

#6Thanks, maybe we should add a comment saying so, because it was not really clear to me.

Wim Leers’s picture

#8: where do you want me to add that comment? :)

attiks’s picture

#9Good question, I guess in the HTML class?

Wim Leers’s picture

#10: why does that need to be documented additionally? Anybody looking at the output sees this, and if you look at the corresponding library definition in core.libraries.yml, it's also clear. I don't see what we gain by also commenting on \Drupal\Core\Render\Element\Html? Feel free to propose a patch though, but it feels like that belongs in #2409083: Remove html5shiv from being loaded, it's definitely off-topic in this issue.

attiks’s picture

##1 You're right, way off topic and I should have looked at libraries.yml as well

Manuel Garcia’s picture

FileSize
42.25 KB

I can't think of a reason why we'd want to put dropbutton on the header.

I'll take as an example the views administration page, which has quite a few:

The page is perfectly functional for the little time the user would see the page without dropbutton being executed:
views admin page before js executes

Also, once dropbutton's js has been downloaded once and the browser has it cached, the impact of having this on the bottom of the page is absolutely minimal, and barely perceivable by the human eye.

Wim Leers’s picture

Manuel Garcia’s picture

Issue tags: +JavaScript

I think we should get rid of the .js CSS class, core should not be triggering CSSOM & layout invalidation on every page load by default. If we currently depend on this for something, let me know because I'm sure we can find a better way to deal with it.

For themes that for some reason need that class, they can add it themselves, it's a trivial thing to do.

catch’s picture

Manuel Garcia’s picture

There is one thing we did not think about, and that is that modernizr adds a js class, and a no-touch class to the <html> element as well... :\

Fabianx’s picture

We could execute this small JS snippet for JS class as inline JS ... /me ducks, hides and runs ...

Wim Leers’s picture

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.