Planet: Page UI/layout issues with scrolling and missing article images

[valani9099]

The WordPress Planet page has some full-page UI and layout issues.

While scrolling through the page, there is unexpected overflow/scrolling behavior, and some content does not stay within the expected layout boundaries.

Some article images also fail to load correctly.

Expected Result

• No unwanted horizontal/vertical overflow.
• Smooth and consistent scrolling.
• Proper responsive UI/layout across the full page.
• All available article images should load correctly.
• Missing images should not break the layout.

Page: ​https://planet.wordpress.org/

[softglaze]

Planet front page at 375px before the fix: 234px of horizontal scroll, note the scrollbar and the cut-off byline

[softglaze]

Same viewport and scroll position with the rule added: 0px horizontal scroll, scrollbar gone, byline fully visible

[softglaze]

Looked at both halves of this. The overflow reproduces and has a cause I can point at; the missing images do not reproduce. PR for the overflow: ​https://github.com/WordPress/wordpress.org/pull/850

The overflow

At a 375px viewport the front page scrolls 234px sideways. At 768px and above nothing overflows.

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:

<hr style="background-color: transparent; color: transparent; margin: 0;
           border: 0; border-top: 1px solid #666666; width: 560px; height: 0;">

560px is the width the newsletter plugin renders for. Planet puts that inside a column that is 342px wide at a 360px viewport.

I checked every element on the page rather than just the separators: three of these hr elements are the only things escaping the viewport, each overhanging by 234px. Nothing else, at any width I tested.

Fix

wp4.css already guards against exactly this, for one element type:

.wrapper img {
	max-width: 100%;
	height: auto;
}

The PR extends the same guard to the other elements that arrive from a feed with a hardcoded width, scoped to .entry so it only touches syndicated content:

.wrapper .entry hr,
.wrapper .entry table,
.wrapper .entry iframe,
.wrapper .entry video,
.wrapper .entry embed,
.wrapper .entry object {
	max-width: 100%;
}

Measure	Before	After
horizontal scroll at 375px	234px	0px
elements escaping the viewport	3	0
the 560px separator	560px wide	302px, inside its 342px parent

No regressions at 1440px. The rule is a no-op there: 40 hr, 14 table and 90 img elements all keep their existing widths, the document height is identical at 75,139px, and horizontal scroll is 0 both before and after.

Screenshots attached, 8419-before-375.png and 8419-after-375.png, same viewport and same scroll position, with only the rule added. The horizontal scrollbar at the bottom of the before shot is gone in the after shot, and the byline that was cut off is fully visible.

The missing images

I could not reproduce this. On the current page all 91 images load, from i0.wp.com and s.w.org, with zero broken images and zero failed network requests.

The post in your screenshot is still in the feed, and the two images that appear broken there both load correctly now:

Michael Hammett reading the Phoenix WordPress Day proclamation
Michael Hammett presenting the WordPress Day proclamation to Matt Mullenweg

So that looks like a transient CDN failure rather than a defect in Planet.

One thing worth recording, because it explains why it looked so bad. 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 rather than the usual broken image icon. That styling arrives with the syndicated content, so it is not something Planet sets, and Planet cannot reasonably override arbitrary source styling.

If the images are still failing for you, a fresh screenshot with the browser network panel open would help, since the URL that failed would identify whether it is Photon or the origin.

On the other points

I did not find anything for the vertical overflow or the scrolling smoothness. Scrolling behaved normally at every width I tested, and there was no vertical overflow beyond the expected page length.

The ticket carries needs-design. The change above is containment rather than a design decision, so I do not think it needs design input, but happy to be told otherwise.