Text Block Hover states overruled by Link styles due to how CSS is generated

  • bwyrwich
    July 9, 2026 at 7:43 pm

    Bug/Logical Flaw: Text Block Hover states overruled by Link styles due to CSS Specificity

    Hi team,

    I wanted to raise a logical flaw in the CSS generated by GenerateBlocks for the Text Block.

    When a Text Block contains a link, setting a Hover or Hover & Focus color on that Text Block fails to apply because the Links state CSS has a higher precedence. The hover state is incorrectly applied to the block container rather than the anchor tag.

    Note on the “Parent Container” workaround: While setting link/hover colors on a parent Container block works for global styles, it completely breaks down if you have multiple Text Blocks in the same container that require unique, individual colors. The CSS logic should work at the individual block level.

    Steps to Reproduce the Bug

    1. Create a parent Container Block.
    2. Create two Text Blocks inside it. GenerateBlocks automatically assigns a unique class to each block. For this example, Text Block 1 is .gb-text-111111a1 and Text Block 2 is .gb-text-222222b2.
    3. Add a paragraph of text to both blocks, with one word in each set as a link.
    4. Configure Text Block 1 with these settings:
      1. Main > Typography > Text Color = Black
      2. Links > Typography > Text Color = Blue
      3. Hover > Typography > Text Color = Red
      4. Hover & Focus > Typography > Text Color = Red
    5. Configure Text Block 2 with these settings:
      1. Main > Typography > Text Color = Black
      2. Links > Typography > Text Color = Green
      3. Hover > Typography > Text Color = Purple
      4. Hover & Focus > Typography > Text Color = Purple

    The Resulting Generated CSS & Flaw

    GenerateBlocks outputs the base and link CSS correctly for Text Block 1:
    .gb-text-111111a1 { color: black; }
    .gb-text-111111a1 a { color: blue; }

    However, it generates the Hover and Hover & Focus states like this:
    .gb-text-111111a1:hover { color: red; }
    .gb-text-111111a1:is(:hover, :focus) { color: red; }

    The Flaw: Because the hover rule targets .gb-text-111111a1:hover instead of the descendant anchor .gb-text-111111a1 a:hover, the browser’s CSS precedence rules mean the specific a styling completely overrules the text block’s inherited hover color.

    As a result, unique text block link hovers never actually change color.

    Could the team please look into ensuring that Hover/Focus states for Text Blocks also correctly target descendant links when Link colors are defined?

  • Alvind
    July 9, 2026 at 8:18 pm

    Hi there,

    Thanks for the detailed report and the repro steps.

    So what’s happening here: the Hover and Hover & Focus states style the Text block itself, while Links styles the anchor inside it. You end up with:

    .gb-text-111111a1:hover {
    color: red;
}

    and

    .gb-text-111111a1 a {
    color: blue;
}

    Because the link has its own color set directly on it, it won’t inherit the red from the hovered parent. It’s really an inheritance thing rather than a specificity fight, since the two rules target different elements.
    What you want are the link-specific states in the selector menu: Hovered links and Hovered & focused links. Setting red under Hovered & focused links gives you:

    .gb-text-111111a1 a:is(:hover, :focus) {
    color: red;
}

    Your second Text block can do the same with purple, so each block keeps its own colors. No need to move anything to the parent Container. Global Styles work the same way, just give the two blocks separate global classes, each with its own Links and Hovered & focused links settings.

    On the suggestion of having the plain Hover state automatically add a descendant link-hover rule: I don’t think we’d want that. It would quietly change existing sites where links are supposed to keep their own color, and it mixes up two different interactions, hovering anywhere on the block versus hovering the link itself.

    You’re right that the current labels make this easy to miss, though. Maybe Block hover versus Hovered links, or making the link states more visible in the menu. I’ll pass that along to the team.

    Also worth noting, GeneratePress isn’t rewriting these selectors. It only provides the general theme-level link colors, so once the link-specific hover state is set on the Text block, the individual hover colors should just work.

Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.