WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.54k stars 4.21k forks source link

Custom CSS: allow option to add for page/post and to any block on page/post #47862

Open gyurmey2 opened 1 year ago

gyurmey2 commented 1 year ago

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:

The entire point of the "per-page/post-type CSS" feature, as seen in many popular page builders for WordPress, is to be able to load CSS specifically for a page/post. For better organization and maintenance. Also, for CSS optimization - performance tools will stop complaining about unused CSS.

Adding CSS in a global input is no different than writing it in style.css. It will get loaded everywhere, even if it is not used. That's why I consider the aforementioned feature more important, because we already have ways to write global CSS (although it can and should be improved) whereas we cannot easily write specific CSS that will be 100% utilized.

However, if I don't have a way to write CSS at the post/page level, just for a specific post, page or custom post, then I will be hesitant to move from other page builders (Elementor, WPBakery etc.) that offer this feature (which makes dev life a lot easier), and put my faith in Gutenberg. It's just that important, in my own opinion. Why?

Because with global custom CSS, we'd be writing styles that are not used by all pages.

With block custom CSS, we'd be writing too specific styles that will be all over the place in a page, albeit very easy to find because they'd be attached to whatever block we'd like to change.

BUT... If we had post/page custom CSS, then we'd also be able to have a centralized place for all of the styles of a page, written in our own personalized way. That way, we wouldn't be forced to use a reusable block or change all the blocks that are sharing styles, because we'd only need to change their common classes in the page's custom CSS. It would also be great if that CSS could be stripped off its comments, get combined, minimized and cached.

Additionally, if we could have template custom CSS (need I explain this?), then we'd easily eliminate all use cases of having unused styles in a page, and certain performance tools would stop complaining about it.

Having custom CSS per block is much more useful, because there's no obvious alternative way. I hope we could have some sort of popup input with syntax highlighting because writing CSS in a tiny box at the sidebar is bothersome.

What would be even more useful, are custom CSS at the page level (be it a page, post or custom post). In other words, CSS for a specific page/post only. Most popular page builders have this feature, and if we can't have this in Gutenberg, personally it would be a good enough reason for me to not use it. It's just that useful.

@jabe64 wrote:

Exactly +1 💯 I've been waiting for this for 2 years 😩👴😅 From conversations I had with others that's one of the main drag on using Block Editor instead of page builders they've been used to. I know there is a lack of dev but I don't understand how no dev prioritize this 🤔 I still have hope for 6.2🤞🍀

https://github.com/WordPress/gutenberg/issues/30142#issuecomment-1409896058

tresorama commented 1 year ago

This should be high priority. I wrote a detailed note about this:


Current state

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:

Proposed Solution

Copy what Otter plugin does with Custom CSS and integrate in all blocks. It’s perfect.

image

Final Consideration:

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.

  1. It’s always good to have a last resort for developer.
Louis7777 commented 1 year ago

@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").

gyurmey2 commented 1 year ago

@Louis7777, nothing more, nothing less.

annezazu commented 9 months ago

No progress made on this front. Punting from 6.5.

colorful-tones commented 6 months ago

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.