Reduce element selectors for editor css to avoid specificity issues for block authors

[billcolumbia]

Describe the bug enhancement
Update: Upon seeing the update for 3.8, I noticed some of this is gone. Which is nice! :D But there is still a property coming through:

.editor-block-list__block, .editor-block-list__block p {
  font-size: 16px;
}

Before update:
Ideally, there would be no generic element selectors in the editor styles. This would allow opt-in to Gutenberg styles. These selectors below...

.edit-post-visual-editor, .edit-post-visual-editor p {
    font-family: Noto Serif,serif;
    font-size: 16px;
    line-height: 1.8;
    color: #32373c;
}

...requires our custom block's css to fight for higher specificity to get our own colors, fonts, etc working as expected. My team and I are willing to help work on a PR for this.

To Reproduce
Steps to reproduce the behavior:

1. Create any block that renders a <p> tag.
2. Add some text
3. Inspect that p tag in browser dev tools
4. Notice the selector chain:

.edit-post-visual-editor, .edit-post-visual-editor p {...

Expected behavior
We expected that custom blocks, that implement p tags, would not have to override the styles declared by the editor's css selectors. It was expected that a class could be optionally added to p tags (or any markup) in custom blocks, components, or controls to achieve a 'default' Gutenberg style.

I've added this example below to illustrate a possible solution (it does not account for possible class name collisions at the moment, and could certainly be much better named. I've replaced the p selector with other ideas for selectors:

.edit-post-visual-editor .block-p {
  /* ...properties */
}

/* maybe even more ideal, no depth selector, reducing specificity even more */
.gutenberg-block-p { /* ... */ }

/* Attempting to follow Gutenberg CSS Naming standards */
.editor-generic_ptag { /* ... */ }
.editor-general_ptag { /* ... */ }
.editor-blocks_ptag { /* ... */ }
.editor-element_p { /* ... */ }
.editor-el_p { /* ... */ }

I'm looking into the CSS naming conventions for Gutenberg now, to further my example if that can be applied here. There is no directory, for the second piece of the selector though, so I've substituted words like generic, general, element, for now.

Additional context
N/A

Thanks for reading :)

[mrpritchett]

I second this. The specificity here is too narrow for something that is supposed to be built on top of when the only true alternative to highly specific styles for all things in the editor is NO styles. Those two extremes aren't great options for a foundation to build upon.

[designsimply]

Have you tested the more sophisticated Editor Styles mechanism announced for 3.8?

This is from the release notes:

Implement a more sophisticated Editor Styles mechanism. 🖍 It allows themes to register editor styles for blocks by targeting the blocks themselves without having to fight CSS specificity, and without having to know the internal DOM structure for the editor.

Source: https://make.wordpress.org/core/2018/09/12/whats-new-in-gutenberg-12th-september/

And this is the related PR: #9008

Can you check to see if it answers your question?

[billcolumbia]

Hi @designsimply - Taking a look at this, thanks for the heads up.

[billcolumbia]

This doesn't seem to solve the issue for us, and prevents css injection / HMR. We are currently using postcss to prefix our editor styles (similarly to the solution in that PR) to get around this issue.

[billcolumbia]

I will close for now though :)