-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Description
What problem does this address?
Currently is not possible to add custom CSS to a block instance.
By instance i mean that if you apply custom CSS to a specific core/cover block instance, no other core/cover block instance are affected by that custom CSS.
There are various custom CSS solution already discussed and merged.
#46571
#44412
These are related to custom CSS applied globally to every block of that kind.
This issue is about custom CSS per block INSTANCE instead.
Which are potential benefits of this feature ?
Gutenberg is designed that, instead of exposing the entire CSS properties set for a block (like Elementor, WebFlow) we only expose a limited amount of block settings/attributes, only necessary ones.
This is the killer feature of the Gutenberg design, because the consumer is the "Content Creator" and not the "Web Designer/Developer".
The "Web Designer/Developer"** is also a consumer of Gutenberg but his/her works is preparing the daily routine to the final "Content Creator".
Sometimes, the exposed block properties in the UI doesn't let the developer achieve his/her goal.
These are rare scenarios, but they exists.
Scenario where this feature adds value
Imagine that you know how to use CSS and, while creating your content , you feel to be 95% close to your goal, but you can’t add that missing piece because “block” you are using doesn't expose necessary CSS properties, not yet.
BUT YOU KNOW THAT WITH 2 LINES OF CSS YOU CAN ACHIEVE YOUR GOAL
Now you have these choices:
-
- Create a CSS stylesheet with a style definition and enqueue that stylesheet, (via PHP, or with a plugin that inject CSS in all pages) and link that block to that CSS via Block > Sidebar > Advanced > Custom CSS Classes.
-
- Create a custom Gutenberg Block and load it as plugin and use that block instead of original one
-
- Install a “Page Builder” Plugin that add a block with feature you are looking for.
-
- Install a plugin that enable "custom CSS per block instance".
Examine these solution:
-
- Css definition in one place (PHP or Plugin Settings) and usage in other place (Block Editor). Feels wrong (to me) and no easy to guess that some custom CSS is used.
-
- Time consuming and feels unnecessary complex, and also it requires that every block that need custom CSS should be created separatly. Feels wrong (to me).
-
- Time consuming for searcing > installing > testing plugins .
Also, why load all blocks that the plugin has just for 1 block?
Also, why load all PHP code for one block ??
Feels ok only if you are using that plugin anyway.
- Time consuming for searcing > installing > testing plugins .
-
- In my opinion the right choice at the moment.
Example plugin that does it well:Otter
- In my opinion the right choice at the moment.
What is your proposed solution?
Copy what Otter plugin does with Custom CSS and integrate in all blocks. It’s perfect.
A demo is visible in the video below.
Otter:
- Generate a unique string and append to block wrapper as css class (
ticss-131a035e) - let you write a <style> declaration in the editor UI
- inject provided custom CSS scoped to that selector
<style type="text/css" media="all">
.ticss-131a035e .wp-block-cover__inner-container{
width:100% !important
}
</style>Otter supports full css:
- media query
- pseudo element and selector
- ...
Otter does also one other UX key thing:
- When you use custom CSS at block level, you should enable the "Custom CSS" tool from a dropdown (similar to when you need to enable "Line Height" or "Letter Spacing" tools from "Typography" dropdown). Doing this ensure that only block where Custom CSS is really used has that section in the Block Inspector (sidebar). This facilitate understanding which block use custom CSS and which not.
Example of UX of this feature (using Otter)
In the following video this marketing hero is created.
The process:
Kapture.2023-02-22.at.19.47.50.mp4
Final consideration
Adding this feature is good for these reasons:
Let user add custom CSS right where it’s used. When that CSS code is not necessary anymore it can be removed safely.
If, instead, that CSS was loaded with an external stylesheet solution , how do you know if you can remove it in the future ??? How can you know which block are using that CSS ??
Orphan css is not good.
If later on, the block receives an updates that add a new feature, and this feature can replace custom CSS , the developer can remove previously added custom CSS and replace with block attributes, all in the same place.
Could be interesting, for Gutenberg dev community, to “observe” which CSS users add, in order to understand what they want to achieve and they can not at the moment.
Thanks to this we can prioritize, and add missing features to core blocks, that are really useful and required.
Obviously, user should be asked to accept that CSS will be observed, similar to a cookie policy.
It’s always good to have a last resort for developer.
