Remove JavaScript detection using class names

[knowler]

This PR took a bit of a turn. Originally, it moved existing JavaScript detection from the body to the html element as well as the code to do that to the index.php file. After some feedback and further research, I began to question the necessity of the JavaScript detection in the first place. I struggled to find websites that actually used JavaScript detection with a class name on html or body and when they did there was no code on the site that actually used the class name for any non-JS or enhanced effect.

I’m convinced that this method has lost favour to progressive enhancement methods which emphasize writing styles that work for HTML out of the box. In these methods, increased specificity (e.g. the targeting the presence of attributes) is used to style components when they are enhanced with JavaScript. An example of this in practice might be web components that dynamically import and adopt their stylesheet upon registration. The philosophy here is to allow browsers that want to work less, to do so instead of working more (e.g. writing .no-js styles that override fully enhanced component styles).

[knowler]

I have not tested this. The only thing I think which could go wrong is maybe needing to add WordPress’ dom-ready to the deps array for the editor script. I don’t know where that is though.

Also, adding the no-js removal inline script in index.php might be non-standard (as opposed to using wp_head), but I figure it’s close to where the class name is set on the element and therefore easier to see what it’s doing.

[knowler]

Ok, I’ve tested this and it works. There’s no need to add any deps for the editor script since wp-dom-ready is in the window. I also just added a js class after the no-js one gets removed. Might be helpful and its in the link I referenced in the PR description. Not sure why PHP 7.3 is failing, but I think it was like that before.

[retlehs]

could we keep a domReady example or starting point in app.js?

[retlehs]

Not sure why PHP 7.3 is failing, but I think it was like that before.

latest acorn release is triggering those failures rn, you can ignore (we're gonna just remove php 7.3 support)

[knowler]

could we keep a domReady example or starting point in app.js?

We can do that. We would need to add our domReady script back though.

[Log1x]

We can do that. We would need to add our domReady script back though.

I vote we add it back and keep it how it was outside of moving no-js to the html element.

[knowler]

I added it back. Should we add it back to editor.js too? Or is using @wordpress/dom-ready there fine (since it’s already available in the admin).

[knowler]

I changed directions here:

• This now removes the JS detection (see updated PR description for reasoning).
• It doesn’t change anything with the domReady stuff like it originally did.