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.
Recent comments
Thanks for the guide, let me do just that. I hope there is still a chance of these seeing a backdrop port.
Station and Community Media
The block system and API in Backdrop is very different from Drupal's. In Backdrop, as in Drupal, modules can define blocks in code (in fact some of the API at this level is the same, with...
Drupal block module conversion
This was from examining line 2463- of the webform.module, where // Attach necessary JavaScript and CSS. $form['#attached'] = array( 'css' => array(backdrop_get_path('module', 'webform...
How do I diagnose Webform Conditionals failing?