Extract CSS resets to reusable mixins

[youknowriad]

Global CSS resets are a bad idea and the more we move away from them, the better is for reusability.
That said, the current resets we have are not very well organized and can't be reused across pages.

With the new widgets page, we need to share these resets between the editor and the widgets page. This PR extract these resets (not all of them) to two reusable mixins:

• reset A context-agnostic reset
• wp-admin-reset A way to prepare a WordPress Admin Page to be Gutenberg based (or JS UI based)

Testing instructions

• Ensure the different Gutenberg UI elements (especially inputs and textareas...) are still showing as expected.

[youknowriad]

Ideally for reusable components using inputs/selects... we shouldn't rely on the existence of these resets because this "reset" mixins are not included in the styles of these reusable components which means if you use a given component outside of the Gutenberg context, it may not be shown properly.

This is a separate task though that should be done step by step.

[kjellr]

This works well in my testing! Just left a couple super-minor comments inline. Once we double check that post title stuff, this should be good to go. 👍

[kjellr]

In my testing (FF, Chrome, Safari for Mac), this border-radius rule seems to be the only change that's needed in this file: if I remove the changes on L10 & L53-64, this still seems to work just fine. Are we sure we need those updates?

[youknowriad]

L10 is probably not needed, I'll check but the focus style is needed in the "Spotlight Mode"

[kjellr]

I think we're missing some small-screen rules here: I just noticed our radio controls look a little weird on mobile. 😄 But that existed before this PR, and can be handled separately.

[youknowriad]

Can I get a ✅ here :)

[kjellr]

LGTM! Thanks, @youknowriad.

[youknowriad]

Thanks for the review @kjellr

[aduth]

This appears to be the cause for a visual regression in the focus style of the title.

Note the lack of right border:

[youknowriad]

👍 PR to fix it #14572

[aduth]

I think this may have caused a regression on the appearance of the "Code Editor" textarea, where the reset of .block-editor textarea in assigning font-family takes specificity priority over the code styling applied by the .editor-post-text-editor selector.

gutenberg/packages/edit-post/src/style.scss

Lines 64 to 68 in 70cc953

	.block-editor,
	// The modals are shown outside the .block-editor wrapper, they need these styles
	.components-modal__frame {
	@include reset;
	}

gutenberg/packages/editor/src/components/post-text-editor/style.scss

Line 1 in 70cc953

.editor-post-text-editor {

(011 vs. 010)

Before	After

Aside: Should .block-editor styles be applied at edit-post/src/style.scss?

[afercia]

Noting that with this change, all the rules related to inputs now apply also to the metaboxes area and to the custom fields area, see for example Yoast/wordpress-seo#13316

The reason is simple:

• before: all the input rules were scoped to specific parts of the Gutenberg UI:

.editor-post-permalink,
.edit-post-sidebar,
.editor-post-publish-panel,
.block-editor-block-list__block,
.components-popover,
.components-modal__content 

• after: they're in the new mixin which is scoped to .block-editor and .block-editor is the Gutenberg main container, which includes both the metaboxes and custom fields areas.

In other words, this change breaks UIs provided by plugins. It should either be communicated to plugin authors well in advance so they can adjust their CSS or (preferably) the new mixin should be better scoped.