Planet: Keep syndicated entry content inside the column - #850
Conversation
Planet republishes post content from other sites, and that content can carry
pixel widths baked into the markup. A post currently in the feed uses newsletter
blocks whose separators are emitted as
<hr style="... width: 560px; height: 0;">
560px is the email column width the plugin renders for. Planet puts that inside
a column that is 342px wide at a 360px viewport, so the page gains 234px of
horizontal scroll on phones. Measured on planet.wordpress.org at 375px: three
such separators, each overhanging by 234px, and they are the only elements
escaping the viewport.
wp4.css already guards against this for one element type:
.wrapper img { max-width: 100%; height: auto; }
Extend the same guard to the other elements that arrive from a feed with a
hardcoded width. Scoped to `.entry` so it only applies to syndicated content.
Measured before and after on planet.wordpress.org:
375px viewport 234px of horizontal scroll -> 0px
the 560px hr 560px wide -> 302px, inside its 342px parent
At 1440px the change is a no-op: 40 hr, 14 table and 90 img elements all keep
their existing widths and the document height is unchanged.
See https://meta.trac.wordpress.org/ticket/8419
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe standard and RTL WordPress.org styles now limit hardcoded-width syndicated entry elements to the width of their ChangesResponsive syndicated entry content
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This localized stylesheet change constrains oversized syndicated content within the Planet column and removes the reported mobile horizontal overflow without changing wider layouts. No actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@softglazee Thanks for looking into this and creating the PR! The changes look good. |
|
Thanks again for preparing the fix. Since this PR addresses the issue I identified in Meta Trac #8419, could I please be included in the props when it is merged, if applicable? |
Trac ticket: https://meta.trac.wordpress.org/ticket/8419
The problem
At a 375px viewport, https://planet.wordpress.org/ scrolls 234px sideways.
The cause is content Planet republished from another site. A post currently in the feed was written with newsletter blocks, and those emit separators with the email column width baked into the markup:
560px is the width the newsletter plugin renders for. Planet puts that inside a column that is 342px wide at a 360px viewport.
Measured on the live page at 375px: three of these separators, each overhanging by 234px, and they are the only elements escaping the viewport. At 768px and above nothing overflows, because the column is wider than 560px.
The change
wp4.cssalready guards against exactly this, for one element type:This extends the same guard to the other elements that arrive from a feed with a hardcoded width, scoped to
.entryso it only affects syndicated content and not wordpress.org's own layout.Testing
Measured on https://planet.wordpress.org/ by injecting the rule and re-measuring real horizontal scrollability.
hr)No regressions at 1440px. The rule is a no-op there: 40
hr, 14tableand 90imgelements all keep their existing widths, the document height is identical at 75,139px, and horizontal scroll is 0 before and after.Screenshots of the same viewport before and after, showing the horizontal scrollbar disappear, are attached to the Trac ticket.
On the second half of the ticket
The ticket also reports missing article images. I could not reproduce that. On the current page all 91 images load, from
i0.wp.comands.w.org, with zero broken images and zero failed network requests.The post in the reporter's screenshot is still in the feed, and both of the images that appear broken there load correctly now, so that looks like a transient CDN failure rather than a defect in Planet.
Worth recording why it looked so severe: those images sit in a gallery block whose own background is
rgb(0, 0, 0), set by the source post. When an image fails, the fallback is alt text on black, which is why the screenshot shows black rectangles. That styling comes from the syndicated content, so it is not something Planet sets.This PR therefore only addresses the overflow, which is reproducible and measurable.
Summary by CodeRabbit