• Resolved enthousiastwpuser

    (@enthousiastwpuser)


    Hello,

    We found out that this CSS coming from plugin is causing issue:
    .tablepress>.row-hover>tr:has(+.child:hover)>,.tablepress>.row-hover>tr:hover+:where(.child)>,.tablepress>.row-hover>tr:where(:not(.dtrg-group)):hover>* { background-color: var(--hover-bg-color); color: var(--hover-text-color) }

    It’s causing multiple warning in console in combination with a infinite slider:

    When we comment out this line there is no more issue and the slider isn’t stuttering anymore.

    Any way to fix that internally?

    Is it because of the :has selector?

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Tobias Bäthge

    (@tobiasbg)

    Hi!

    Thanks for your post and sorry for the trouble!

    Unfortunately, your post doesn’t show the warnings, nor do you describe what exactly is the issue with your slider.

    Also, I can’t see what should be wrong with that CSS and it has been working totally fine for many users, for years.

    And, please also test with other browsers and include details about the browser that shows this warning. Thanks!

    Best wishes,
    Tobias

    Thread Starter enthousiastwpuser

    (@enthousiastwpuser)

    Hi @tobiasbg

    Thanks for responding. Let me clarify the issue with more technical detail.

    The warning: The browser console shows [Violation] Forced reflow while executing JavaScript or [Violation] 'requestAnimationFrame' handler took Xms warnings — these appear when style recalculations block the main thread for too long.

    The specific CSS causing it:

    .tablepress>.row-hover>tr:has(+.child:hover)>*

    Why it’s problematic in certain contexts:

    The CSS is syntactically valid, but the combination of :has() with :hover creates a performance-sensitive selector. Here’s why:

    1. :has() is a “live” relational selector — the browser must continuously re-evaluate whether the condition (+ .child:hover) is true
    2. :hover state changes frequently, especially when the mouse moves near animated elements
    3. When an infinite/continuously-animating slider is on the same page, DOM mutations happen constantly
    4. Each DOM change + hover event forces the browser to recalculate styles for all matching .tablepress>.row-hover>tr elements

    This creates a cascade of style recalculations that can exceed the browser’s 50ms threshold, triggering violations and visible stuttering.

    Why most users don’t see this:

    The issue only manifests when both conditions are present:

    • TablePress with row-hover feature active
    • An infinite slider or heavily animated content on the same page

    Without both, the recalculation cost stays within acceptable limits.

    Browser: Chrome 131 (Chromium-based browsers are most vocal about these violations in the console)

    Possible solutions:

    1. Use content-visibility or contain properties to limit recalculation scope
    2. Consider a JS-based hover approach with debouncing for the child-row highlighting specifically
    3. Add a class to disable the :has() hover effect on pages with known animation conflicts

    Happy to provide a screen recording if that helps demonstrate the stuttering.

    Best regards

    Plugin Author Tobias Bäthge

    (@tobiasbg)

    Hi @enthousiastwpuser,

    Got it! Thanks a lot for this detailed and very helpful explanation! I understand what’s going on!

    The idea of that CSS snippet is to improve the hover highlighting in child rows e.g. when the “Collapse” mode is used — but yeah, but what you describe is a drawback that should be solved.

    I’ll look into finding better options for a future version here!

    In the meantime, I recommend that you turn off the “Row Hover Highlighting” checkbox on the “Edit” screen of your table, and maybe re-add that effect with simpler CSS, like just

    .tablepress-custom-row-hover > tbody > tr:hover > * {
    background-color: var(--hover-bg-color);
    color: var(--hover-text-color);
    }

    and tablepress-custom-row-hover added to the “Extra CSS classes” field on the table’s “Edit” screen.

    Best wishes,
    Tobias

    Plugin Author Tobias Bäthge

    (@tobiasbg)

    Hi @enthousiastwpuser,

    Quick update here 🙂

    Today, we released TablePress 3.2.6, which uses the CSS content-visibility property on table rows, to hopefully mitigate this problem.

    Best wishes,
    Tobias

    Thread Starter enthousiastwpuser

    (@enthousiastwpuser)

    Hi @tobiasbg,

    Sorry I didn’t see your messages earlier. I just saw an update, and after checking the changelog, I came back here and found your messages. So, by just updating to the latest version without doing anything else, it should resolve the issue, right?

    Plugin Author Tobias Bäthge

    (@tobiasbg)

    Hi,

    That’s what I hope, so if you could test again with the latest version TablePress 3.2.6, that would be great 🙂

    Best wishes,
    Tobias

Viewing 6 replies - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.