Needs work
Project:
Drupal core
Version:
main
Component:
javascript
Priority:
Major
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
25 Jan 2015 at 15:39 UTC
Updated:
13 Jun 2024 at 18:08 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #1
manuel garcia commentedThis looks to be a bit more work than we had initially had thought, but we should be able to work through it.
Attached the result of $ grep -r --include="*.css" ".js " . (inside core directory).
Most of the results are for dropbutton, or dropbutton related.
My suggestion is for dropbutton js to add its own
dropbutton-activeclass to all elements it affects, and then change the CSS selectors based on that.The rest of the files are:
Comment #2
manuel garcia commentedLet me correct myself... dropbutton already adds an activation class,
dropbutton-processed.Comment #3
manuel garcia commentedComment #4
manuel garcia commentedModernizr will still add a
jsclass to the<html>element.Here is some progress, I have worked on the changes for dropbutton only, tested this on the views admin page and on node/add/article.
Still to do:
Comment #5
damien tournoud commentedThis class is there for a reason, to avoid flashing on the rendering of JS-based components. The only thing that needs to be in the header is the setting of this class. Setting this in the head will trigger layout invalidation, but given that there has been nothing to layout at that point, I don't see why it would hurt.
Comment #6
fabianx commentedAnd I think we could seriously do this as inline-JS so that we don't need to load any file just for that part in the header.
Comment #7
damien tournoud commented@Fabianx: absolutely, setting the class with a simple inline JS would be perfectly fine.
Comment #8
joelpittetComment #9
prashant.cLast submitted path failed applying.
Submitting new patch after replacing all the instances of .js class.
Comment #10
prashant.cComment #12
Jeff Burnz commentedAFAICT inline JS is out if we want to allow Drupal to be CSP compliant, that said I don't see the point to removing this, I still use js/no-js classes for various things, although it is true I tend to add/remove more specific classes with JS for my fallback styles. I would agree with catch's characterisation of this being "vestigial", just not sure we're ready to let go just yet, so agree with #5.
Comment #13
krishnan.n commentedApplied patch:
- Checked a few of the buttons, drop-down, blocks, and other places where .js was removed, looks fine.
- appears to be present in a couple of more files
core$ grep -r "^.js " *
modules/color/css/color.admin.css:.js .color-preview {
modules/locale/css/locale.admin.css:.js .locale-translation-update__wrapper {
themes/stable/css/system/system.maintenance.css:.js #edit-submit-connection {
themes/stable/css/system/system.maintenance.css:.js #edit-submit-process {
Comment #14
krishnan.n commentedApplying this patch breaks the "save and publish" button on create page: content -> add content -> basic page. Please see attached image. NB: tend to agree with #5, #12
Comment #15
Jeff Burnz commented#9 I just noticed my previous comment removed your patch and changed the status, this was not intentional at all. I don't know why that happened. My apologies.
Comment #16
xxAlHixx commentedI've applied patch remove-js-css-class-2413847-9.patch and can confirm that issue with "save and publish" from #14 exists and in Views UI issue with Operations buttons appear too.
Comment #17
andypostComment #18
joelpittetThough there is a problem with the last patch busting the RTL
Dropped the language prefix on a lot of these.
Comment #19
andriyun commentedPatch #9 is applicable to 8.1.x branch.
Comment #29
ramya balasubramanian commentedComment #30
ramya balasubramanian commentedHi @andriyun,
According to #13, some files are missing and it is affecting some 'Save&Publish' button and dropdown buttons. Before continuing this ticket, please let me know whether we need to exclude the 'Save and Dropdown' button designs.
Comment #31
ramya balasubramanian commentedComment #38
gauravvvv commentedI have attached patch for 11.x, please review
Also the issue reported in #16 & 14 are no longer reproducible with this patch. thanks
Comment #39
gauravvvv commentedFixed the build errors.
Comment #40
smustgrave commentedThink there's some BC to consider before just fully removing no?
Comment #43
yash.rode commentedConverted to MR ^ As patch testing will be stopped form 1st july.
Comment #44
catchThe MR is only removing usages of the class, not the class itself, so there is no bc issue with the current MR. I think we could keep this issue to remove usages and open a second issue to stop adding the class.
I do think we need some kind of bc layer here because CSS written to use the js class will just stop working without it.
The class is set in:
drupal.init.js
document.documentElement.className += ' js';One possibility for bc would be to add a new module to core, which does exactly this via altering a js file into the core library definition, enable that module by default in a post update, but have it uninstalled for new sites (or sites that uninstall it). We could then deprecate that module in Drupal 11 and make it obsolete in Drupal 12. Just writing that out makes me think two issues would make this easier to get done rather than trying to tackle both here.
Comment #45
smustgrave commentedSounds like a good plan, updated issue summary
Comment #46
catch@smustgrave in #44 I was suggesting to do that plan in a new issue, not in this one because I think it'll be a bit complex to attempt both. I've opened #3453951: Deprecate setting the .js class in core in preparation for removal and adjusted the issue summary.
Comment #47
smustgrave commentedOh I had read it that maybe it could be included here but cool.
So in regards to this ticket of removing, did a search for .js in css files and found more instances
Comment #48
smustgrave commentedComment #49
mithun sCurrently looking into this.
Comment #50
mithun sRemoved the pending .js class from the css files and added a commit. Please review.
Comment #51
berdirI'm very confused about this change. See my MR comment, js might not be used much directly, but the js-show and js-hide classes have 10+ usages in core alone and the proposed change completely breaks the functionality of that.
Comment #52
smustgrave commentedHow come issue summary was removed?
Comment #53
andypostComment #54
catch.js-show and .js-hide should not be included here.
Those are now implemented without having to execute or load any JavaScript at all:
from <code>core/modules/system/css/components/js.module.cssi.e. we have a CSS-only implementation for
.js-showand .js-hide, the.jsclass is only added so that.js .js-hideworks, which is not necessary with the media query.So this issue should be about removing the JavaScript implementation and the .js class, leaving the CSS-only implementation intact.
Comment #55
smustgrave commentedHiding patches for clarity.
I'm not seeing the removal of js-hide or js-show in the MR?
Comment #56
catch@smustgrave it's https://git.drupalcode.org/project/drupal/-/merge_requests/8370/diffs#e8... as pointed out by @berdir in the MR
That is the thing that makes .js-hide work on browsers that don't support
@media (scripting: enabled), which used to be all of them when it was added, but is not necessary now (except there are a couple of 'unknowns' on https://caniuse.com/?search=media%20scripting%3A)This file should have been the only ever usage of the class in core or anywhere else, because the whole point of it is to make .js-hide and .js-show work, not for styling things independently of those, but it's clear that usages have crept in over time.
That CSS would need to be handled in #3453951: Deprecate setting the .js class in core in preparation for removal but should be left here.