High specificity paragraph styles

[inc2734]

Thank you for the wonderful development.

I think that many themes basic text colo set to body. But, in the current editor style of Gutenberg, since the text color style is also applied to the paragraph, the editor and the actual page display different character colors.

This styles are written on /build/edit-post/style.css. I tryed dequee it. As a result, Not only the style of blocks and HTML elements, the style of the whole editor has disappeared.

I propose that you should delete the style below or split it into HTML elements and other styles.

https://github.com/WordPress/gutenberg/blob/master/edit-post/components/visual-editor/style.scss#L7-L16

These problems also apply to line-hight and list margin.

How about that?

Thank you and regards.

[jasmussen]

Thanks for a great ticket!

Forgive me if I misunderstand you, and please correct me if that is the case. But as I understand it, the objection is to the highly specific .edit-post-visual-editor selector. This is partially intentional, partially an upstream WordPress core issue.

The classic WordPress editor exists inside an iframe, which means you can have unscoped generic selectors for elements, and not worry about the CSS styles bleeding into the rest of the admin. Not the case here. The CSS is specific for two reasons:

1. It has to override base styles provided by WordPress core for wp-admin.
2. It has to be scoped so as to not bleed into the rest of the admin.

There's a good argument for 1 being solved by the selector for the rest of the admin being more specific, but this should be an upstream ticket filed on trac, you're welcome to do that here: https://core.trac.wordpress.org/

2 is necessary so as to prevent this from happening:

☝️ that's what a plain paragraph would look like if we removed the .edit-post-visual-editor part. We could of course scope the rest of the Gutenberg UI to have its own CSS for paragraphs that override the preceeding code.

I would welcome a patch or code example, if you have ideas for how to address this!

[pascalknecht]

I completely agree with @inc2734 . Some of the styles of gutenberg leak into my components. One of this is the mentioned p element but also .wp-core-ui .button, .wp-core-ui .button-secondary leaks into my component. For the button components one should use a more specific class name in my opinion.

[jasmussen]

CC: @youknowriad, will recent experiments help address this?

[inc2734]

@jasmussen

1. It has to override base styles provided by WordPress core for wp-admin.
2. It has to be scoped so as to not bleed into the rest of the admin.

I see ! understood. However, it seems that style is too strong for p. Because, If I removed the style related to p from /plugins/gutenberg/build/edit-post/style.css, the following admin style remained.

p {
    font-size: 13px;
    line-height: 1.5;
    margin: 1em 0;
}

p is easier to overwrite than .edit-post-visual-editor p .

I understand that .edit-post-visual-editor p is necessary for a theme not compatible with Gutenberg, but depending on the theme it is unnecessary, so I think that it is better to be able to opt out.

I don't know how the CSS of the Gutenberg plugin is made now, so I will investigate and try making a patch if I can do it. Thank you.

[chrisvanpatten]

I've been stymied by this as well. I have a custom block which allows setting a background and foreground color, and also contains an <InnerBlocks /> area. Ideally, I could just set the background and foreground and have the nested/child block inherit from the parent colors; this works on the front-end but not in the editor itself:

(I don't have a good solution in mind at the moment… definitely wishing the Shadow DOM was a bit better supported though!)

[youknowriad]

That's exactly what my experiment is trying to resolve, it would force us to "rework" our styles a little bit (to use the same wrapper used for theme styles) but it should work. A more detailed comment here:

#9008 (comment)

[ZebulanStanphill]

Quoting myself from the Slack (relevant part bolded):

I have been working on a proof-of-concept Container block. One of the things I tried to add were text settings. I figured that setting the text color for an entire section would be useful (and reduce the need for color options on individual blocks like Heading/List), so I tried adding that and other text-related settings.

Everything seemed to work on the front-end.

However, in the editor, the default styles of some blocks overrode the ones set in the Container.

• Text alignment worked fine for everything.

• Text color did not work with the Code, Heading, Paragraph, Preformatted, and Verse blocks.
• Font size did not work with the Code, Paragraph, and Preformatted blocks.

Would this be considered an issue with the specificity of some of the block styles?

Also, if anyone is interested in what I have done so far with my Container prototype, you can check it out on this branch:

https://github.com/ZebulanStanphill/gutenberg/tree/try/container-block

Once I have added some more features to it, I plan on creating a PR for it as a last attempt to try and get a Container block before the WordPress 5.0 release. I don't really expect it to make it in, though, and if it does not make it into 5.0, I will try and release the block as a plugin instead.

[designsimply]

Now that improvements editor styles have been made to avoid specificity issues in #9008 and #10956, is it enough to close this issue?

[chrisvanpatten]

@designsimply I do think this is largely solved by #9008 and #10956. We can definitely re-open if something specific/actionable comes up! :)