Add block-editor class to site editor. #27724
Conversation
Addison-Stavlo
requested review from
spacedmonkey and
TimothyBJacobs
as code owners
Addison-Stavlo
requested review from
noahtallen,
youknowriad,
vindl,
mattwiebe,
Copons,
david-szabo97 and
jeyip
|
Size Change: -37 B (0%) Total Size: 1.28 MB
ℹ️ View Unchanged
|
Addison-Stavlo
removed request for
mattwiebe,
spacedmonkey,
youknowriad,
vindl,
Copons,
david-szabo97,
TimothyBJacobs,
jeyip and
noahtallen
Addison-Stavlo
requested review from
noahtallen,
youknowriad,
vindl,
mattwiebe and
Copons
Addison-Stavlo
requested review from
david-szabo97,
jeyip,
spacedmonkey and
TimothyBJacobs
|
My question here would be why blocks are using this class? It seems block styles should be context agnostic instead of adding more boilerplate to editors. |
|
It makes sense to me. Since |
1000% agree. And the ones I have seen that are problematic are fixing this on their end. However, it did make me wonder if we should be adding this class to the site editor anyways. |
|
hah :) For me, I was wondering whether we should remove it from the post editor instead :P |
|
I'm not familiar how third-parties are targeting the block editor in CSS. But using |
My question would be why? I'm not suggesting to target edit-post and edit-site, I'm suggesting that blocks shouldn't need any global classname. |
|
I don't have any example handy, but I do recall some blocks having issues in the Site Editor for the lack of the I don't have a strong opinion on whether we should add the class to the Site Editor or remove it from the Post Editor, as long as we keep them consistent. IMHO, parity is more important than one redundant class. This said, we don't have control over existing third-party blocks. If we decide to remove the class from the Post Editor, we'll need to do it gradually, with a deprecation path or some sort, to allow for plugin developers to update their blocks. |
Yes, My opinion is that we should do a dev note about that and potentially a deprecation message on the console.
I disagree with that, the site editor is experimental and it's actually a good way to encourage people to remove that requirement from their blocks. It's also not the only class that is present in edit-post and not in edit-site, there are a lot of them (all edit-post-* classes) so consistency is not possible and it just means more boilerplate for folks that want to use custom block editors. (Think edit-site, edit-widgets, edit-post, p2, asblocks, drupal Gutenberg...) |
Right, it makes sense. |
Description
Q - Should we have the
.block-editorclass in the site editor? It is an implementation of the block editor, although distinct from the post editor which also relies on this class. cc @youknowriad any thoughts?Plugins and 3rd party blocks may often end up requiring the
.block-editorclass for their css styles to be applied. This class was never added in the site editor causing these blocks to not function as expected and potentially break the layout when loaded in the site editor. This PR adds this class to the site editor, on the same element corresponding to where it would be present in other editors.How has this been tested?
Smoke test the site editor and verify styles aren't broken.
Screenshots
Types of changes
Checklist: