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.

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

Add options/hooks to remove highly opinionated styles and blocks #8666

Closed
cbirdsong opened this issue Aug 7, 2018 · 5 comments
Closed

Add options/hooks to remove highly opinionated styles and blocks #8666

cbirdsong opened this issue Aug 7, 2018 · 5 comments
Labels
Customization Issues related to Phase 2: Customization efforts [Feature] Extensibility The ability to extend blocks or the editing experience [Type] Enhancement A suggestion for improvement.

Comments

@cbirdsong
Copy link

cbirdsong commented Aug 7, 2018

Many of Gutenberg's default blocks/styles are extremely opinionated, and while retrofitting themes to work with it I've found a lot of the default options often conflict with existing styles.

I think it’s fine if the current defaults are the new baseline for theme authors to aim for, but it would be best if an option existed to remove or disable many of the features that will be particularly problematic to deal with when adding Gutenberg to existing sites, or for extremely specific designs in the future.

Some of the big offenders:

Paragraphs and Lists

Text sized using the small/medium/large buttons uses pixel sizes instead of em-based sizing that could inherit from existing theme styles. This can be overridden in CSS along with custom values in add_theme_support( 'editor-font-sizes'), but then I have to remember to go and update that if the baseline body copy font size changes. An em-based default seems preferable.

Text sized using the font size slider gets an inline style=“font-size: ;”, which then can’t be overridden with CSS short of !important. It can also get insanely big, which many themes simply aren’t designed handle, since TinyMCE didn’t include a font size selector by default.

Drop Caps

Not all fonts work well with the default font size/line height/margins attached to .has-drop-cap:

drop cap example

The float also really needs to be accounted for in the CSS, as discussed in #8447. Something like add_theme_support( 'editor-drop-caps') seems ideal.

Buttons

They’re round, they’re black, they look completely out of place, and they often lose specificity, depending on how links were previously styled.

button example

I don’t see an easy way for these to inherit styles from the parent theme and would prefer they just default to simple text links, particularly in the file download block.

Blockquotes

The standard quote style fits right in with a semantically styled <blockquote>/<cite>, but once you tick the “large” style on it breaks because it includes margin/padding resets.

blockquote/large blockquote comparison

Pull Quotes

The “pull quote” block looks different from a blockquote in the editor, but then looks just like a blockquote unless specific styles are added for . wp-block-pullquote.

pull quote in the editor
pull quote in the site


This is my first issue, so I apologize if any of this has been discussed or dismissed in the past, or if this should be broken into multiple issues.

@designsimply designsimply added [Type] Enhancement A suggestion for improvement. [Feature] Extensibility The ability to extend blocks or the editing experience labels Aug 7, 2018
@designsimply
Copy link
Member

I checked the Gutenberg handbook and found this:

Core blocks include default styles. The styles are enqueued for editing but are not enqueued for viewing unless the theme opts-in to the core styles. If you’d like to use default styles in your theme, add theme support for wp-block-styles.

https://wordpress.org/gutenberg/handbook/extensibility/theme-support/#default-block-styles

There is also a discussion around how to dequeue theme.css at #7776 and the discussion is mainly around how styles are enqueued in the editor but there's also a note about how to dequeue styles on the front end at #7776 (comment)

If those notes do not answer your questions, could you let me know in a reply here and tell me a little more about your end goal and how I can help you reach it?

@designsimply designsimply added Customization Issues related to Phase 2: Customization efforts [Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed labels Nov 16, 2018
@onetrev
Copy link

onetrev commented Mar 15, 2019

I think the OP's request, or at least mine is, that developers may not want to blanket dequeue ALL Gutenberg styles on the front end. The problem with that is then you have to re-create all these styles again in our custom theme.

Instead, there should be a way to just remove some element styles -- i.e. button styles. That way we aren't left with having to overwrite all the default button styles. It's particularly annoying you have to do this when you've already unregistered the button like so:

wp.blocks.unregisterBlockStyle( 'core/button', 'default' );

The extra frustration is then when you've unregistered all the included button styles, then registered your own button style names, however you then still have the default button styles on the front end that you have to overwrite.

@designsimply
Copy link
Member

Thank you for clarifying! I think that makes it different enough to re-open separately from #7776 to get another opinion/review.

@designsimply designsimply reopened this Apr 15, 2019
@designsimply designsimply added Needs Decision Needs a decision to be actionable or relevant and removed [Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed labels Apr 15, 2019
@mtias
Copy link
Member

mtias commented Nov 17, 2019

The extra frustration is then when you've unregistered all the included button styles, then registered your own button style names, however you then still have the default button styles on the front end that you have to overwrite.

There's already a mechanism for moving opinionated styles to theme.scss in core blocks so that they are only loaded if the theme does add_theme_support( 'wp-block-styles' ). There might be cases where this is not properly setup for a specific block, and it'd be great to open a proposal for those on how to split the styles between structure and appearance.

@mtias mtias closed this as completed Nov 17, 2019
@mtias mtias removed the Needs Decision Needs a decision to be actionable or relevant label Nov 17, 2019
@onetrev
Copy link

onetrev commented Nov 17, 2019

Sorry if I'm missing something, but I haven't used add_theme_support( 'wp-block-styles' ), however my custom button styles for core/button are still loading the default styles.

// ++ create custom button style names + remove included buttons styles
wp.blocks.registerBlockStyle( 'core/button', {
    name: 'standard',
    label: 'Standard Button'
} );

wp.domReady( () => {
	wp.blocks.unregisterBlockStyle( 'core/button', 'default' );
	wp.blocks.unregisterBlockStyle( 'core/button', 'outline' );
	wp.blocks.unregisterBlockStyle( 'core/button', 'squared' );
} );

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Customization Issues related to Phase 2: Customization efforts [Feature] Extensibility The ability to extend blocks or the editing experience [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

4 participants