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

Blocks: Introduce separate stylesheet for editor with optional theme opt-in #2905

Closed
samikeijonen opened this issue Oct 6, 2017 · 11 comments
Labels
Customization Issues related to Phase 2: Customization efforts [Feature] Blocks Overall functionality of blocks

Comments

@samikeijonen
Copy link
Contributor

samikeijonen commented Oct 6, 2017

Markup:

<hr class="wp-block-separator">

CSS:

.wp-block-separator {
	border: none;
	border-bottom: 2px solid $dark-gray-100;
	max-width: 100px;
	margin: 1em auto;
}

Many themes have styles for <hr> element so this will have styling issues with many themes. I propose removing styles from the front-end. Yeah I know then it would not match styles in the Gutenberg. That's something we need to solve.

@karmatosed
Copy link
Member

I think we need to be really cautious removing all styling. A lot of themes to be honest do styling wrong. Offering some (note some) default styling is not a bad idea.

@karmatosed karmatosed added the [Feature] Rich Text Related to the Rich Text component that allows developers to render a contenteditable label Oct 9, 2017
@samikeijonen
Copy link
Contributor Author

A lot of themes to be honest do styling wrong.

That's a bold statement even for <hr> styling. But like I said in other ticket I'm OK that all blocks have default styling.

@mtias
Copy link
Member

mtias commented Oct 10, 2017

@samikeijonen yes, this one could potentially cause some unintended issues. Can we do a quick test through a few of the top themes to see if there are obvious things we can protect from? (The twenties, etc.)

As long as we only target the class, I think we can treat this separator as a special separator—unless, obviously, the theme wants to provide their own styles for it.

@mtias mtias added [Feature] Blocks Overall functionality of blocks Customization Issues related to Phase 2: Customization efforts and removed [Feature] Rich Text Related to the Rich Text component that allows developers to render a contenteditable labels Oct 10, 2017
@samikeijonen
Copy link
Contributor Author

samikeijonen commented Oct 10, 2017

Can we do a quick test through a few of the top themes to see if there are obvious things we can protect from? (The twenties, etc.)

I can add screenshots here when I have some time. Twenty-* themes are not going to be problem though because we know to update and make small CSS tweaks to them before Gutenberg is released.

@oandregal
Copy link
Member

FWIW, this also happens with the Independent Publisher theme.

@oandregal
Copy link
Member

Could it be worth exploring the possibility of having the block class in the block section settings so users don't have to switch back to HTML to remove the class?

@mtias
Copy link
Member

mtias commented Oct 26, 2017

I think we should consider dropping automatic inclusion of some specific blocks styles that tend to always have theme styles (blockquote and hr would fall there).

@aduth aduth added the Good First Issue An issue that's suitable for someone looking to contribute for the first time label Mar 1, 2018
@aduth
Copy link
Member

aduth commented Mar 1, 2018

From the conversation, it appears there are two action items here:

  • Remove front-end styling for Separator block (move styles from styles.scss into editor.scss)
  • Remove front-end styling for Quote and Pull Quote block (move styles from styles.scss into editor.scss)

Let me know if these are incorrect.

@aduth aduth changed the title Separator block markup in the front-end Blocks: Remove front-end styling from common theme blocks Mar 1, 2018
@aduth aduth changed the title Blocks: Remove front-end styling from common theme blocks Blocks: Remove front-end styling from commonly theme-styled blocks Mar 1, 2018
@mtias
Copy link
Member

mtias commented Mar 1, 2018

@aduth we have been reducing styles for many blocks in various releases, notably the quote styles. I think we need to regroup here and introduce the notion of core_block_styles which themes might opt into supporting via add_theme_support, since many themes do want our styles (specially new ones) but many others don't. The tricky bit is how to separate structure from visuals.

Maybe we should introduce another theme.scss for blocks (next to style.scss and edit.scss? Might give an easier way to also overwrite visuals within the editor without affecting structural styles.

@aduth aduth removed the Good First Issue An issue that's suitable for someone looking to contribute for the first time label Mar 1, 2018
@aduth aduth changed the title Blocks: Remove front-end styling from commonly theme-styled blocks Blocks: Introduce separate stylesheet for editor with optional theme opt-in Mar 1, 2018
@karmatosed
Copy link
Member

Maybe we should introduce another theme.scss for blocks (next to style.scss and edit.scss? Might give an easier way to also overwrite visuals within the editor without affecting structural styles.

I really like this idea and think going forward it solves a lot of issues.

@mtias
Copy link
Member

mtias commented Mar 6, 2018

Closing in favor of #5360 as it has a wider overview.

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] Blocks Overall functionality of blocks
Projects
None yet
Development

No branches or pull requests

5 participants