[wp-trac] [WordPress Trac] #61829: Some layout styles have increased specificity in WordPress 6.6 within the non-iframed editor

[WordPress Trac]

#61829: Some layout styles have increased specificity in WordPress 6.6 within the
non-iframed editor
-------------------------------------------------+-------------------------
 Reporter:  talldanwp                            |       Owner:
                                                 |  hellofromTonya
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  6.6.2
Component:  Editor                               |     Version:  6.6
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests has-        |     Focuses:
  testing-info gutenberg-merge commit fixed-     |
  major dev-feedback                             |
-------------------------------------------------+-------------------------

Old description:

> Ticket for backporting the changes in
> https://github.com/WordPress/gutenberg/pull/64076.
>
> == Description
>
> When the block editor is not iframed (which can happen when Custom Fields
> are active, or blocks that use and older `apiVersion` are present), style
> rules are processed using post css to append the `.editor-styles-wrapper`
> class name. This has the effect of scoping the the style rules to ensure
> they don't affect the editor chrome or admin.
>
> In WordPress 6.6, one of the rules was changed to `.is-layout-flow > *`.
> In a iframed editor, the specificity of this rule is ok (0,1,0), but in a
> non-iframed editor it becomes `.editor-styles-wrapper .is-layout-flow >
> *`, a specificity of (0,2,0). Comparing this to 6.5, the same rule was
> `.editor-styles-wrapper :where(body .is-layout-flow) > *` (specificity
> 0,1,0). So this is a regression in specificity that has caused some
> issues. Notably themes can no longer properly override the spacing for
> blocks using theme.json and have the results correctly shown in the non-
> iframed editor.
>
> == Testing Instructions
> 1. Add some very obvious margin rules to your theme.json like this for
> paragraphs (under `styles.blocks`):
>

> {{{
> "core/paragraph": {
>         "spacing": {
>                 "margin": {
>                         "top": "4rem",
>                         "bottom": "4rem"
>                 }
>         }
> },
> }}}
>

> 2. Create a new post. Ensure you don't have custom fields active.
> 3. Insert 3 paragraphs with text, check that the margin looks right. The
> first paragraph should have no top margin, the last no bottom margin, but
> in all other cases there should be `4rem` top/bottom margin.
> 4. Activate Custom Fields in the editor preferences to 'un-iframe' the
> editor
> 5. Observe that the block spacing is now incorrect
>
> == Screenshots or screencast
> ==== Actual
> [[Image(https://github.com/user-
> attachments/assets/1e053fe1-d942-4f71-8a53-ea478b26c0b4)]]
>
> ==== Expected
> [[Image(https://github.com/user-attachments/assets/ffb33f68-cf8f-42eb-
> 916c-af4d189d428e)]]

New description:

 Ticket for merging the changes in
 https://github.com/WordPress/gutenberg/pull/64076.

 == Description

 When the block editor is not iframed (which can happen when Custom Fields
 are active, or blocks that use and older `apiVersion` are present), style
 rules are processed using post css to append the `.editor-styles-wrapper`
 class name. This has the effect of scoping the the style rules to ensure
 they don't affect the editor chrome or admin.

 In WordPress 6.6, one of the rules was changed to `.is-layout-flow > *`.
 In a iframed editor, the specificity of this rule is ok (0,1,0), but in a
 non-iframed editor it becomes `.editor-styles-wrapper .is-layout-flow >
 *`, a specificity of (0,2,0). Comparing this to 6.5, the same rule was
 `.editor-styles-wrapper :where(body .is-layout-flow) > *` (specificity
 0,1,0). So this is a regression in specificity that has caused some
 issues. Notably themes can no longer properly override the spacing for
 blocks using theme.json and have the results correctly shown in the non-
 iframed editor.

 == Testing Instructions
 1. Add some very obvious margin rules to your theme.json like this for
 paragraphs (under `styles.blocks`):


 {{{
 "core/paragraph": {
         "spacing": {
                 "margin": {
                         "top": "4rem",
                         "bottom": "4rem"
                 }
         }
 },
 }}}


 2. Create a new post. Ensure you don't have custom fields active.
 3. Insert 3 paragraphs with text, check that the margin looks right. The
 first paragraph should have no top margin, the last no bottom margin, but
 in all other cases there should be `4rem` top/bottom margin.
 4. Activate Custom Fields in the editor preferences to 'un-iframe' the
 editor
 5. Observe that the block spacing is now incorrect

 == Screenshots or screencast
 ==== Actual
 [[Image(https://github.com/user-
 attachments/assets/1e053fe1-d942-4f71-8a53-ea478b26c0b4)]]

 ==== Expected
 [[Image(https://github.com/user-attachments/assets/ffb33f68-cf8f-42eb-
 916c-af4d189d428e)]]

--

Comment (by hellofromTonya):

 Pinging committers involved in this change for a 2nd committer sign-off to
 backport it to the 6.6. branch for 6.6.2 RC1 on Sep 4th.

 @aaronrobertshaw @andrewserong @talldanwp

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61829#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform