Remove legacy browser support from js.module.css

Seems pretty straight forward.

Committed f9be36f and pushed to 11.x. Thanks!

This seems to have broken/started showing some buttons that need to be hidden in the Views wizard:

Should open a follow up or is this a revert and fix?

reverted for now, thanks for finding the issue!

Not confident enough in my css skills to mark RTBC, but checked, and it fixes the issue in the Views wizard at least

The views wizard issue is fixed, but the change in MR 11855 causes a regression from #3404218: Table filter creates jank (layout shift) on page load. The filter is popping in again on /admin/modules when I use Chrome inspector to disable cache and throttle to 3G. This doesn't happen on HEAD.

Screen recording is attached.

Manually tested both the views wizard and modules filter and they both look good now. I'm slightly concerned about the use of !important, but I'm not familiar enough with what's going on there to offer any alternatives w/r/t specificity. +1 for RTBC if others are good with the !important.

To overcome some experience builder past bugs, we would add an attribute to increase the specificity.
Say.

.js-show[class] {
    display: block;
  }

https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors
That could make it more specific than Claro and avoid using !important

Before this fix, without the !important

After the fix with [class]

Looking back at comments from #3404218: Table filter creates jank (layout shift) on page load:

Original patch in #2 had this:

@media (scripting: enabled) {
  /* Extra specificity to override previous selector. */
  [class] .js-hide {
    display: none;
  }

  .js-show {
    display: block;
  }
}

Suggestion was made for this instead in #8:

Why not .js-hide.js-hide like we do usually when we need to increase specificity?

Both are valid solutions, but DrupalCMS is leaning more on attributes [class].
https://git.drupalcode.org/project/drupal_cms/-/merge_requests/374/diffs...
So I would say preference leans towards class attributes.

From the IS, the goal is to remove the additional classes in the selectors since @media (scripting: enabled) is well supported. In which case, seems to me that the selectors within the media query should work well enough as is (and I've just tested to confirm), and the only thing needed is to remove the rules outside the media query.

That reduces the diff size, and the use of .{CLASS}.{SAMECLASS} selectors is used often in core, so I think that part can be left as is.

I have to say, this one in media-library.pcss.css is pretty amusing:
.media-library-item .ajax-progress.ajax-progress.ajax-progress

The .js-hide[class] approach seems like the most concise, specific option without using !important, and I'm also in favor of it. However, that approach would select .js-hide with any other class, not just its duplicate, but I'm not sure how much of a problem that is if it's working for Drupal CMS.

I think this is a good example of when we would use !important.

In this instance, it's !important that when the class .js-hide is present that the item concerned is hidden.

Perhaps we can use !important just for the hiding part and not for the showing part. For .js-show we may not want display: block all the time (sometimes we might want flex/grid/inline-block/etc) so !important should not be used for that.

After that I think @godotislate "double class" idea is probably best. .js-hide.js-hide. If we use .js-hide[class] it might affect other classes if they are present.

Sorry to be that guy, since this did cause an issue before can we update the summary fully. Tried to get it started.

I think this is technically supposed to be needs review.

I don't see any layout shift due to Filter shows a little late. I followed the steps as per IS
Attaching screen capture

I like the approach in #35, as its forward thinking. That being said, the media scripting functionality is still relatively new (MQ Level 5) adopted in modern browsers around 2023. Checking caniuse media scripting shows we meet the "Baseline" at around 89% of global browsers. But for the other 11%, the way the MR is written might have a regression. On browsers that don't support media scripting, both media query blocks get ignored/dropped, and .js-show becomes visible by default. (i.e., "assume old browsers have JS enabled") Is this intentional?

Also, I can't make sense of the test failure, or why we have a test like this:

Asserting StylesheetBytes 979 is greater or equal to 1000 and is smaller or equal to 2000
Failed asserting that 979 ( is equal to 1000 or is greater than 1000 ) and ( is equal to 2000 or is less than 2000 ).

Nice. I wanted to check the tugboat preview environment, but it is marked failed. I tried a rebuild which also failed.

Tested MR 14393 locally, and it fails the regression test per #10. This is on MacOS Tahoe Chrome 143.0.7499.193. The buttons do not appear when I test on main.

Latest commit fixes the View wizard, and there's no regression on the module filter in the IS. Though it seems we've circled back to whether .js-hide.js-hide (existing Drupal core convention) vs .js-hide[class] (new Drupal CMS convention? see #20) is preferred.

Normally, I would never argue for the use of !important, but .js-hide/.js-show cascade warfare seems different than other places.

The cascade problems arise when we're doing things like display:block but we want that element to have (for example) display: flex and have to resort to CSS specificity hacks.

But the refactor from catch has cleverly allowed us to removed all display: block instances.

ISTM that now that .js-hide/.js-show is used exclusively for hiding content in certain scenarios, it should take precedence over everything else and therefore display: none !important could be safe to use here, no? What am I missing?

I think we're just back at the outstanding "Needs frontend framework manager review".

@catch I know I mentioned in #15 above that !important seems right here, but often we want to change something from display: none; to display: flex; (or grid, etc) (rather than block), and that !important could come back to bite us.

I'm not saying we should not do it, but just wanted to raise it as a consideration.

No strong opinion either way, but note: this MR removes all display: block usage and standardizes on display: none (optionally reinforced with !important). This is so that now, out of the box, display: flex (or grid or block) applied to a div that has js-show will Just Work ™ as you intended!

If on the other hand someone wants to (for whatever crazy reason) explicitly do the inverse of what is coded (i.e. show something marked as js-hide when JS is enabled, or hide something marked as js-show when JS is disabled), the correct approach is to either A) swap js-hide with js-show and vice-versa or B) remove the js-hide/js-show utility class and replace it with your own class and styles. (I hope this makes sense to everyone, it boils down to logic tied to classnames matching display intent).

Using display: flex !important to override those utilities works, but it’s effectively opting out via a specificity hack, so the burden is intentionally on the developer when going against the pattern.

Without !important reinforcement in the MR, the minor risk is that if something is coded with high specificity eg :root .mything { display: flex } the js-hide/js-show logic will never take effect.

Edit: updated my comment for clarity. 2026/4/1

Haven't been able to get ahold of a frontend manager. Not sure how to best move this one forward.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

In that case think it’s good to go.

+1 from me, !important is made for this kind of things.

Committed and pushed b7156dd to main and 5b74413 to 11.x. Thanks!

Should this go to 11.3.x? Moving to Patch to be ported in case we want it.

This has caused a regression in the paragraphs module when a modal dialog is used to add new paragraphs.As this is a task I propose that we revert this change from 11.x, 11.4.x and main and try again.

I've prepped an MR against 11.x that also applies cleanly to 11.4.x to revert this.

I can confirm that paragraphs is now not broken anymore