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

Block Supports: Allow themes to set styles when serialization is skipped #32417

Open
stacimc opened this issue Jun 3, 2021 · 7 comments
Open
Labels
Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json [Type] Enhancement A suggestion for improvement.

Comments

@stacimc
Copy link
Contributor

stacimc commented Jun 3, 2021

I'd like a flexible way to support setting specific styles via theme.json that do not target the top-level of the block: ie, block supports with __experimentalSkipSerialization enabled. It is currently difficult to do this without affecting all styles for the block. Here's an example:

#32416 adds the color block support to the Search block, and enables __experimentalSkipSerialization so that the color selections can be applied to just the Search button rather than at the block's top level:
Screen Shot 2021-06-02 at 6 10 44 PM

This works for user selections, but not when a theme sets colors in its theme.json like this:

"core/search": {
	"color": {
		"text": "blue",
		"background": "yellow"
	}
}

In this case, the styles set by the theme will get added at the top level instead of to the button. I can fix this for the color styles by setting "__experimentalSelector": ".wp-block-search__button" in the block.json -- but this setting applies to all future block supports as well.

This isn't flexible if we want to add additional block supports that should apply their styles to the top-level Search block, rather than to just the button: for example, width or typography supports.

@youknowriad
Copy link
Contributor

@nosolosw @aaronrobertshaw might have thoughts here.

@youknowriad youknowriad added the Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json label Jun 3, 2021
@oandregal
Copy link
Member

In #28913 we discussed:

Allow selectors per property, for cases in which different properties want to target different DOM elements.

Now that we're wrapping up 5.8 work, it could be a good moment to revisit.

@aaronrobertshaw
Copy link
Contributor

Given most block supports controls are disabled by default, their primary use at the moment would be through theme.json generated styles. That makes addressing this issue reasonably important in terms of using block supports in the wild.

I believe the proposal on the issue linked above is best demonstrated by this snippet:

	"supports": {
		"align": [
			"left",
			"center",
			"right"
		],
		"anchor": true,
		"color": {
			"background": true,
			"__experimentalSkipSerialization": true,
			"__experimentalSelector": ".wp-social-link"
		},
		"font-family: {
			"__experimentalSelector": ".wp-social-link a"
		}
	}

Will the bulk of the work be a matter of updating the class-wp-theme-json-gutenberg.php and global-styles-provider.js uses of the experimentalSelector?

@oandregal
Copy link
Member

I think that's one path we can take. Another one is to look at whether/how can we connect "elements" in the block.json, as we do in the theme.json: this other path is yet a bit fuzzy to me, but wanted to share as an alternative to foster further thoughts.

@aaronrobertshaw
Copy link
Contributor

This issue fits into the discussion in #33255 around managing styles for blocks with a wide design surface area.

A solution that allows us to apply styles to alternate rows in a table or nested nav menus would likely have this use case covered as well.

@ramonjd
Copy link
Member

ramonjd commented Aug 10, 2021

Also dropping image border support as a potential beneficiary for any solution we come up with: #31366

The challenge for the image block is to apply border properties to the image only, and not the enveloping <figure /> block container.

The application contrasts with say, padding and margin, which we'd want to apply to the block container.

The proposal from @aaronrobertshaw above had also occurred to me as a valid path of inquiry, as it isolates the selector within a specific support. I'm not yet sufficiently knowledgable to understand the repercussions for global styles and themes.

One head-scratcher however will be how to define further granularity for other supports, e.g.,

		"spacing": {
			"padding": {
                               "__experimentalSelector": ".wp-social-link > a"
                          },
			"margin": true,
		},

@aaronrobertshaw
Copy link
Contributor

One head-scratcher however will be how to define further granularity for other supports, e.g.,

I believe the general consensus so far is we'd be leaning more toward extending the elements API rather than expand the use of __experimentalSelector. Either way, I don't think being able to target different features, e.g. padding vs color, to different selectors will be too much of an issue.

If the elements API is opened up to allow CSS selectors in place of simple HTML elements e.g. h1, h2 etc. Each defined element/selector would encapsulate its own styles allowing greater flexibility in the theme.json styling.

An example of this flexibility could be for the image block. It could be possible to apply a border to the block's wrapper <figure> as well as a border to the <img>. Multiple padding applications become possible and so on.

I'd be interested to explore expanding the elements API in the near future once the new ToolsPanel and its surrounding work land.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

6 participants