Generated with the help of an LLM.

Problem/Motivation

Rivet 1.2.1 changes rivet_css_alter() so that the assets from the rivet/core library are assigned to the CSS_BASE group:

$css[$asset['data']]['group'] = CSS_BASE;

CSS_BASE is a CSS category weight, not an aggregate group. Its value is -200, so assigning it to group moves Rivet Core ahead of Drupal's group-0 CSS, including Normalize.

This reverses the intended cascade. For example, Rivet Core defines the desktop header menu as visible:

.rvt-header-menu {
  display: flex;
}

Drupal's Normalize stylesheet then loads after Rivet Core and applies:

[hidden] {
  display: none;
}

Because both selectors have the same specificity, the later Normalize rule wins. Header menus that use Rivet's responsive hidden behavior remain hidden at desktop widths even though their blocks and markup are present in the DOM.

The regression was introduced by the Rivet 1.2.1 change for issue #3636602. The hook is still needed because Drupal core currently assigns theme CSS to the theme aggregate group, as described in #3046636: LibraryDiscoveryParser overwrites theme CSS group ordering. The problem is the aggregate group selected by the hook.

Steps to reproduce

  1. Install Drupal 11.4.x and Rivet 1.2.1.
  2. Use Rivet, or a Rivet subtheme, as the default theme.
  3. Place a menu block in a Rivet header region so that it is rendered inside an element with the rvt-header-menu class and hidden attribute.
  4. View the page at a desktop viewport width.
  5. Observe that the menu remains hidden even though the desktop Rivet media query should display it.
  6. Inspect the resolved CSS order. Rivet Core loads before core/assets/vendor/normalize-css/normalize.css.

Expected result: Rivet Core loads after Drupal's base/Normalize CSS. At desktop widths, the Rivet header rule wins and the menu is displayed.

Actual result: Drupal Normalize loads after Rivet Core. Its [hidden] rule wins and the desktop header menu remains hidden.

Proposed resolution

Put Rivet Core in CSS_AGGREGATE_DEFAULT group instead of incorrect use of CSS_BASE category constant, which should not be used as a group.

Preserve the asset weights supplied by the rivet/core library. This produces the intended order:

  1. Drupal Normalize
  2. Rivet Core
  3. Drupal component CSS
  4. Rivet compatibility and subtheme CSS

Add a functional regression test that attaches core/normalize, rivet/core, system/base, and rivet/base, then verifies both the Rivet Core aggregate group and the resulting asset order.

A first-pass Composer patch using this change has been validated on a Drupal 11.4.x site with Rivet 1.2.1. The missing desktop header menus are restored, while the responsive menu remains hidden until opened at mobile widths.

Remaining tasks

  • [x] Reproduce and identify the CSS ordering regression
  • [x] Validate the proposed aggregate-group change on a consuming site
  • [ ] Create a merge request
  • [ ] Add and run upstream functional regression coverage
  • [ ] Review and merge

User interface changes

Restores Rivet header menus that incorrectly remain hidden at desktop viewport widths.

API changes

None.

Data model changes

None.

Issue fork rivet-3636973

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

jwilson3 created an issue. See original summary.

  • jwilson3 committed e2871457 on 1.2.x
    Issue #3636973 by jwilson3: Fix Rivet CSS cascade order
    
jwilson3’s picture

Assigned: jwilson3 » Unassigned
Status: Active » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.