fix: fix lazy-loaded images in safari

[Arukuen]

Summary by CodeRabbit

• Bug Fixes
  • Fixed rendering issues for lazy‑loaded images in Safari on iOS/macOS to reduce flicker and improve visual stability.
  • Improved perceived performance for images that load lazily in affected Safari versions.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a Safari-specific CSS rule that, inside an @supports font check targeting Safari 9+ on iOS/macOS, applies will-change: transform to img.stk-img.lazyloaded to address lazy-loading rendering issues.

Changes

Cohort / File(s)	Summary
Safari Lazy-Load Rendering Fix src/block-components/image/style.scss	Introduced an @supports block (font-support guard for Safari) that applies will-change: transform to img.stk-img.lazyloaded, targeting Safari 9+ lazy-loading rendering glitches on iOS and macOS.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 A tiny hop to fix a frame,
Safari quirks I softly name,
will-change: transform — a gentle shove,
Lazy images settle like leaves above,
Hooray, the pixels cozy up and tame!

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: fixing lazy-loaded images in Safari. It directly relates to the SCSS modification that adds a Safari-specific rendering fix for lazy-loaded images.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/img-lazy-load-safari

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

🤖 Pull request artifacts

file	commit
pr3684-stackable-3684-merge.zip	de39663

[github-actions]

Try this Pull Request in the WordPress playground: https://playground.wordpress.net/?mode=seamless#{"landingPage":"/wp-admin/post-new.php?post_type=page","preferredVersions":{"php":"latest","wp":"latest"},"steps":[{"step":"login","username":"admin","password":"password"},{"step":"installPlugin","pluginZipFile":{"resource":"url","url":"https://raw.githubusercontent.com/gambitph/Stackable/artifacts/pr3684-stackable-3684-merge.zip"}}]}

[coderabbitai]

🧹 Nitpick comments (1)

src/block-components/image/style.scss (1)

76-80: Consider a more robust Safari-only @supports compound check.

@supports (font: -apple-system-body) alone can match non-Safari browsers on macOS. While the consequence here is benign (an innocuous will-change hint applied to Chrome/Edge on macOS), the code comment explicitly states the intent is to target Safari. A more bulletproof approach chains (hanging-punctuation: first) and (font: -apple-system-body) and (-webkit-appearance: none), which reliably isolates Safari 16+ on macOS and all WebKit-based browsers on iOS without false-positives on Blink-based desktop browsers.

♻️ Proposed refinement

-@supports (font: -apple-system-body) {
+@supports (hanging-punctuation: first) and (font: -apple-system-body) and (-webkit-appearance: none) {
 	img.stk-img {
 		will-change: transform;
 	}
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/block-components/image/style.scss` around lines 76 - 80, The current
`@supports` block that targets img.stk-img uses (font: -apple-system-body) which
can match non‑Safari browsers; update the Safari check to a compound `@supports`
condition that reliably isolates Safari/WebKit (for example combine
(hanging-punctuation: first) and (font: -apple-system-body) and
(-webkit-appearance: none)) and replace the existing `@supports` around the
img.stk-img rule; keep or add a brief comment stating the intent to target
Safari/WebKit so future editors understand the special-case selector.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/block-components/image/style.scss`:
- Around line 76-80: The current `@supports` block that targets img.stk-img uses
(font: -apple-system-body) which can match non‑Safari browsers; update the
Safari check to a compound `@supports` condition that reliably isolates
Safari/WebKit (for example combine (hanging-punctuation: first) and (font:
-apple-system-body) and (-webkit-appearance: none)) and replace the existing
`@supports` around the img.stk-img rule; keep or add a brief comment stating the
intent to target Safari/WebKit so future editors understand the special-case
selector.

[coderabbitai]

🧹 Nitpick comments (2)

src/block-components/image/style.scss (2)

76-76: Consider a more bulletproof Safari @supports guard.

@supports (font: -apple-system-body) alone is sufficient today, but chaining it with hanging-punctuation: first and -webkit-appearance: none produces a more bulletproof Safari-only match, as recommended since 2024. A false positive here (e.g., a future non-Safari engine picking up -apple-system-body) would unconditionally enable will-change: transform on all lazy-loaded images in that browser.

♻️ Suggested guard

-@supports (font: -apple-system-body) {
+@supports (hanging-punctuation: first) and (font: -apple-system-body) and (-webkit-appearance: none) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/block-components/image/style.scss` at line 76, The current `@supports` rule
"@supports (font: -apple-system-body)" is too narrow and risks false positives;
update the Safari guard around the block that enables "will-change: transform"
for lazy-loaded images by chaining additional feature checks such as
"hanging-punctuation: first" and "-webkit-appearance: none" (i.e., use a
combined `@supports` condition that requires all three) so the rule only matches
Safari-like engines; locate the `@supports` block in
src/block-components/image/style.scss and replace the single-feature guard with
the chained guard to more reliably scope the Safari-only styles.

---

77-79: Permanent will-change: transform on all lazy-loaded images may create unnecessary GPU pressure.

will-change is intended as a temporary hint and should be removed once the rendering issue is resolved. Applying it permanently in CSS to every img.stk-img.lazyloaded element allocates a separate compositor layer per image for the lifetime of the page. On image-heavy pages, this compounds memory usage.

If the rendering glitch only occurs during the transition from lazyloading → lazyloaded, a JS-based approach (add will-change: transform on lazybeforeunveil, remove it shortly after lazyloaded fires) would be more precise. If staying in CSS, scoping it further (e.g., by also requiring an ancestor class specific to the Stackable block) would limit the blast radius.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/block-components/image/style.scss` around lines 77 - 79, The rule
img.stk-img.lazyloaded keeps will-change: transform permanently and should be
made temporary or scoped to avoid persistent GPU layers; update styles/behavior
by removing will-change from the global CSS selector and either (A) implement a
JS fix that adds will-change: transform when the image enters lazybeforeunveil
and removes it shortly after the lazyloaded event (or on a small timeout) using
the img.stk-img.lazyloaded node, or (B) if keeping a CSS-only fix, restrict the
selector to a much narrower scope (e.g., require a Stackable block ancestor
class such as .stk-block img.stk-img.lazyloaded) so only affected blocks get the
hint. Ensure the code references the img.stk-img.lazyloaded selector and the
lazybeforeunveil / lazyloaded events when implementing the JS approach.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/block-components/image/style.scss`:
- Line 76: The current `@supports` rule "@supports (font: -apple-system-body)" is
too narrow and risks false positives; update the Safari guard around the block
that enables "will-change: transform" for lazy-loaded images by chaining
additional feature checks such as "hanging-punctuation: first" and
"-webkit-appearance: none" (i.e., use a combined `@supports` condition that
requires all three) so the rule only matches Safari-like engines; locate the
`@supports` block in src/block-components/image/style.scss and replace the
single-feature guard with the chained guard to more reliably scope the
Safari-only styles.
- Around line 77-79: The rule img.stk-img.lazyloaded keeps will-change:
transform permanently and should be made temporary or scoped to avoid persistent
GPU layers; update styles/behavior by removing will-change from the global CSS
selector and either (A) implement a JS fix that adds will-change: transform when
the image enters lazybeforeunveil and removes it shortly after the lazyloaded
event (or on a small timeout) using the img.stk-img.lazyloaded node, or (B) if
keeping a CSS-only fix, restrict the selector to a much narrower scope (e.g.,
require a Stackable block ancestor class such as .stk-block
img.stk-img.lazyloaded) so only affected blocks get the hint. Ensure the code
references the img.stk-img.lazyloaded selector and the lazybeforeunveil /
lazyloaded events when implementing the JS approach.