Global Styles: use CSS variables to mark block style hooks #22317
Conversation
oandregal
added
the
Global Styles
Why not just? I'm asking cause when we originally tried the CSS variables approach for these styles (color, background, gradient), we had cascade issues, applying a gradient to a container applies it to all its children. Not saying we shouldn't use CSS variables at all but I'm thinking more that they are more useful for what I call the "branding configs" (link-color, gridd-size-unit...) |
|
Size Change: 0 B Total Size: 828 kB ℹ️ View Unchanged
|
|
For your particular use-case (tweaking the number of a features pattern) I'd solve it like that: Register a "number" style variation for the paragraph block with the following style: and on the pattern markup apply that style variation (I'm assuming the pattern comes from the theme itself). If the pattern doesn't come from the theme itself, I don't see any way of solving the issue, since it's not conceivable that a theme would style all patterns available (imagine a repository of patterns). |
The reason is that this doesn't solve the specificity issues, so themes will still have to try to "win" over core declarations if any. It'll be like #20290 but without addressing nested content. I'm happy to try that approach, but my feeling is that it's not enough. Which takes me to the question I posed in the other thread: from a theme author perspective, what'd be the advantage of using theme.json in this case over using regular CSS?
Yeah, I understand that and I'm glad that you brought those issues up. That's mainly why I explored #20290 without CSS variables! |
I'm not sure how #20290 is any different in that regard though, you still need to know what properties are made available by blocks and patterns that come from the repositories (am I missing something) |
I like that and actually thought about it myself. The problem I see with this approach is that we need to create multiple styles for the block paragraph to cover every pattern, cluttering the UI. Also: when you change themes, everything is messed up if the variation comes from the theme itself. One potential way out would be if we were able to "filter" style variations by block and context so they're only shown in particular contexts. Not sure I like this idea, but talking out loud in case it moves the conversation forward. |
Same answer: The main advantage is for the "global" config. you'd be able to define properties that work across blocks without knowing how these blocks will use them (especially useful for the branding configs) |
| ), | ||
| 'core/columns' => array( | ||
| 'supports' => array( 'color' ), | ||
| 'selector' => '.wp-block-columns', |
There was a problem hiding this comment.
Would it be ok to use class selectors as a default and not provide the selectors explicitly?
|
Is this PR still relevant? It seems #20290 also does what is being done here. |
|
Yeah, this is different in that it "marks" the blocks with CSS variables, but it looks like #20290 has got enough momentum and support, so we can close this for now. |
Continues work from: #19883 #20047
Alternative to #20290
See larger picture at #22296
This PR takes a different stance than #20290 so should be considered an alternative. Note that this is a Proof of Concept, to share direction and gather feedback. The idea is that we take the implicit attributes declared from blocks and make them CSS variables bound to that block.
Input. Let's say the paragraph block declares through its settings that it has support for some implicit attributes and also provides a CSS selector:
Output. We enqueue a new embedded stylesheet for that block that looks like this:
Unlike #20290 this doesn't try to provide a way to "manage CSS" so it's the theme responsibility to set the values of the variables for the contexts in which a block can be used (top-level document, within a pattern, etc).
A theme should do something along this lines: