search

backdrop / backdrop-issues

Issue tracker for Backdrop core.
144 stars 39 forks source link

Add support for supplemental CSS selectors #4782

Open jenlampton opened 3 years ago

jenlampton commented 3 years ago

What about using special body classes to include new CSS? If new sites got the classes, but existing sites did not, we could prevent the CSS from affecting existing sites. (backwards-compatible)

At install time, the list of special body classes would be determined. Then, for the rest of that site's lifetime, only those original classes would be applied.

If new CSS is added in 1.17, one of those classes could be version-1-17. All the new CSS rules in 1.17 could be prefixed with .version-1-17, and all sites installed at version 1.17 or later would have this class applied. However, if I had installed Backdrop at version 1.14, my site would not have the version-1-17 body class, so would not get the CSS rules applied.

Backdrop sites installed at version 1.18 would also get all previous body classes, and if there were new CSS changes introduced in 1.18 too, that site would also get a version-1-18 class (but if there weren't any CSS changes, no class would be added).

Pro: This approach would allow us to keep all the related CSS in the same file, rather than moving the newer ones into a separate file that would not be included on newer sites.

Pro: This approach could work for CSS included in any part of core (modules, themes, etc).

Con: This approach could eventually lead to a lot of body classes on older Backdrop sites.

Related issues:

ghost commented 3 years ago

I like this idea, especially the two pros.

As for the con, we could try shorter classes (like v117), or we could make it so that only the current/latest version is added as a class on install. However that would mean needing to update all existing version-specific CSS to add the new version class on each new release, so maybe not a good option...

jenlampton commented 3 years ago

As for the con, we could try shorter classes (like v117)

Yeah, I like that better.

However that would mean needing to update all existing version-specific CSS to add the new version class on each new release, so maybe not a good option...

I thought about that too. I think I prefer less work with each release. Updating all existing selectors seems like it would be easy to forget.

ghost commented 3 years ago

Updating all existing selectors seems like it would be easy to forget.

Indeed. And they'd be spread all over the place.

klonos commented 3 years ago

I also like this idea 👍 ...I would love it if we figured a way to not "punish" new sites with adding all the version classes though; wondering if we could reverse this, so that only old sites that choose to not update have the extraneous classes. Needs a bit more thought 🤔

stpaultim commented 3 years ago

This proposal (above) is interesting. Part of me wonders if it is really better than supplemental stylesheets (which I was fine with), but I can see why folks might think this is better.

In the spirit of brainstorming, I'll throw out a few potentially bad ideas (modifications to this proposal) that might not be bad or might spark some good ideas.

1) Add a yearly class instead of a version based class. Simply to make it very clear that these kinds of changes only get in once a year and to limit the amount of extra classes that we might eventually accumulate.

2) I understand the proposal to suggest adding a new class to the body field for each version (or year), meaning that in 2018 (if we are still on 1.x) we might have sites with <body class="v2021 v2022 v2023 v2024 v2025 v2026 v2027 v2028>. Each new css rule would only need to address a single class:

.v2021 h1 {
    padding: red;
}

.v2021 .container .block p {
    padding: blue;
}

.v2022 header {
    padding: green;
}

.v2023 .menu-item {
    padding: yellow;
}

We could (I think) shift the focus to the CSS files and only add a single class to each sites markup, depending upon when it was installed. Then we could multiply the classes in the CSS, so that the changed rules simply apply to more different classes.

This option would keep the page markup cleaner, but would create a greater amount of 'redundant' css and the need to update all of these changed css rules each year. Maybe this is better, because the markup is more likely to be seen/noticed. On the other hand, this is probably a bad idea because of the extra work and cruft - but, maybe someone can make it better?

Markup contains only one year based class (example = <body class="2022">).

.v2021 h1, .v2022 h1, .v2023 h1 {
    padding: red;
}

.v2021 .container .block p, .v2022 .container .block p, .v2023 .container .block p {
    padding: blue;
}

.v2022 header, .v2023 header {
    padding: green;
}

.v2023 .menu-item {
    padding: yellow;
}

figured a way to not "punish" new sites with adding all the version classes though; wondering if we could reverse this, so that only old sites that choose to not update have the extraneous classes

I don't know if I understand the logic here. These new classes/changes potentially break old sites. I am not sure that we would give the old site the opportunity to choose the new classes (we could, but is the complexity worth giving them a possible fix to a problem that they have probably already solved). So, I don't think that there is necessarily any choice involved in this.

Also, why would you "punish" old sites IF they did choose to not risk breaking their site over improvements which they most likely don't need.

In most cases these css fixes will not help old sites, because old sites have most likely found a solution to the problem already. These new css fixes are for the benefit of new sites so that they can avoid the need to find their own custom fixes.

ghost commented 3 years ago

In order to reduce the number of classes added to sites, what if we only supported backwards-compatibility for the previous (e.g. 2) versions...?

So each (minor) release of Backdrop, we'd go through and remove any CSS class prefixes that were older than 2 version ago. This would mean that those changes were optional when they were first introduced, and for the next 2 versions of Backdrop (giving people a chance to update their themes, etc.), but then they're added to core after that.

For example:

This means we should only ever have 2 supplemental classes on the body tag. We can change this to support more versions of Backdrop (maybe 6, so then we're supporting the last 2 years of releases), but at least there's a limit to the number of CSS classes we're adding, and the amount of time CSS changes are optional before being made mandatory.

jenlampton commented 3 years ago

In order to reduce the number of classes added to sites, what if we only supported backwards-compatibility for the previous (e.g. 2) versions...?

I think you mean only supporting two minor versions -- and if that's the case I am very much against this idea. All of my clients really dislike surprise costs, and they like surprise breakage even more.

Once they get their website working, they are happy to pay for routine updates, but the expectation is that the updates will fix bugs, not cause more. When updates start causing bugs is when people stop being willing to update anything. :(

I'd rather have 100 classes added to the body tag than one client who's furious about the site being broken in an update. (The client certainly won't care how many classes are on the body tag).