backdrop
Add a UI for Supplemental CSS
Description of the need
Supplemental CSS is very close to getting into 1.30, despite an ongoing discussion about whether or not we should have a UI for this feature in Basis. We decided to merge the issue without a UI, holding out the option that we may YET incorproate a UI in 1.30 or later. https://github.com/backdrop/backdrop-issues/issues/4782
If we do not get a UI into 1.30, we would at least make sure to release a contrib module that provides a UI.
In the meantime, we're opening this issue to focus on the decision about whether or not to include a UI in core at all - at least at this time.
Proposed solution
Here is a screenshot the UI we were working on, before removing it from core.
Some comments from the previous discussion:
https://github.com/backdrop/backdrop-issues/issues/4782#issuecomment-2547504813
I would like to propose that we postpone adding any UI at all until after we have some real-world experience with CSS changes in core. It seems like we're doing a lot of guessing about what is going to be needed, and creating a lot of potential confusion in the process.
The only thing we have on the Basis settings page (without color module) is a setting that a new user won't need on a fresh install - and likely won't understand. What percentage of Backdrop sites are going to benefit from having these options? Less than 5%? Less than 1%?
The two use-cases in the original scope of this issue were 1) new installs (that get all fixes up to that point) and 2) existing sites, which get none of them. There was no need for a UI with that much more limited scope -- and no chance of breaking anyone's site accidentally with either of them :)
https://github.com/backdrop/backdrop-issues/issues/4782#issuecomment-2547532358
For all existing sites running Basis unmodified, it would be nice if there was a way to decide to opt-in to the messages being fixed without diving into config files or preprocess functions. We'll probably feel similar about other future fixes that might also have a dramatic improvement to the appearance of Basis. I think a lot of sites will want to use the improvements as they are released.
https://github.com/backdrop/backdrop-issues/issues/4782#issuecomment-2547571120
In terms of scope creep, I'm not personally invested in adding a UI. I put it into the PR because I was asked and because I'm not necessarily opposed to it and I am frequently disappointed in new additions to core that don't have a UI. A few random thoughts.
I agree that much of the thinking behind this PR was about making changes to Basis moving forward, not necessarily making it possible for old sites to pull in changes. So I personally did not expect it to have a UI to start with. But, as I said, I'm a sucker for a UI, so I'm easily convinced and potentially wrong.
I also think it's true, that only a percentage of existing sites are using Basis and only a percentage of those will not have already fixed problems that they didn't like in Basis by default. I personally don't expect too many sites to change this setting. Again, I'm thinking that most changes we will make in the future are for future sites, not old sites.
I suppose that early drafts of this PR had the words "Expert" and "Advanced" on the label for the setting, because I am a bit concerned that some site owners are going to be confused by this setting and potentially use it incorrectly. BUT, I also think we have done a fairly good job of adding help text to minimize that confusion and/or risk and I strongly advocated for a "Default" setting to make it easy for someone to get back to the originally intended setting, if they try something else.
I was a bit surprised that we added a UI to this PR, given how often we add features like this without a UI and leave that to either contrib or future releases. But, I am a sucker for a UI, so while surprised, I was not disappointed by the UI.
If we decide against a UI, I will absolutely start working on the contrib module to provide a UI immediately. Usually, I don't feel confident in my ability to create UI's for features like this one. But, in this case, I wrote the possible core UI, so I'm pretty comfortable with the idea of creating the contrib module. I doubt many people will find the contrib module, but we may be surprised and I will feel better knowing it's available.
What about simplifying it to something like this:
CSS changes:
(*) No
Future updates to the theme's CSS will not be automatically applied so your site will stay as it is now.
( ) Yes
CSS updates will be automatically applied and may result in changes to your site.
My 2c to the UI-or-not discussion: People may wonder, why one of their sites looks differently to another of their sites, although they're using the same modules and theme ... They'd never figure out, it's because of the install time of the site.
To have the ability to fix that WTF, a UI for toggling on/off would be extremely helpful. Otherwise it's just a riddle for site builders and even if they figure out, only solvable by directly fiddling in a json file...
I have created a contrib module to add this UI as a temporary measure. I'm on the fence regarding the need for a UI in core for this feature and could go either way.
https://github.com/backdrop-contrib/supplemental_css_ui
I think the presence of this UI is as likely to create confusion as the absense of the UI. But, in either case, I think we can mitigate that confusion.
I agree it would be difficult to understand why two different sites look different without a setting page.
The only alternative I could see is an entry in the Status report page which could make clear what is causing the different look. (I am not saying this is the solution, nor could I suggest what that entry should say to make that clear.)
The only alternative I could see is an entry in the Status report page which could make clear what is causing the different look.
I see some additional benefit in that info. And it shouldn't only be on the status page, but also on the debug page (admin/reports/debug).
But that's actually not topic of this issue here - should I create a new issue for that?
Edit: Issue created.
But that's actually not topic of this issue here - should I create a new issue for that?
Adding information on /admin/reports/status and /admin/reports/debug can be done even if the settings page described here is added. If the new settings page is not added, the information on /admin/reports/status and /admin/reports/debug can still be added.
I would create a new issue for that.