{ ...blockProps } always on the parent element can make block creation more difficult #36079
Replies: 4 comments 3 replies
-
|
Hey @c4rl0sbr4v0, I have started a conversation about the same topic in #35473, in case you want to follow it 🙂 For your specific problem: have you tried using the experimental API that @oandregal introduced in #28913? I also saw that you opened a related Trac ticket: https://core.trac.wordpress.org/ticket/54319. Could you please explain a bit more the relation of that ticket with this issue? |
Beta Was this translation helpful? Give feedback.
-
Awesome! is there any way to "merge" the discussions?
Didn't use skip serialization and styles, but maybe could solve the issue. I will do some tests!
They are kind of different issues. This one is related to what you said in the other one, to find a way to be able to set where do we want the attributes to be applied, on the wrapper or on other elements of the block. The other one is related more to PHP rendering. In that ticket, the main issue is that we need a way to separate classes from styles. Right now is all in one string, and some WordPress functions have different variables for classes and other attributes. |
Beta Was this translation helpful? Give feedback.
-
I see, thanks. In any case, I guess some dynamic blocks may also need to distribute block supports features more freely between HTML markup of the block as well. I still need to study the current APIs more to get a better idea of how it works, though.
Could you please report here once you do? Thanks Carlos! 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
We created some PHP code in order to achieve the same we do with Maybe we could move it to the Core as a function and make it available for other blocks: what do you think? $spacing_attributes = isset( $attributes['style']['spacing'] ) ? $attributes['style']['spacing'] : null;
if ( isset( $spacing_attributes ) && ! empty( $spacing_attributes ) ) {
$spacing_array = array();
foreach ( $spacing_attributes as $spacing_attribute_key => $spacing_attribute_value ) {
foreach ( $spacing_attribute_value as $position_key => $position_value ) {
$spacing_array[] = $spacing_attribute_key . '-' . $position_key . ': ' . $position_value;
}
}
$spacing_string = implode( ';', $spacing_array );
}
.....
....
....
if ( isset( $spacing_attributes ) ) {
return sprintf( '<div style="%1s">%2s</div>', $spacing_string, $avatar_block );
} |
Beta Was this translation helpful? Give feedback.
-
|
I'll put this on hold for now, as we still need to figure out how to modify the current block supports system to make it compatible with declarative frontend hydration. |
Beta Was this translation helpful? Give feedback.
-
|
There is a discussion happening on how to improve the saving and rendering of block styles happening in #37495. As a result, @andrewserong opened an issue #38167 that proposes a new Styles Engine. For this particular case, the solution might be completely different while such a system is in place. At the moment the biggest limitation is that styles are injected into the markup generated inside the wrapper. That's why developers use Before HTML for the block in the content: <div class="my-block" style="color:red">
<div class="my-block__nested" style="color:green">Content</div>
</div>After HTML for the block in the content: <div class="my-block my-block-abc123">
<div class="my-block__nested">Content</div>
</div>Dynamically generated CSS styles for the block in the HTML: <style>
.my-block-abc123 {
color:red;
}
.my-block-abc123 .my-block__nested {
color:green;
}
</style> |
Beta Was this translation helpful? Give feedback.
-
|
After two years and with the styles engine. We can close this stalled discussion. Thanks everyone for your support! |
Beta Was this translation helpful? Give feedback.
-
What problem does this address?
TL:DR:
Block attributes are mostly applied to a wrapper element. What would be the best approach if we need to have some of them on the wrapper element and some of them in the inner element?
Right now, the entire approach of styling blocks is done on a wrapper HTML element. Some examples:
Image block:
Post Excerpt Block:
Using this approach, we get some benefits like:
Sometimes, an element style must be applied to the inner tag. In order to solve it, we use CSS inherit properties:
That is a good approach for many properties like margin, padding, width, height or border-radius.
But what if we want a property to be applied to the inner HTML tag? The main one? Consider we want to achieve this:
If we try to use the options provided by the block, this is what we get:
If we apply the
{...blockProps}only to the inner tag. Some attributes likepaddingormarginneed some tweaks in order to work as expected.If we apply the
{...blockProps}in both the wrapper and the main tag. Anything can happen, depending on the block. Like duplicated styles, ignored styles, etc. Not getting the desired solution both in the editor and in frontend.Of course, all of this can be solved by applying custom CSS, but we lose some part of the power of full site editing.
What is your proposed solution?
Feel free to help us find a good answer to this! Blocks are evolving, having more options, and many of them are being hard to apply due to this issue.
Could we find any way to separate between "Container Attributes" and "Element Attributes"?
Related discussions:
Beta Was this translation helpful? Give feedback.
All reactions