Additional CSS - hidden by design

[burnuser]

Description

Additional CSS should work like same option in customizer.
And in was OK in Gutenberg 15.0
But hidden by design in 15.1 behind 3 dots menu, where no one would ever look for it!
Congratulations! (It was not hidden in Customizer, why hide it in styles?)

But to make it really crazy: It is always visible - like it should be - in styles of individual Blocks!
Which additional visible whole site CSS option in 3 dots menu above - to make it confusing as possible.
Which - after inserting some CSS - appears in the interface. => Design by miracle!

If You do not want anybody using additional CSS, don't implement it! - But implementing it and hiding it afterwards is useless.

Step-by-step reproduction instructions

1. Take a regular WordPress user
2. Put him into Styles
3. Order: Add CSS
4. See if he/she will find the option - or not.

Screenshots, screen recording, code snippet

No response

Environment info

WP 6.1 - Betatester
Gutenberg 15.1.0 RC1

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[Mamaduka]

cc @richtabor

[ghost]

I agree with the issue.

[richtabor]

This is a tough one. Ideally block themes wouldn't need custom CSS — instead leveraging Global Styles to personalize every block added to the site. The more custom CSS added, the more likelihood of styles breaking/conflicting with Global Styles.

But its important for advanced users to be able to extend with custom CSS, so its added to Global Styles — but not front-and-center, to reduce the likelihood of it causing unintentional confusion/conflicts.

And once you add custom CSS, it'll be visible at the top-level of Global Styles, so you don't have to keep opening up the menu item for it. 👍

[ghost]

I believe this issue wasn't opened for lack of understanding about the change. We already know this. I praise the concern behind it, but it seems to be an overengineered change to me and maybe for the author too. It brings unnecessary logic about how it works, when it appears or not, and it is bad positioned now. I understand it may be subjective our point of view regarding the best position, but yours seems too. What is the criteria for menu items in this context? Normally they are help, tools, and secondary actions.
Additional CSS is not a secondary action. It is going to be used, people want it, and conflicts and solutions emerge from its inherent existence. This is not a problem.
My feedback and point of view: additional CSS was already deprioritized in the UI, when it was not listed among the first items on the sidebar... It was the last or penultimate. There was a wide separator indicating its less important section. And there is a description before entering and after entering the Additional CSS feature. Make a good use of it, to simply discourage its use then. "Cautious", "warning" messages...

[glendaviesnz]

Maybe an Advanced section at the bottom of the right panel, that is collapsed by default, would be an alternative way of not having Custom CSS front-and-centre, but more discoverable than in the top ellipsis menu?

[richtabor]

My feedback and point of view: additional CSS was already deprioritized in the UI, when it was not listed among the first items on the sidebar... It was the last or penultimate. There was a wide separator indicating its less important section. And there is a description before entering and after entering the Additional CSS feature. Make a good use of it, to simply discourage its use then. "Cautious", "warning" messages...

Because of the complexities/inherit challenges you'll run into applying custom CSS globally to blocks (in lieu of using Global Styles), the Additional CSS control should not have the same weight as styling all the blocks. That's not subjective, but cautionary.

If you're an advanced user, and want to add additional CSS to your site, you take the extra step to enable it. That extra step is imperative to reducing those complexities for non-advanced users (who may not even understand what CSS is).

For reference, here's what it looks like with additional CSS added to a site:

[richtabor]

Maybe an Advanced section at the bottom of the right panel, that is collapsed by default, would be an alternative way of not having Custom CSS front-and-centre, but more discoverable than in the top ellipsis menu?

To continue the current Global Styles UX patterns, we'd need to do a drill down from Advanced, to the entry point of Additional CSS - which you'd then click to open the next panel.

But I'm not confident that discoverability is an issue. Sure we can definitely improve how its invoked and add more context, but bringing it top-level will lead to far more issues than it's worth.

[burnuser]

A) At the moment the UI for additional CSS is inconsistent in any way.
1.) The ellipsis menu is definitely the wrong place to position - and search - it. (And yes, discoverability is an issue! The UI should support people, not hinder them!)
2.) In "Blocks" the CSS option is visible by default like global CSS before Gutenberg 15.1
=> Maybe the suggestion with an "Advanced" section would do it?
=> And make it consistent again: "Advanced" section for Global AND Blocks CSS!

B) Your attempt to hide additional CSS is useless at all. There are a lot of Plugins to add CSS to WordPress. And they work for Classic Themes AND Full Site Editing Themes.
=> The only result of hiding CSS in the UI: People think "Oh, there is no global CSS option like in the classic Customizer. What a shame! So I must use a CSS Plugin."

[ghost]

Well, feedback from 2 people. Real usage.
Everything is already said.

I am going to add that there is No problem on keeping the current direction, and I don't want to stress the team when writing my feedback.
This is a minor issue.

Once that is said,
I also add in a constructive manner that at least the author (burnuser) and me, we are complaining about the current position of the feature.
How strange it is when our feedback is followed by a statement regarding "I'm not sure about discoverability...". We already know this =D and it's okay. We also are not sure about many other things, BUT on this issue, we voiced, we are very sure that it is bad. How much do you believe in feedback and where is the capability to adapt?
To aggregate efforts?
We are being clear about a possible better solution. There is no word about how this is being considered. But words and words never miss to reinforce one's decision. Which is also valid, but not enough.

WordPress is made by awesome and skilled people, including the Design team here present. Design is scientific. And few projects on the internet are so good on their practices, management, and this interaction to the public.
The collaboration exists.

However, as nothing is perfect, one area that this project does bad, SO bad, or in other words, one area in which WordPress has room for improvement, is on the decision making. Everything related to achieving consensus, you just need to read the issues to understand this is always the pain point.

In so many decisions, we read "I believe this is better". "It is going to bring problems". "Let's deliberate". "Follow the mockups".

It is wrong to think that someone, as skilled as it can be, is capable of seeing everything. It is wrong to think that a decision made by a team, as skilled as it can be, and as immersed in the community as it can be, is capable of satisfying all points of views, wishes, etc. This is NEVER going to be enough and therefore it is a constant to repeat discussions like the current one.

Because there is one single "enlightenment" missing on the decision making:
What about people's participation on the decision making? Everyone talks so much about end-users, how this project is "open source", as if participation was taken for granted, as if participation was happening in silence. As if the beta period, the support team and conventions were going to satisfy the needs.

Feedback collected fom annezazu, for example, is great and valuable indeed. Criterias exposed by Rich Tabor are also valuable, as one can see.

Both positions should remain. However the feedbacks collected in these scenarios happen AFTER changes were conceived and later implemented.
Feedbacks in this scenario serve a preconceived direction. Even the best feedbacks in this scenario are just going to encourage "minor course or actions", new "attributes" to the grand plan, instead of considering the centrality of feedbacks directly in the central scope.

This is not a problem that is going to be solved by training the team, which is dealing as well as it can here.

The root meditation that I am writing, with much patience, to make my feedback be heard, is regarding the fact that there is not enough people's participation in deliberations YET, in the process making YET.

and the existence of this YET is a decision.
It is a management decision with implications as less quality for the product, more discussions as the current one.

They believe that post-Feedbacks are enough to catch something alarming.
"Hey, the plugin is updated every 2 weeks, there is a beta period... Participate when you want"

However, how to participate on the mockups? On the planning direction? When we write feedback, for example on this issue, everything is so difficult to change then. We are presented by the internal docs, the deliberations... As if we were missing the point. What we are missing is indeed the voice, the right moment to join in.

No one doubts the work behind it, and it is elegant indeed. WordPress is striving, because the team remains amazing, and capable of implementing a difficult project.
That by itself is already half of the way.

But the mockups were never enough to represent our feedbacks.
These labels "Needs Design Decision" are funny in a sense. They actually require a person or team to create the mockups. Everything is okay until here. And then (!) They present their creations on the blog, they start to implement them... There is anew valid guideline.

What a gap!!!

An intermediate state is missing and could be: let's collect feedback NOW on the MOCKUPS, on the planning. Let's create a public temporary group to discuss this mockup. This planning, WHILE it is being planned, let's invite the public. Only then publish it, and start the process to create issues, in order to implement it.
You see? Feedback already happened.
Of course you would keep on collecting post-feedbacks in an organized or sporadic manner, as it is this the nature of this current issue...

---

Too long to read:
The feature is working. It is great.
Rich Tabor considerations are valid, and so are ours, which did a real usage.
How to change a feature after it is implemented?
Rely on the planning? Yes.
Is this planning and guidelines currently enough? NO! Because feedbacks were never considered. The guidelines, the mockups, the planning, are flawed since the start.

There is so much distinction between end-user, developer, as if the experience had layers.
Very possibly PEOPLE are not going to enjoy the current feature. And many others are also going to see no problem at all, of course!

There is need to decide now, if keeping the planning is the solution, or to put security aside in order to consider our free feedback and experience with your product. To believe on the planning and the team decision, AND to BELIEVE on our experience TOO. Ideally not later, to invite our thinking to contribute to your planning is wiser.
It is just so strange how skilled designers know what is best, and we giving feedback, in return need to read about the greater plan of things...

We are using your product and disliking it.

Although my phrasings are a bit strong sometimes, my comment is NOT meant to be disrespectful, to anyone!!!!. It is just a "call to wake up". A free consultant work, hey owner Matt ;-)

I repeat my suggestion: there should be feedback participation on the planning stages of features, while they are being planned. This increases quality, as it decreases tension and uncertainty to a minimum. By doing so, planning, mockups, decisions are not only going to be released, exposed. The whole process is going to be more organic, with public participation. Fundamental decisions like the current one are going to be a more considerate process, with less chances of reverting or needing a substantial rework later on.

All the best,
Simon Wright