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

WordPress Trac noreply at wordpress.org
Tue Aug 13 17:43:34 UTC 2024


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

 * status:  reviewing => closed
 * resolution:   => fixed


Comment:

 In [changeset:"58890" 58890]:
 {{{
 #!CommitTicketReference repository="" revision="58890"
 Editor: Fix bumped specificity for layout styles in non-iframed editor.

 Fixes a regression introduced in [58241] which inadvertently bumped the
 specificity in a non-iframed editor for `.editor-styles-wrapper .is-
 layout-flow > *` from (0,1,0) to (0,2,0). This fix restores theme.json
 spacing rules taking precedence over the implicit spacing rules in a non-
 iframed editor.

 **The What**

 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.

 With [58241], one of the rules was changed to `.is-layout-flow > *`. In a
 iframed editor, the specificity of this rule is okay (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 before [58241], the same
 rule was `.editor-styles-wrapper :where(body .is-layout-flow) > *`
 (specificity 0,1,0). 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.

 **The How**

 This changeset modifies the selector to `:root :where(.is-layout-flow) >
 *` (still specificity 0,1,0). `transformStyles` handles 'root' selectors a
 little differently, it'll instead replace the `:root` part so it becomes
 `.editor-styles-wrapper where(.is-layout-flow) > *` (keeping the
 specificity at 0,1,0).

 The other layout selector that this affects is the `:first-child` `:last-
 child` selectors that are responsible for resetting margin at the start
 and end of a block list. They traditionally have a 0,2,0 specificity so
 that they can override both the above rule and any rules in the
 theme.json. Those selectors are also maintained at 0,2,0 with this change,
 they become something like `:root :where(.is-layout-flow) > :first-child`.

 **References:**
 * PHP changes from [https://github.com/WordPress/gutenberg/pull/64076
 Gutenberg PR 64076].

 Follow-up to [58241], [58228], [55956], [54162].

 Props talldanwp, aaronrobertshaw, andrewserong, markhowellsmead,
 ramonopoly, hellofromTonya.
 Fixes #61829.
 }}}

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


More information about the wp-trac mailing list