Responsive editing: viewport style changes stack on top of general styles instead of overriding them

[jobthomas]

What problem does this address?

While testing Responsive editing (WordPress 7.1 Beta 4), viewport-specific style changes appear to be applied on top of the general (default) block styles rather than overriding them.

Concretely: after enabling Responsive editing via the device preview dropdown and changing the "orientation" control for a specific viewport, the block's text rendered upside down. The viewport orientation value combined with the base value instead of replacing it.

Expected behaviour

A style set for a specific viewport should override the general style for that property at that viewport — not stack additively on top of it.

Steps to reproduce

1. Enable Responsive editing from the device preview dropdown.
2. Select a block that supports the orientation style.
3. Change the orientation for a specific viewport.
4. Observe the text renders upside down — the base and viewport values combine rather than the viewport value overriding.

Environment

• WordPress 7.1 Beta 3
• Tested on WordPress.com
• Related to Integrate Resizable Editor with Device Preview and add Responsive editing #75121

The cause for the above is that both orientation styles are selected for this block: one in the general view (so for every site), one on the responsive editing. However, in the responsive view only, it's not visible that this is the case, it just looks like upside down text. I can fix it by first updating the general approach, and then editing the orientation in desktop view, but it feels very counterintuitive to do so since the exception I want here is on mobile.

Part of it seems to be the fact that the UI gives the idea you're starting with a blank slate when adding a responsive layer, but you're not, you're inheriting existing styles.

[talldan]

@jobthomas Thanks for reporting this. The repro steps are not very clear to me and I wasn't able to repro the upside down text. I think there's something missing, because you mention the states 'combine', but the repro steps only mention setting text direction on one viewport, so what are they combining with?

Maybe if you could share a video or update the steps. Thanks.

[jobthomas]

Sorry about that:

• Set the orientation to vertical across the site
• Go to mobile + responsive style
• You then see that the side bar changes (even though orientation vertical is clearly still applied to the H2 element, it's no showing as selected), if you then click on "Horizontal", the element goes upside down

Here's a video, I couldn't add it to this actual comment: https://cleanshot.com/share/pTGK1B14

[ramonjd]

Thanks for the helpful video @jobthomas Edit: I updated this comment after a bit more testing.

I'm not sure anything is stacking, and I don't see a different when the global style for vertical orientation is set or not.

I can reproduce the upside down text with the following markup:

<!-- wp:paragraph {"style":{"@mobile":{"typography":{"writingMode":"horizontal-tb"}},"typography":{"writingMode":"vertical-rl","textAlign":"right"}}} -->
<p class="has-text-align-right" style="writing-mode:vertical-rl">para</p>
<!-- /wp:paragraph -->

It looks like it's related to the rotate value:

.block-editor-block-list__block[data-type="core/paragraph"].has-text-align-right[style*="writing-mode: vertical-rl"] {
    rotate: 180deg;
}

Here's what happens when I toggle it:

Kapture.2026-07-31.at.15.59.55.mp4

Since #53175, there's some sort of auto rotate going on. Maybe we could reconsider that idea.

About the closing tools panels, it is a bit annoying that the control closes when switching between viewports. It's a different issue. Many controls are not shown by default unless they have a value. So when you switch from Desktop to Mobile, even if control x has a value for Desktop, if it's hidden by default, it'll appear to "disappear".

It would be more user friendly to keep it open, but I think it'd required a rewiring of the way ToolsPanel works.

[ramonjd]

Since #53175, there's some sort of auto rotate going on. Maybe we could reconsider that idea.

Ah, since that PR making text vertical and aligning right rotates the whole block half a turn, so it reads bottom-to-top instead of top-to-bottom. This is done by that CSS rules.

.block-editor-block-list__block[data-type="core/paragraph"].has-text-align-right[style*="writing-mode: vertical-rl"],
.block-editor-block-list__block[data-type="core/paragraph"].has-text-align-left[style*="writing-mode: vertical-lr"] {
	rotate: 180deg;
}

p.has-text-align-right[style*="writing-mode:vertical-rl"],
p.has-text-align-left[style*="writing-mode:vertical-lr"] {
	rotate: 180deg;
}

With responsive editing, it puts declarations in a media query, but doesn't know about the classnames or the style attribute.

So setting orientation in mobile makes the text horizontal

@media (width <= 480px) {
    .wp-states-5d7e40b0 {
        writing-mode: horizontal-tb !important;
    }
}

but the HTML still reads "vertical and right-aligned"

<p class="has-text-align-right wp-states-5d7e40b0 wp-block-paragraph" style="writing-mode:vertical-rl">para</p>

so the rotation stays switched on. Horizontal text plus 180° is upside-down text.

This is a YOLO PR to ensure the breakpoint knows whether text should be flipped:

• Fix/responsive state text rotation #81008

On reconsidering the auto rotate, a sideways- (writing-mode value) control could allow users to rotate it manually. An extra "thing" though.

Kapture.2026-07-31.at.17.10.05.mp4

[jobthomas]

Thanks! Seems like it's luckily more of an oddball case than a bigger problem.