Feat/style improvements#93
Conversation
laravdiemen
requested review from
FreakyWizard,
JasperS20,
Rovasch,
ShunLuk,
SimonvanWijhe,
WybeBosch,
Yannicvanveen,
YvetteNikolov,
Copilot,
dtakken,
ictbeheer,
mvdhoek1 and
rivanuff
There was a problem hiding this comment.
Pull request overview
This PR makes a set of small frontend/style tweaks in the Sage theme (Blade templates + Tailwind/CSS utilities) and bumps the Yard toolkit dev dependency.
Changes:
- Improve “no results” rendering in Yard Query Block templates by making the warning alert span full grid width.
- UI/layout tweaks: hide empty FacetWP selections container, adjust search-loop layout, and refine card direction classing.
- CSS refinements: conditional rounded corners for WP images (skip
alignfull), updates to dark-background utility selectors, and auto-grid defaults; plus a Tailwind@themedirective change. - Update
@yardinternet/toolkitfrom^2.1.2to^2.1.3(lockfile updated accordingly).
Reviewed changes
Copilot reviewed 8 out of 11 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| web/app/themes/sage/resources/views/vendor/yard-query-block/templates/horizontal.blade.php | Makes “no results” alert span full grid width. |
| web/app/themes/sage/resources/views/vendor/yard-query-block/templates/default.blade.php | Formatting cleanup + “no results” alert spans full grid width. |
| web/app/themes/sage/resources/views/components/facetwp/selections.blade.php | Hides the selections wrapper when selections are empty (via Tailwind has-[...] variant). |
| web/app/themes/sage/resources/views/components/card.blade.php | Adds explicit direction marker classes (card-column/row/fluid) and preserves passed-in classes via $attributes['class']. |
| web/app/themes/sage/resources/views/blocks/FacetWP/loops/search-loop.blade.php | Switches wrapper layout from grid to flex column. |
| web/app/themes/sage/resources/styles/blocks/wp/shared.css | Applies rounded corners only when blocks are not alignfull, using nested selectors. |
| web/app/themes/sage/resources/styles/base/utilities.css | Updates dark-background utility selectors + changes auto-grid defaults (auto-fill, wider min column). |
| web/app/themes/sage/resources/styles/base/config.css | Changes Tailwind theme directive to @theme static. |
| web/app/themes/sage/resources/styles/base/base-editor.css | Adds z-1 to the editor root container. |
| package.json | Bumps @yardinternet/toolkit to ^2.1.3. |
| pnpm-lock.yaml | Lockfile updates from the toolkit bump (and related dependency graph changes). |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| .wp-block-cover, | ||
| .wp-block-image img, | ||
| .wp-block-post-featured-image img, | ||
| .wp-block-image, | ||
| .wp-block-post-featured-image, | ||
| .wp-post-image { | ||
| @apply rounded-theme; | ||
| &:not( .alignfull ) { | ||
| &, | ||
| img { | ||
| @apply rounded-theme; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
🔴 The CSS refactor in shared.css introduces two issues: (1) .wp-block-cover:not(.alignfull) img now applies rounded-theme to all descendant images inside cover blocks — a regression since the old code only rounded the cover container itself, not its inner images; (2) .wp-post-image:not(.alignfull) img is dead code because WordPress applies .wp-post-image directly to <img> elements, which cannot have descendant img children. To fix the regression, .wp-block-cover should be kept separate (without the img sub-rule); the dead img sub-rule under .wp-post-image can also be removed as a cleanup.
Extended reasoning...
Bug 1 — Cover block img rounding regression (normal)
The PR refactors four selectors into a shared nested rule that applies rounded-theme to both the container (&) and its img descendants. While this is correct for .wp-block-image and .wp-block-post-featured-image (both are wrapper elements that contain a single <img> child), it is incorrect for .wp-block-cover.
In the old code, .wp-block-cover had no img sub-rule at all — only the container div was rounded:
/* OLD */
.wp-block-cover,
.wp-block-image img,
.wp-block-post-featured-image img,
.wp-post-image {
@apply rounded-theme;
}In the new code, the grouped rule adds img { @apply rounded-theme; } under .wp-block-cover as well:
/* NEW — the img sub-rule now also applies to .wp-block-cover */
.wp-block-cover,
.wp-block-image,
.wp-block-post-featured-image,
.wp-post-image {
&:not( .alignfull ) {
&,
img { @apply rounded-theme; }
}
}This means .wp-block-cover:not(.alignfull) img now matches: (a) img.wp-block-cover__image-background, which is the absolute-positioned background fill image; and (b) any <img> that an editor places inside the cover block's inner content container (.wp-block-cover__inner-container). The background image is clipped by overflow:hidden on the parent, so the rounding there is visually redundant. However, user-placed content images inside a cover block's overlay will gain an unexpected border-radius: 5px that was never applied before — a visible regression for any page using images inside cover block content areas.
The fix is straightforward: move .wp-block-cover out of the grouped rule and keep it as a standalone rule that only rounds the container:
.wp-block-cover:not( .alignfull ) {
@apply rounded-theme;
}
.wp-block-image,
.wp-block-post-featured-image,
.wp-post-image {
&:not( .alignfull ) {
&,
img { @apply rounded-theme; }
}
}Bug 2 — .wp-post-image img is dead code (nit)
WordPress applies the .wp-post-image class directly to <img> elements via get_the_post_thumbnail() / the_post_thumbnail(). The rendered HTML is:
<img class="attachment-post-thumbnail size-post-thumbnail wp-post-image" src="..." />Because <img> is a void element — it cannot have children — the selector .wp-post-image:not(.alignfull) img ("an img that is a descendant of a .wp-post-image element") will never match any DOM node. The rounded-theme utility is still correctly applied to the image itself via the & self-selector, so there is no visual regression. The img sub-rule is purely wasted generated CSS. By contrast, the same img sub-rule is valid for .wp-block-image and .wp-block-post-featured-image, which are wrapper <div> or <figure> elements with real <img> children.
Step-by-step proof for Bug 1:
- An editor creates a Cover block in Gutenberg, adds a background image, and then places an
<img>or Image block inside the cover's overlay area (this is a common use case — logos, icons, or decorative images on top of a cover). - WordPress renders:
<div class="wp-block-cover"><img class="wp-block-cover__image-background"/><div class="wp-block-cover__inner-container"><img src="logo.png"/></div></div> - Old CSS: only
.wp-block-cover(the outer div) getsborder-radius: 5px. The inner<img>elements are untouched. - New CSS:
.wp-block-cover:not(.alignfull) imgnow matches both the background image and the content image — both receiveborder-radius: 5pxunexpectedly.
There was a problem hiding this comment.
The fix correctly addresses Bug 2 ( is now a standalone rule without the sub-rule) and applies for specificity reduction. However, Bug 1 is still present: remains grouped with and , so the img sub-rule still generates the selector .wp-block-cover:where(:not(.alignfull)) img — meaning descendant images inside cover blocks still receive border-radius: 5px unexpectedly.
To fully fix Bug 1, .wp-block-cover needs to be moved out of the grouped rule into its own standalone rule (rounding only the container, not its img descendants):
.wp-post-image:where( :not( .alignfull ) ) {
@apply rounded-theme;
}
.wp-block-cover:where( :not( .alignfull ) ) {
@apply rounded-theme;
}
.wp-block-image,
.wp-block-post-featured-image {
&:where( :not( .alignfull ) ) {
&,
img {
@apply rounded-theme;
}
}
}| .wp-block-post-featured-image, | ||
| .wp-post-image { | ||
| @apply rounded-theme; | ||
| &:not( .alignfull ) { |
There was a problem hiding this comment.
Ik merk dat ik bij de Media en Tekst en de Groep blokken vaak aan het stoeien ben met specificity. Omdat er met .has-background, .align* én :not() wordt gestunt.
We moeten eens in kaart brengen wanneer we :where() moeten gaan gebruiken om deze specificity wars een beetje in te beperken. Misschien is dit een mooie eerste stap?
&:where( :not( .alignfull ) ) {
&,
img {
@apply rounded-theme;
}
}
There was a problem hiding this comment.
Ik heb het aangepast
| .wp-block-cover, | ||
| .wp-block-image, | ||
| .wp-block-post-featured-image { | ||
| &:where( :not( .alignfull ) ) { | ||
| &, | ||
| img { | ||
| @apply rounded-theme; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
🔴 The developer's fix for the border-radius regression only extracted .wp-post-image into a standalone rule, but .wp-block-cover was not separated — it remains grouped with .wp-block-image and .wp-block-post-featured-image (lines 19–28), meaning the compiled CSS still generates .wp-block-cover:where(:not(.alignfull)) img { @apply rounded-theme; }. This is a regression: the old code only rounded the cover container div itself, not descendant images — any <img> inside a cover block (background image or content-overlay images) now receives an unexpected border-radius.
Extended reasoning...
What the bug is and how it manifests
After the developer replied 'Ik heb het aangepast' (I've adjusted it) to the previous review comment, .wp-post-image was correctly extracted into its own standalone rule on line 15. However, .wp-block-cover was not given the same treatment — it remains in the grouped selector on lines 19–28 alongside .wp-block-image and .wp-block-post-featured-image. Because the nested block applies rounded-theme to both & (the container itself) and img (all descendant images), the CSS now generates .wp-block-cover:where(:not(.alignfull)) img { @apply rounded-theme; } — a selector that never existed in the pre-PR code.
The specific code path that triggers it
In the current shared.css (lines 19–28):
.wp-block-cover,
.wp-block-image,
.wp-block-post-featured-image {
&:where( :not( .alignfull ) ) {
&,
img {
@apply rounded-theme;
}
}
}The img sub-rule inside the nesting applies to every img that is a descendant of each listed selector. For .wp-block-image and .wp-block-post-featured-image this is intentional — both are wrapper <figure>/<div> elements containing a single <img> child. For .wp-block-cover it is not intentional.
Why existing code does not prevent it
The developer understood the issue well enough to separate .wp-post-image (line 15), confirming they read the previous review. But .wp-block-cover was left in the grouped rule, presumably because the regression for that class was less obvious: the cover container div still gets rounded (which is correct), but the grouped img sub-rule silently also rounds all descendant images at the same time.
What the impact would be
WordPress renders cover blocks as:
<div class="wp-block-cover">
<img class="wp-block-cover__image-background" />
<div class="wp-block-cover__inner-container">
<!-- Any images placed by the editor inside the overlay -->
<img src="logo.png" />
</div>
</div>Both the absolute-positioned background image (img.wp-block-cover__image-background) and any content images in the overlay area now receive border-radius: 5px unexpectedly. Placing an image (logo, icon, decorative element) inside a cover block's content area is a common editorial pattern; those images will be visually broken on every non-.alignfull cover block across the site.
How to fix it
Move .wp-block-cover out of the grouped rule into its own standalone selector that only rounds the container, without the img sub-rule:
.wp-block-cover:where( :not( .alignfull ) ) {
@apply rounded-theme;
}
.wp-block-image,
.wp-block-post-featured-image {
&:where( :not( .alignfull ) ) {
&,
img { @apply rounded-theme; }
}
}Step-by-step proof
- An editor creates a Cover block, sets a background image, and places an Image block or
<img>inside the cover overlay content area (common use case: logo or icon on a hero banner). - WordPress renders the cover as shown above — one
img.wp-block-cover__image-backgroundand one content<img>inside.wp-block-cover__inner-container. - Old CSS: only
.wp-block-cover(the outer<div>) getsborder-radius: 5px. The inner<img>elements are untouched. - New CSS: the selector
.wp-block-cover:where(:not(.alignfull)) imgmatches both inner images — both receiveborder-radius: 5pxunexpectedly, visually rounding what should be un-rounded content images.
There was a problem hiding this comment.
Het lijkt erop dat de code eerst niet klopte. De HTML ziet er als volgt uit:
<div class="wp-block-cover" style="min-height:350px;aspect-ratio:unset;">
<img loading="lazy" decoding="async" width="1620" height="1080" class="wp-block-cover__image-background wp-image-34" alt="" src="http://brave.local/app/uploads/2024/06/office.jpeg" data-object-fit="cover" srcset="https://brave.local/app/uploads/2024/06/office.jpeg 1620w, https://brave.local/app/uploads/2024/06/office-300x200.jpeg 300w, https://brave.local/app/uploads/2024/06/office-1024x683.jpeg 1024w, https://brave.local/app/uploads/2024/06/office-768x512.jpeg 768w, https://brave.local/app/uploads/2024/06/office-1536x1024.jpeg 1536w" sizes="auto, (max-width: 1620px) 100vw, 1620px">
<span aria-hidden="true" class="wp-block-cover__background has-black-background-color has-background-dim"></span>
<div class="wp-block-cover__inner-container is-layout-flow wp-block-cover-is-layout-flow">
<p class="has-text-align-center has-white-color has-text-color has-large-font-size">Omslagafbeelding</p>
</div>
</div>
Dus er zit zeker wel een <img> in wp-block-cover
Paar kleine aanpassingen, zie de commits voor wat exact.