jenlampton
commented
3 years ago we add all new CSS changes to the existing stylesheets
I don't get it. We need to find a way to put the CSS changes someplace where they won't affect any existing site. Adding CSS changes to stylesheets that are already in use on live sites is what breaks them.
and then add SS that revert it back to how it was before the change (for backwards-compatibility).
When you say "revert it back" does that mean that this additional stylesheet is an exact copy of the previous version of the core stylesheet? Those wouldn't be supplemental anymore, so I'd call them "backwards-compatible stylesheets" instead. (I'll call this option A, below)
Or, would they only contain the inverse of the new rules that were added to the original stylesheet? So if we added a text-align: center to the original stylesheet, the supplemental one would add a text-align: left to put it back how it was before? (I'll call this option B, below)
I can understand the intent with wanting to have an exact copy of the stylesheet before we introduced the change (option A), but that file would need to be the one that remains in-use on a production site to prevent breakage. And -- this is the important part -- it would also need to have exactly the same filename as it did before the update. (so, copying it to a file named whatever-bc-1.18.css wouldn't fly...)
Adding any CSS changes to a production site can cause it to break, but there are several ways changing the name of a core stylesheet can also have breaking affects on a production site:
-
A stylesheet can be overridden by adding that stylesheet in a theme's
.infofile and then providing a file with the same filename in the theme. (I do this on nearly all my sites withmenu-dropdown.theme.cssandmenu-toggle.theme.css. These two stylesheets are intended for exactly this purpose, hence thethemein their name. I have seen it done lots of other core stylesheets, though.) -
A stylesheet can be removed by adding that stylesheet in a theme's
.infofile but not providing the file. Here's an example from Basis:
; Remove unwanted core CSS
stylesheets[all][] = system.theme.css
stylesheets[all][] = menu-dropdown.theme.css- A stylesheet can also be removed or re-ordered in
hook_css_alter(). The keys of the$cssarray are the filename of the CSS files.
By changing a stylesheet's filename in a release (or switching all existing sites to use a different file entirely -- option A), all the CSS that was removed or replaced before the release will be added back to that site, possibly causing breakage.
By adding additional stylesheets to existing sites (option B), we would also be adding CSS changes to a production site that had previously solved the problem in a different way. Now you have the "revert" CSS on a site, but not the the CSS it's reverting, also possibly causing breakage.
Whatever it is we decide to do, it needs to not affect the existing sites at all. That means not changing stylesheets that are already in use on existing sites (and potentially overridden, or removed) and not adding any additional stylesheets to existing sites. Whatever changes we do decide to make, the difference in CSS must only apply for new installs.
It's the fact that there's a proposal to add new CSS changes to additional CSS files.
Unfortunately, as noted above, there's no way to avoid breaking production sites that doesn't include putting the new CSS changes into additional CSS files.
Wouldn't that mean that users would never get updates to CSS for their site? As in, years down the track they're still seeing an old version of Basis that looks way different to new sites, when in reality they just didn't want to break one little thing at the time...
Yep, that's exactly what it means. We can't do any CSS updates automatically or sites will break.
Any of the changes that new sites are getting would need to opt-in for existing sites, so that people would have a chance to review the breakage and fix it on their own schedule.
ghost
findlabnet
stpaultim
klonos
philsward
UPDATED: August 27, 2020 by @stpaultim
Possible solutions:
Description of the need
A new user that does not have the time or skills to create their own theme or sub-theme should be able to build a solid, reliable, and functional site without need to install a contrib theme. However, there are a number of small problems with Basis that make that difficult, some of which have been fixed or are in the process of being fixed.
Most Backdrop developers are used to creating custom themes for sub-themes for their sites and routinely deal with these issues during that process OR have created their own sub-theme templates with fixes in place.
It is my concern that as we continue to tweak Basis and/or fix bugs, that we might end up breaking or making unexpected changes to existing sites that are using Basis as their only theme. Since we are at least 3 years away from Backdrop CMS v 2.x, I would like to decide on a best course of action for providing a robust and flexible theme (for beginners with limited theme building skills) in core that can safely be used "out of the box" and will accommodate a variety of uses.
Possible solutions that have been considered
1) We could go on making updates to the current version of Basis at some risk of minor breaks to sites that are already build using Basis out of the box without any sub-theme or changes. 2) We could introduce Basis v 2.x into core as an experimental theme, making it clear that it is under development until 1.x-1.16.x (or whichever version we determine) 3) https://github.com/backdrop/backdrop-issues/issues/4167#issuecomment-554654706 We could develop it as a contrib theme, but with an expectation that we eventually moving it into core at a later date. We already have https://github.com/backdrop-contrib/basis_contrib 4) Issue #4512 - Add a "supplemental stylesheet" to Basis (or default theme) that includes new css or overrides that might cause problems with existing sites. This "supplemental stylesheet" would only be used if a config option was checked, the default would have this config
off, but on new sites it the install profiler would turn iton. [Added 10/28/19 - inspired by discussion here: #4166] 5) https://github.com/backdrop/backdrop-issues/issues/4167#issuecomment-666914785 Create and add a sub-theme of basis to core called something like "basis_edge" or "basis_current" that includes all the changes. This new sub-theme would be the default theme on new sites, but old sites would continue to rely on the existing version of basis. 6) https://github.com/backdrop/backdrop-issues/issues/4167#issuecomment-667600343 Create a new default core theme, keeping Basis as it is but deprecated, and try to fix as many of the issues as possible in this new core theme. (This is very similar to option 2. It's not clear if either of these plans offers an avenue for ongoing improvements in CSS). 7) Issue #4782: Add support for supplemental CSS selectors. All new CSS or CSS overrides that might cause problems with existing sites would be prefixed with a class matching the version of core where it was introduced. That class would only be added to sites installed on or after that core version. 8) Issue #5175 : A new theme to core - This may be the most ambitious option. The idea is that if we cannot find another way to fix CSS issues, we could simply create a new theme for core that fixes existing problems, is updated to give Backdrop core a new look, and possible contains within itself a system that allows updates and fixes safely.Some Issues blocked by this decision
Additional information
This idea was inspired by issues such as:
[META] Issues with Basis https://github.com/backdrop/backdrop-issues/issues/4094
Should we set default margins on 'p' tag in Basis? https://github.com/backdrop/backdrop-issues/issues/4166
Remove the hover color from header account links in Basis https://github.com/backdrop/backdrop-issues/issues/3748
Basis & Flexible Layout Templates: Remove white space between two hero blocks placed next to each other. https://github.com/backdrop/backdrop-issues/issues/4095
I really don't know if this is a good idea or if it's necessary to accomplish the goals I've outlined, but I wanted to put it out there for discussion.