Try new syntax for dynamic selectors #24423
Conversation
oandregal
added
[Feature] Blocks
|
Size Change: -3 B (0%) Total Size: 1.15 MB
ℹ️ View Unchanged
|
|
Hi @nosolosw,
|
|
Hey Jorge, for context, I'm sharing a little exploration I did about using block variations for this #22805 If I understood correctly this proposal, this is what would happen:
Is that correct? Let me share my raw thinking on this:
I guess I'm struggling to see the value of using block variations in addition to the runtime value of attributes to compute the selector value. 🤔 Computing the selector exclusively from the runtime value of attributes seems simpler (conceptually and from an implementation point of view). |
|
Hi @nosolosw, Regarding the possible alternative using the block variations API,
No, in that case, the selector would be h3. The way to match if a variation is being used or not is not by what variation was inserted. We could use a rule for example a given variation is active if all the selectors the variation defines contain the same value in the current block instance.
We would only use a variation selector if the variation provides a selector, otherwise, we would normally use the block selector.
This case would be the most problematic with the variations approach. If that's the case I guess, one would need to specify some variations that are hidden, that just contain attributes relevant to compute the selector. But I guess this case would not be very common.
The value of using variations is that block authors would not need to learn a new API with a custom syntax they would simply use the variations API that already exists and use the normal __experimentalSelector option that already exists for blocks. |
| @@ -23,13 +23,9 @@ | |||
| "__experimentalFontSize": true, | |||
| "__experimentalLineHeight": true, | |||
| "__experimentalSelector": { | |||
| "core/post-title/h1": "h1", | |||
There was a problem hiding this comment.
It seems we have an issue both post-title and heading block map to the same CSS selectors so CSS output from one block will overwrite the CSS output of the other blocks. One post title the selector should probably also include a class.
|
Regarding the API being proposed on this PR, What would happen if the way to compute the selector needed more than one attribute? What if we have a block that uses an isInline boolean attribute when true needs a "span.wp-block-x" selector and when false needs a "div.wp-block-x" selector. Or an isVideo that is used when we need a video element but otherwise we use an image selector? Ideally, we would have some function that given the attributes returns the selector, but that would not allow us to know the selector on the server which may be needed in the future. So I think we should follow a path that allows us to know the selector on the server and the client. |
|
Going to close this in favor of #26945 which is simpler! |
Related:
Blocks that support the Global Styles system need a way to be converted to a CSS selector. At the moment, the way we do it is by using this algorithm:
If the block doesn't define a
__experimentalSelectorwithin its block.json, the selector is built based on its name:.wp-block-${ blockName }.Example:core/groupmaps to.wp-block-group.If the block does define a
__experimentalSelectorkey within its block.json and it is a string, the selector is the value of__experimentalSelector. Example:core/paragraphmaps topbecause it declares support by"__experimentalSelector": "p".If the block does define a
__experimentalSelectorkey within its block.json and it is an object, the block has as many selectors as object entries. Example:core/headingcan becore/heading/h1,core/heading/h2, ...,core/heading/h6and each one has its own selector that is defined this way:This works fine for the static nature of server-side global styles (it doesn't use the block values, only its description). However, for the dynamic nature of the client-side (particularly feature detection) we need a way to map the specific instance of a block to a particular selector. Example: the core/heading block when its level is 3 should be detected as
core/heading/h3, while it should be detected ascore/heading/h2when its level is 2.This PR proposes a new syntax for dynamic selectors:
The
attributeandexpressionwould be used client-side (or in mobile) to construct the selector based on dynamic data (the value of thelevelattribute). Therangewould be used server-side to process the block.Note that I haven't implemented the change yet because I want to gather thoughts first.