Skip to content

.pr_agent_accepted_suggestions

qodo-merge-bot edited this page Mar 13, 2026 · 2 revisions
                     PR 599 (2026-03-13)                    
[correctness] Non-unique dropdown IDs
Non-unique dropdown IDs `_s-cms-nav.hbs` hard-codes IDs (e.g., `nav-link-1`, `nav-menu-1`) and binds ARIA attributes to them, so rendering more than one `s-header` on the same page produces duplicate IDs and invalid `aria-controls`/`aria-labelledby` relationships. This is concretely triggered by the existing `s-header--different-logos` pattern, which renders two `@s-header` instances in one document.

Issue description

_s-cms-nav.hbs hard-codes id values used by ARIA relationships (e.g., nav-link-1, nav-menu-1). When multiple @s-header instances render on the same page (which already happens in s-header--different-logos.hbs), these IDs collide and ARIA relationships become invalid.

Issue Context

s-header.hbs already supports an id parameter for the collapse target. Reuse that same instance identifier (or a derived prefix) to make dropdown IDs unique per header instance.

Fix Focus Areas

  • src/lib/_imports/trumps/_s-cms-nav/_s-cms-nav.hbs[9-91]
  • src/lib/_imports/trumps/s-header/s-header.hbs[1-22]
  • src/lib/_imports/trumps/s-header/s-header--different-logos.hbs[1-7]

Suggested approach

  • Pass a unique id/prefix from s-header.hbs into the @s-cms-nav partial (e.g., {{> @s-cms-nav headerId=(default id 0)}}).
  • In _s-cms-nav.hbs, build IDs like nav-link-{{headerId}}-1 / nav-menu-{{headerId}}-1 (and similarly for -2).
  • Update all aria-controls and aria-labelledby values to match the new IDs.


                     PR 593 (2026-02-27)                    
[reliability] Dist/source CSS out of sync
Dist/source CSS out of sync `dist/tools/x-link.css` (and other dist files) were changed, but the source mixins in `src/lib/_imports/tools/x-link.css` still define the old `text-decoration: none`-based behavior. Because the build script generates `dist/` from `src/lib/_imports/`, the next rebuild/publish will likely revert these changes or create inconsistent artifacts.

Issue description

dist/** outputs were updated for x-link, but the source files under src/lib/_imports/** (which are used to generate dist/) were not updated. This makes the change non-reproducible and likely to be overwritten on the next build/publish.

Issue Context

The build script compiles src/lib/_imports/**/* into ./dist. Any intended style behavior changes must be made in the source mixins and then rebuilt.

Fix Focus Areas

  • src/lib/_imports/tools/x-link.css[3-86]
  • bin/build.js[11-15]
  • src/lib/_imports/elements/links.css[1-17]

[correctness] Hover thickness override dropped
Hover thickness override dropped The new dist output removes `text-decoration-thickness` from hover styles for `.x-link--hover` and general anchor `:hover` rules. Source comments indicate thickness was intentionally set to override downstream Bootstrap behavior; without it, consumers that apply a `text-decoration` shorthand on hover may reset thickness back to their default.

Issue description

Hover styles no longer explicitly set text-decoration-thickness, even though the source indicates it was needed to override downstream Bootstrap behavior. This may cause underline thickness changes when downstream CSS uses text-decoration shorthand on hover.

Issue Context

This is likely part of the x-link refactor (moving away from text-decoration shorthand). Ensure the previous override intent is either preserved or intentionally removed.

Fix Focus Areas

  • src/lib/_imports/tools/x-link.css[24-35]
  • dist/tools/x-link.css[1-1]
  • dist/elements/links.css[1-1]


Clone this wiki locally