Open gyurmey2 opened 1 year ago
This should be high priority. I wrote a detailed note about this:
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”s you are using don’t let you do what you want to achieve. BUT YOU KNOW THAT WITH 2 LINES OF CSS YOU CAN ACHIEVE 100% .
Now you have these choices:
Examine these:
Copy what Otter
plugin does with Custom CSS and integrate in all blocks. It’s perfect.
Adding this feature is good for these reasons:
1. Let user add custom CSS right where it’s used. When that CSS code is not necessary anymore it can be removed safely. (Tailwind approach) If , instead, that CSS was loaded with a external stylesheet solution , how do you know that you can remove it in the future ??? How can you know which block are using that CSS ??
2. If later on, the block receives an updates that add a new feature, and this feature can replace custom CSS , this can be done in an easy way.
3. Could be interesting to “observe” which CSS users add, to understand what they want to achieve and they can not. 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.
@tresorama
4. In my opinion the right choice at the moment. Example plugin that does it well: “Otter”
Agreed, although it needs some obvious improvements, such as syntax highlighting and the ability to horizontally increase the size of that editing area (it's annoying trying to type and organize your CSS in such a small box at a sidebar) - perhaps also opening it in a popup.
While I consider custom CSS per block a necessary feature to have, I believe that an even higher priority should be custom CSS per post/page. That way you'll have your custom CSS organized in one place, loaded only for that page/post/template, for all of its own blocks, and you'll only have to add classes to those blocks ("via Block > Sidebar > Advanced > Custom CSS Classes").
@Louis7777, nothing more, nothing less.
No progress made on this front. Punting from 6.5.
Hi folks, We are only one week away from the Beta 1 cut-off date for WordPress 6.6. This issue hasn’t seen any movement in a while, so we (the editor triage leads of the 6.6 release) have decided to remove it from the WordPress 6.6 Editor Tasks project board.
Why?
This will unleash full creative potential, including the ability to add negative margins (right now, you don’t have the ability to add a negative margins to any element, but they are highly useful for achieving some layouts).
Also, the comments below best describe how important this feature is.
Louis7777 wrote:
@jabe64 wrote:
https://github.com/WordPress/gutenberg/issues/30142#issuecomment-1409896058