Table filter creates jank (layout shift) on page load

@mherchel is there an additional step? I'm on Version 119.0.6045.159 (Official Build) (arm64) and applying the patch I'm not noticing any difference on the page load

@mherchel is there an additional step? I'm on Version 119.0.6045.159 (Official Build) (arm64) and applying the patch I'm not noticing any difference on the page load

Ha! You're just like me and skipped over part of the testing steps (I do this all the time). Here's the part that you missed 🤣🤣🤣

Note that the at-media feature is not supported in the latest version of Chrome (119). It is supported in the next version of Chrome (120), Safari 17, and Firefox. So, if you're testing on Chrome, please verify that you're on 120 or later (you can use Chrome Canary if you'd like).

Tested on firefox and see what you mean now.

Wonder if a meta should be opened for other locations this could be used?

Great minds think alike :D
🌱 META: Reduce / eliminate “jank” (layout shifts) within Drupal’s admin UI Active

1. +++ b/core/modules/system/css/components/js.module.css
   @@ -20,3 +20,17 @@
   +  [class] .js-hide {
   

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

2. +++ b/core/modules/system/css/components/js.module.css
   @@ -20,3 +20,17 @@
   +  .js-show {
   

   Shouldn't we add the extra specificity here too?

HI lauriii,

I tried to changes as per your comment, kindly review.

Thanks!

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

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

No specific reason. Attribute has the same specificity as a class, so 🤷‍♂️. Not sure if there's a preference.

Shouldn't we add the extra specificity here too?

Nope. We don't need it. The extra specificity is only for when JS is enabled, and therefore the current (previous) ruleset works file. We only need to take into account for situations where JavaScript is enabled but the .js class is not yet present.

Ah, you're right @mherchel! I fixed it.

Restoring status.

Safari 17 is quite a high bar given Apple ties it to specific OS updates (it's the new IE). Any interest in a fallback technique with broader browser support?

lauriii → closed merge request !5587

Not sure it's worth using too much time trying to invent another solution for this since it's a perceived performance improvement for a problem that has existed for years in Drupal. If you are interested in that and want to propose something, I think it would be fine to do so in the meta issue.

Committed 3ad9ff9 and pushed to 11.x. Also cherry-picked to 10.2.x. Thanks!

Fair enough. No on second thought it's a problem that will go away eventually by itself with these fixes in.

Automatically closed - issue fixed for 2 weeks with no activity.

Follow-up 📌 Simplify js.module.css Active .