Styling broken when previewing Home page of new WP.com site

[twstokes]

When previewing the Home page of a newly created site running the Alves theme, some styling is broken.

Expected behavior

Styling is consistent with block editor and web browser previews.

Actual behavior

Some styling is broken when previewing the page within the app.

Steps to reproduce the behavior

1. Create a new WP.com site
2. Choose the "Alves" theme under Business
3. Complete the site creation by choosing a domain, etc.
4. From the "My Site" view choose "Pages"
5. Choose "Home"
6. Observe that the heading "Raise Your Helping Hand" is white
7. Tap the ellipses at the top right and choose "Preview" in the bottom sheet
8. Observe that "Raise Your Helping Hand" is black
9. Tap the globe icon to preview in a browser
10. Observe that "Raise Your Helping Hand" is white

RPReplay_Final1645721687.MP4

Other context

This only seems to affect the Home page. When creating a new page on the site with the same design, the previews look correct.

Tested on iPhone 12, iOS 15.3.1, WPiOS 19.3.0.1

[twstokes]

This may be due to a discrepancy in the URLs used:

Browser	App Preview

[tiagomar]

This is also happening with other themes. I checked your test site and it looks exactly like the App Preview, with "Raise Your Helping Hand" in black.

I did reproduce the same for a recently created site with different theme:

styling.mov

[twstokes]

Thanks @tiagomar - I think it's theme-independent as well.

Interestingly, today both

• Browser
• App Preview

are landing on the same URL and have matching output. Yesterday this wasn't the case (as evident by my "App Preview" screenshot) - the browser would stay on the App Preview URL, e.g. wordpress.com.

Running curl -Iv https://twstokestest224223business.wordpress.com/\?preview\=true\&preview_id\=5\&preview_nonce\=58f25e8b26 shows me a location header of:

location: https://twstokestest224223business.wordpress.com/?preview_id=5&preview_nonce=58f25e8b26

which on load returns another location header of:

location: https://twstokestest224223.business.blog/?preview_id=5&preview_nonce=58f25e8b26 that matches the working URL.

My guess is that the server didn't send the redirect yesterday but today it did. If this is all on the web side, Android may be affected as well.

[fluiddot]

As far as I checked, this issue looks related to the changes introduced in WordPress/gutenberg#33541 related to the Cover block. I checked the HTML of some of the starter page templates used when creating a site and noticed that the HTML is updated adding a class is-light to the Cover block.

Here is an example (note that I'm only showing the affected HTML parts):

Raw HTML content from the Alves theme starter page template:

<!-- wp:cover {"url":"https://alvesstarter.files.wordpress.com/2020/06/jenn-evelyn-ann-uydoe_ayjqs-unsplash.jpg","id":62,"dimRatio":70,"overlayColor":"foreground-dark","focalPoint":{"x":0.5,"y":0.5},"align":"full"} -->
<div class="wp-block-cover alignfull has-background-dim-70 has-foreground-dark-background-color has-background-dim"
    style="background-image:url('https://alvesstarter.files.wordpress.com/2020/06/jenn-evelyn-ann-uydoe_ayjqs-unsplash.jpg');background-position:50% 50%;">

    <div class="wp-block-cover__inner-container">
        <!-- [HERE GOES THE COVER CONTENT] -->
    </div>
</div>
<!-- /wp:cover -->

<!-- [HERE GOES THE REST OF THE BLOCKS] -->

HTML after being parsed and updated by the editor:

<!-- wp:cover {"url":"https://alvesstarter.files.wordpress.com/2020/06/jenn-evelyn-ann-uydoe_ayjqs-unsplash.jpg","id":62,"dimRatio":70,"overlayColor":"foreground-dark","focalPoint":{"x":0.5,"y":0.5},"align":"full"} -->
<div class="wp-block-cover alignfull is-light">
    <span aria-hidden="true"
        class="wp-block-cover__background has-foreground-dark-background-color has-background-dim-70 has-background-dim">
    </span>
    <img
        class="wp-block-cover__image-background wp-image-62"
        src="https://alvesstarter.files.wordpress.com/2020/06/jenn-evelyn-ann-uydoe_ayjqs-unsplash.jpg"
        style="object-position:50% 50%" data-object-fit="cover" data-object-position="50% 50%" />
    <div class="wp-block-cover__inner-container">
        <!-- [HERE GOES THE COVER CONTENT] -->
    </div>
</div>
<!-- /wp:cover -->

<!-- [HERE GOES THE REST OF THE BLOCKS] -->

You can see that the main div is modified keeping the classes wp-block-cover alignfull and adding a new one is-light. The rest of the classes are moved to a new span element, and similarly, the style attribute is moved to a new img component. These modifications are part of the deprecations defined here.

With the introduction of is-light class in this PR, we have two issues in the native version:

Native version doesn't provide different styles for is-light class and isDark attribute

This is the main cause why we see the text color difference between the editor and the preview, as described in the issue description. If we had styles for this case, we would see the text color within the Cover block also black as in the preview.

isDark attribute is not automatically updated

In the web version, isDark attribute is automatically updated depending on the darkness of the cover background, via the useCoverIsDark hook. This means that even if the editor adds the is-light class after applying the updates due to deprecations, the isDark attribute would be updated accordingly to the cover background and keep/remove the is-light class properly.

Why is this only happening on starter page templates?

It's interesting that this issue only occurs in starter templates, I also checked the HTML from the page templates and noticed that there's a difference on the attributes of the text blocks:

HTML from page template - Heading block with text Raise Your Helping Hand:

<!-- wp:heading {"textAlign":"center","level":1,"textColor":"background"} -->
<h1 class="has-text-align-center has-background-color has-text-color"><strong>Raise Your Helping Hand</strong></h1>
<!-- /wp:heading -->

HTML from starter page template - Heading block with text Raise Your Helping Hand:

<!-- wp:heading {"textAlign":"center","level":1} -->
<h1 class="has-text-align-center"><strong>Raise Your Helping Hand</strong></h1>
<!-- /wp:heading -->

You can see that in the first one (i.e. page template), the background text color is set via the textColor attribute, which actually is the white color.

---

At this point, we have various options for addressing the issue:

1. Update the Cover block's HTML of start page templates.
2. Support isDark attribute in the native version.

The latter would be a bit tricky as we can't use the useCoverIsDark hook because it's only supported on web. So, most likely it would be more feasible to update the starter page templates HTML based on the latest versions of the page templates.