Reader: Keep inline styles in post content

[mmtr]

Fixes #44992.
Helps with #43595.

Changes proposed in this Pull Request

The reader API endpoints return posts with content that might include inline styles provided by the Gutenberg blocks fallbacks plugin (D50508-code). However, Calypso was stripping out those styles as part of a normalization process. This PR removes the piece of logic that was removing the inline styles so they are kept in the post content rendered in the reader.

Before	After
	Requires D51569-code
	They look the same, but we use less code now given that most styles are coming from Gutenberg.

Testing instructions

• Apply D51569-code and sandbox the API.
• Make sure the block fallbacks cache is turned off by adding define( 'BLOCK_FALLBACKS_DEBUG', true ); to your /wp-content/mu-plugins/0-sandbox.php file.
• Go to Reader and check different post.
• Make sure the block styles are applied to what's rendered.

[matticbot]

Test live: https://calypso.live/?branch=remove/reader-normalize-styles

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~163 bytes removed 📉 [gzipped])

name    parsed_size           gzip_size
reader       -784 B  (-0.1%)     -163 B  (-0.1%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~533 bytes removed 📉 [gzipped])

name                                                     parsed_size           gzip_size
async-load-design-blocks                                      -784 B  (-0.0%)     -207 B  (-0.0%)
async-load-calypso-components-web-preview-component           -784 B  (-0.1%)     -163 B  (-0.1%)
async-load-calypso-blocks-support-article-dialog-dialog       -784 B  (-0.8%)     -163 B  (-0.6%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[krymson24]

This is what I get back for content:

content: "<div class="wp-block-buttons">↵<div class="wp-block-button"><a class="wp-block-button__link">button1</a></div>↵↵↵↵<div class="wp-block-button"><a class="wp-block-button__link">button2</a></div>↵↵↵↵<div class="wp-block-button"><a class="wp-block-button__link">button3</a></div>↵</div>↵↵↵↵<h2 class="has-text-align-center has-secondary-color has-background-dark-background-color has-text-color has-background">heading</h2>"

This is what I see:

[bluefuton]

@mmtr just to clarify - won't this leave all inline styles in place, not just Gutenberg ones? Can we be more selective?

I think we stripped them originally because the user-defined inline styles often don't render well in Reader.

[gibrown]

@mmtr all of this feels like it should be handled server side in a more consistent manner rather than just in Calypso. This won't deal with any issues in the mobile apps or elsewhere if we only do it here.

[kwight]

@gibrown I gave some additional background in paYKcK-KO-p2.

won't this leave all inline styles in place, not just Gutenberg ones? Can we be more selective?

It would, yes. Maybe we could add a class marker to an element (has-gutenberg-styles) which could be identified by removeStyles and allowed to pass?

I think we stripped them originally because the user-defined inline styles often don't render well in Reader.

Does this refer to things like strikethrough and underline?..

[krymson24]

Still seeing this 😢

[krymson24]

@kwight, @gibrown I believe the [inline_block_styles](D50508-code) fallback that @mmtr wrote is being applied to the Reader content and passing through inline styles, with some exceptions mentioned here: D51569-code#1047745, so this isn't just being applied on the frontend. Unfortunately, for whatever reason, my Reader instance in particular isn't show anything of these styles, but I believe there's something not quite right with my local environment.

@bluefuton I think there's new context here. My understanding is that the Reader posts are supposed to look exactly like the original post, and our work here is to enable more rich content and styles here to flow through. What was previously styled content that doesn't render well, we want to gradually make better.

[gibrown]

How about expanding on how the normalizer was already allowing certain styles through?

wp-calypso/client/lib/post-normalizer/rule-content-remove-styles.js

Line 19 in 41f07f8

export default function removeContentStyles( post, dom ) {

After poking at the code more I rescind my attempt to have this happen server side. I think I remember making that argument years ago too. Sigh...

My understanding is that the Reader posts are supposed to look exactly like the original post

@krymson24 this has never fully been possible. There are lots of styles someone could add to their content that would look terrible in the Reader. That is why we build our own excerpts for instance where the streams look terrible if you just take whatever the user gives you. We definitely should continue to make things better, but it is almost certainly going to break a lot of things if we completely remove any of the normalization steps. Let's improve what is there and add more tests along the way to make it easier.

[krymson24]

Why were these classes removed? (They aren't the correct styles, admittedly, but I feel like we still need them, without knowing a better place to put them)

[bluefuton]

Does this refer to things like strikethrough and underline?

No, more that any style the user adds inline (e.g. using a Custom HTML block) ends up making it to Reader with this change.

https://hash-96a65d8c72cff8e86eb15e46d6c559e887609d03.calypso.live/read/feeds/40474296/posts/2988003678

The display of content in Reader has always been opinionated - we respect certain structural basics of the layout (like tables, headings, and so on) but we make the decisions about text size, font, colour, which images or video to highlight, spacing, etc.

If we're changing that, it's a big change, and we should talk through the ramifications of it with Design.

[kwight]

The display of content in Reader has always been opinionated - we respect certain structural basics of the layout (like tables, headings, and so on) but we make the decisions about text size, font, colour, which images or video to highlight, spacing, etc.

Ah, I see – I didn't realize myself how opinionated it was. The goal of our block rendering project is to have blocks render in the Reader in a sensible, predictable way, but we certainly don't want to just regress any intentional design done up to now. It sounds like being more detailed in the post normalization handling will be a better way forward, so I'll close this for now and we can pick up elsewhere with a new approach.