Title: 7-1 – Make WordPress Test

---

#  Tag Archives: 7-1

 [  ](https://profiles.wordpress.org/nikunj8866/) [Nikunj Hatkar](https://profiles.wordpress.org/nikunj8866/)
4:19 am _on_ July 3, 2026     
Tags: 7-1, [call for testing ( 23 )](https://make.wordpress.org/test/tag/call-for-testing/),
[core-test ( 218 )](https://make.wordpress.org/test/tag/core-test/), [full-site-editing ( 63 )](https://make.wordpress.org/test/tag/full-site-editing/),
[gutenberg ( 72 )](https://make.wordpress.org/test/tag/gutenberg/)   

# 󠀁[Call for Testing: Responsive Styling](https://make.wordpress.org/test/2026/07/03/call-for-testing-responsive-styling/)󠁿

As part of the upcoming **WordPress 7.1 release**, we’re working on **responsive
styling** – the ability to style blocks differently for tablet and mobile, directly
from the editor. [PR #75121](https://github.com/WordPress/gutenberg/pull/75121) 
unifies the resizable editor with the device-preview switcher, which is the groundwork
this feature builds on, and we’d love your help testing it.

More testing is needed to make sure it’s reliable and intuitive before it ships.

## What is responsive styling?

Until now, a style you set on a blockBlock Block is the abstract term used to describe
units of markup that, composed together, form the content or layout of a webpage
using the WordPress editor. The idea combines concepts of what in the past may have
achieved with shortcodes, custom HTML, and embed discovery into a single consistent
API and user experience. – a font size, some spacing – applied the same way on every
screen. Responsive styling lets you change a value **just for tablet or just for
mobile**, without writing any custom CSSCSS CSS is an acronym for cascading style
sheets. This is what controls the design or look and feel of a site..

A few real examples:

 * A large heading on desktop that becomes smaller on mobile.
 * Generous padding on desktop that tightens up on a phone.
 * A different text color on the tablet than on the desktop.

To make these changes, first turn on Responsive editing from the device-preview 
dropdown – then switch the device view to Tablet or Mobile and edit the value while
that view is active. The change is saved only for that breakpoint.

## Why this matters

 * Let’s you match a design across screen sizes without leaving the editor or hand-
   writing media queries.
 * Keeps responsive tweaks, visual, and previewable – what you see is what visitors
   get.
 * Moves WordPress toward fuller per-breakpoint design control in the editor.

## How to test

The easiest way to test is **WordPress Playground** – no setup, nothing to install.
This loads a fresh site with the latest GutenbergGutenberg The Gutenberg project
is the new Editor Interface for WordPress. The editor improves the process and experience
of creating new content, making writing rich content much simpler. It uses ‘blocks’
to add richness rather than shortcodes, custom HTML etc. [https://wordpress.org/gutenberg/](https://wordpress.org/gutenberg/),
which includes the responsive styling work plus any fixes that have landed since.

[Test responsive styling in Playground](https://playground.wordpress.net/?gutenberg-branch=trunk)

The link logs you in as admin and opens a fresh post, ready to test. Building the
PR can take a minute on first load, so give it a moment.

> Tip: The device view switcher is the **Desktop / Tablet / Mobile** dropdown in
> the editor’s top toolbar. Switching it is how you tell WordPress which breakpoint
> you’re looking at. With this PR, you can also drag the **resize handles** at the
> edge of the canvas to change the width.

## Key changes to observe

 * The device-preview dropdown and the resizable editor now work together: picking**
   Tablet** or **Mobile** sets the canvas width, and dragging the resize handles
   updates the device view to match.
 * The dropdown has a new **Responsive editing** option. When it’s on, style changes
   you make apply to the current viewport (Tablet or Mobile) instead of Desktop.
 * When Responsive editing is on, and you select a block on Tablet or Mobile, a **
   viewport badge** appears in the block inspector showing which device you’re editing.
   No badge is shown on the desktop, since edits there apply everywhere.
 * Per-viewport edits are preserved and shown per device; turning Responsive editing
   off resets the editing state to default, and the badge disappears.

## Test steps

You don’t need to follow all of these – pick what you have time for, and note anything
that feels broken or confusing.

### Scenario 1 – Resize handles and device view together (Post editor)

 1. In the post editor, open the device dropdown and switch to Tablet (resize handles
    appear on the canvas edges).
 2. Drag a handle inward and outward and watch the canvas width change.
 3. Drag a handle all the way out to its widest – the handles should disappear, and
    you should land back in **Desktop** view.
 4. Confirm the dropdown and the handles always agree on which view you’re in.

> Note: In Desktop view, the handles may not show at first if there’s no spare space
> beside the canvas – use the dropdown to switch to Tablet/Mobile first. This is
> expected.

### Scenario 2 – Pattern editor and Navigation editor

 1. Edit or create a **pattern** (Appearance → Patterns, or via the site editor).
 2. Here, the resize handles are always visible. Drag them and also use the device 
    dropdown.
 3. Confirm the two stay in sync and the canvas resizes smoothly.
 4. Repeat the same check in the **Navigation editor** (Appearance → Editor → Navigation),
    where the handles are also always visible.

This change touches all four editors – Post, Template / Site (Appearance → Editor
→ Templates), Pattern, and Navigation – so testing across more than one is especially
valuable.

### Scenario 3 – Responsive editing (the main one)

 1. Open the device-preview dropdown and turn on **Responsive editing**.
 2. Select a block that has style options (e.g., a **Heading**). (On Desktop, no viewport
    badge is shown – this is intended.)
 3. Switch the device preview to **Tablet** or **Mobile** – or drag the canvas to that
    width. A viewport badge now appears in the block inspector (right sidebarSidebar
    A sidebar in WordPress is referred to a widget-ready area used by WordPress themes
    to display information that is not a part of the main content. It is not always
    a vertical column on the side. It can be a horizontal rectangle below or above 
    the content area, footer, header, or any where in the theme.) showing which device
    you’re editing.
 4. Change a style (for example, a smaller **font size**). Confirm the change applies**
    only** to that viewport, not to Desktop.
 5. Switch back to **Desktop** and confirm your per-viewport edit is preserved and 
    the Desktop value is unchanged.
 6. Turn **Responsive editing** off and confirm the editing state resets to default,
    and the badge disappears.

**Also worth trying (quick real-world checks):**

 * **Save and reload** the editor – your per-viewport edits should still be there.
 * Try it on a **couple of different blocks** (Group, Button, Image) and **different
   properties** (spacing, colors), not just font size.
 * Set **both** Tablet and Mobile differently on the same block and confirm each
   is remembered.
 * **Undo/redo** a per-viewport edit and confirm it behaves sensibly.

### Scenario 4 – Hidden-on-device blocks respond to canvas resize

Block visibility itself has already shipped in Gutenberg. What’s new in this PR 
is that **resizing the canvas** (not just the device dropdown) now triggers it.

 1. Add a paragraph and set it to be **hidden on Tablet** using the block’s visibility
    option.
 2. Drag the resize handles into **tablet width**. The block should hide.
 3. Drag back out to the desktop width. The block should reappear.
 4. Confirm the **device dropdown** set to Tablet hides it too, exactly as before.

### Always check the front end

After any responsive edit, verify it in **both** modes:

 * **Preview** – use the editor’s _Preview_ (the “View” / preview option) to open
   the page before publishing.
 * **Saved/published** – **Save**, then open the live URLURL A specific web address
   of a website or web page on the Internet, such as a website’s URL www.wordpress.
   org.

In each mode, resize your browser from wide to narrow – or use your browser’s device/
responsive view – through desktop, tablet, and mobile widths. Each width should 
show the style you set for it (e.g. the smaller font on mobile, the different color
on tablet), and both Preview and the saved front end should match what you saw in
the editor at the same width.

## What to expect

This is active development, so expect a few rough edges, and the UIUI UI is an acronym
for User Interface - the layout of the page the user interacts with. Think ‘how 
are they doing that’ and less about what they are doing. may still change. A couple
of things that are known or by design:

 * **Resize handles in Desktop view (post/template editor):** they may not appear
   at first because there isn’t enough space beside the canvas. Switch to Tablet
   or Mobile via the dropdown first. A follow-up is planned – see [#71210](https://github.com/WordPress/gutenberg/issues/71210#issuecomment-3195959898).
 * **Responsive editing is desktop-first:** a value you set on Desktop carries down
   to Tablet and Mobile unless you override it at that smaller viewport. So seeing
   the Desktop style on mobile (until you change it) is expected.
 * Only styles set in the block inspector (right sidebar) – font size, colors, spacing,
   etc. – apply per viewport. Block toolbar controls like alignment apply to all
   devices.

## For pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory 󠀁[https://wordpress.org/plugins/](https://wordpress.org/plugins/)󠁿 or can be cost-based plugin from a third-party. and theme developers

If your plugin or theme interacts with the editor canvas, please test it against
this build – the underlying device/canvas model has changed:

 * Code using `getDeviceType()` / `setDeviceType()` should keep working. `getDeviceType()`
   now derives the device from the canvas width, and `setDeviceType()` converts 
   a device to a width.
 * `useResizeCanvas()` is now **deprecated and a no-op**. If you rely on it, please
   tell us your use case.
 * Responsive styles work out of the box for custom blocks that use block supports(
   color, typography, border, layout, dimensions), so custom block authors can test
   on their own blocks too (Note: if a block implements custom controls instead 
   of block supports, responsive styles won’t apply to those).

## Sharing your Feedback

There are a few ways to share what you find:

 * **General feedback / UXUX UX is an acronym for User Experience - the way the 
   user uses the UI. Think ‘what they are doing’ and less about how they do it. 
   impressions:** comment on this post – it’s the best place for overall impressions
   and questions.
 * **Bugs and regressions:** open a [Gutenberg issue](https://github.com/WordPress/gutenberg/issues/new/choose)
   and reference PR [#75121](https://core.trac.wordpress.org/ticket/75121).
 * **Not sure whether it’s a bug?** Ask in the [#core-test](https://wordpress.slack.com/archives/C03B0H5J0)
   channel on the WordPress SlackSlack Slack is a Collaborative Group Chat Platform
   [https://slack.com/](https://slack.com/). The WordPress community has its own
   Slack Channel at [https://make.wordpress.org/chat/](https://make.wordpress.org/chat/).

We’d love to know, for example:

Specifics:

 * Was it clear how to turn on **Responsive editing** and which viewport you were
   editing?
 * Did the viewport badge correctly follow the device as you switched?
 * Did a per-viewport style edit stay on that viewport only, and survive a save 
   and reload?
 * Did the device dropdown and the resize handles always agree on the current view?
 * Did resizing feel smooth, or did handles get stuck or disappear unexpectedly?
 * Did the editor preview match the front end at each width?
 * Did anything feel slower, confusing, or broken?

The bigger picture:

 * How intuitive did responsive styling feel overall – were you able to do what 
   you wanted without guidance?
 * Does this solve a real problem for you? Would you use it in an actual project?
 * Anything about the overall approach that felt right, or that you’d design differently?

When reporting something, a short step-by-step with a screenshot or screen recording
helps a lot. To make a report actionable, please include:

 * The editor you used (Post, Template / Site, Pattern, or Navigation).
 * Your browser and OS, and whether it was a touch device.
 * The Gutenberg / WordPress version or PR build.
 * The active theme – especially block themes with custom breakpoints.

Props to [@huzaifaalmesbah](https://profiles.wordpress.org/huzaifaalmesbah/), [@jeffpaul](https://profiles.wordpress.org/jeffpaul/),
[@talldanwp](https://profiles.wordpress.org/talldanwp/), [@isabel_brison](https://profiles.wordpress.org/isabel_brison/),
and [@annezazu](https://profiles.wordpress.org/annezazu/) for review and feedback
on this post.

[#7-1](https://make.wordpress.org/test/tag/7-1/), [#call-for-testing](https://make.wordpress.org/test/tag/call-for-testing/),
[#core-test](https://make.wordpress.org/test/tag/core-test/), [#full-site-editing](https://make.wordpress.org/test/tag/full-site-editing/),
[#gutenberg](https://make.wordpress.org/test/tag/gutenberg/)

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Ftest%2F2026%2F07%2F03%2Fcall-for-testing-responsive-styling%2F%23respond&locale=en_US)