Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Block Editor 's shadow DOM of edited page: <body> misses many classes upon which CSS selectors may depend: such as page-template-*, page-id-*, post-type-* , etc #51353

Closed
porg opened this issue Jun 8, 2023 · 8 comments
Closed

Block Editor 's shadow DOM of edited page: <body> misses many classes upon which CSS selectors may depend: such as page-template-*, page-id-*, post-type-* , etc #51353

porg opened this issue Jun 8, 2023 · 8 comments
Labels
CSS Styling Related to editor and front end styles, CSS-specific issues. [Type] Enhancement A suggestion for improvement.

Comments

@porg
Copy link

porg commented Jun 8, 2023 •
edited
Loading

WordPress Block Editor shadow DOM body misses many classes which may be used as legitimate CSS selectors

Problem

In the shadow DOM of the Block Editor the <body> element misses many classes which may be legitimately used as a CSS selector. Such as those which are specific for a content-type (post vs. page) or template or certain page-IDs.

Proposed Fix / Improvement

Include the relevant classes like in the <body> of the Frontend output in the Block Editor shadow DOM too, except of course those which are Frontend runtime specific (such as Logged-In, or those coming from plugins and their dynamic runtime state).

Reproduction

My CSS selector in my enqueued global.css file

                      .page-template-default section:nth-child(2n + 2) { background-color: var(--wp--preset--color--tertiary) !important; }

Which in the enqueued representation gets:

.editor-styles-wrapper.page-template-default section:nth-child(2n + 2) { ... }

  • ✅ In the Frontend this works:

    • On a page with the "Default" page template
    • Every second section (Group block with section as its html type) has a gray background color.

  • ❌ In the Block Editor this has no effect.

After debugging I found out why:

  • Output in Frontend:

    <body class="page-template-default page page-id-1571 page-child parent-pageid-24 logged-in admin-bar no-customize-support wp-custom-logo wp-embed-responsive gspbody gspb-bodyfront mega-menu-max-mega-menu-1 mega-menu-max-mega-menu-2" style="position: relative;">

  • Shadow DOM in the Block Editor:

    <body class="block-editor-iframe__body editor-styles-wrapper post-type-page admin-color-fresh wp-embed-responsive" tabindex="0" contenteditable="false">

Realization

A lot of classes are missing in the Block Editor environmnet, which should be there, because it's legit to use them as CSS selectors:

  • Some classes are only mode/runtime relevant, and are ok to be left out in the body of the Block Editor Shadow DOM:

    • admin-bar
    • no-customize-support
    • wp-custom-logo
    • wp-embed-responsive
    • gspbody
    • gspb-bodyfront
    • mega-menu-max-mega-menu-1
    • mega-menu-max-mega-menu-2

  • But it is very legit to have CSS styles specifically for:

    • page || post
    • page-template-*
    • page-id-*
    • page-child
    • logged-in

  • These should be present in the Block Editor too!

Environment

  • WordPress 6.2
  • Gutenberg 15.9.1
  • Safari 16.5 on macOS 11.7.6 Big Sur

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

No
@kathrynwp kathrynwp added [Type] Enhancement A suggestion for improvement. CSS Styling Related to editor and front end styles, CSS-specific issues. labels Jun 26, 2023
@MaggieCabrera
Copy link
Contributor

I can confirm this, I was working on a theme that was relying on the .error-404 class to style that page and saw that the classes are missing in the editor. That leads to inconsistencies between editor and frontend for themes that rely on the classes.

@MaggieCabrera MaggieCabrera mentioned this issue Jun 12, 2023
Open
@ellatrix
Copy link
Member

I think this is a duplicate of #17854?

@spencerfinnell
Copy link

spencerfinnell commented Aug 15, 2023 •
edited
Loading

Related/duplicate of:

@annezazu
Copy link
Contributor

annezazu commented Sep 7, 2023

Let's close this out as it seems to be a duplicate of the above items. If that's incorrect, please comment back on here and I'll reopen!

@annezazu annezazu closed this as completed Sep 7, 2023
@github-project-automation github-project-automation bot moved this from Triage to Done in WordPress 6.4 Editor Tasks Sep 7, 2023
@spencerfinnell
Copy link

@annezazu can you please reopen #13339 for visibility. The issue was closed without addressing the original report.

@annezazu
Copy link
Contributor

annezazu commented Sep 8, 2023

@spencerfinnell looking that over, I think the current issue reported there is covered by work around having style partials as mentioned here: #39281 Does that match your understanding?

@spencerfinnell
Copy link

spencerfinnell commented Sep 8, 2023 •
edited
Loading

@annezazu No, that still requires an element/group/block to be inserted. #13339 refers to an additional class being applied to the editor's body based on the page template being applied -- not the content on the page.

@spencerfinnell
Copy link

#13339 refers to the client-side implementation of https://developer.wordpress.org/reference/functions/body_class/ which does not exist as far as I am aware.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
CSS Styling Related to editor and front end styles, CSS-specific issues. [Type] Enhancement A suggestion for improvement.
Projects
Automattic team Ignite's project board
Archived in project
WordPress 6.4 Editor Tasks
Status: Done
Milestone
No milestone
Development

No branches or pull requests
6 participants
@spencerfinnell @porg @MaggieCabrera @ellatrix @kathrynwp @annezazu