Postponed

This issue is postponed on 8.1.x being open for development.

Example: remove all system stylesheets like this:

stylesheets-remove[] = system*

Comments

joelpittet’s picture

joelpittet
Primary language English
Location Vancouver
CreditAttribution: joelpittet commented
Component: theme system » CSS
Issue summary: View changes
Issue tags: -Twig +YAML
joelpittet’s picture

joelpittet
Primary language English
Location Vancouver
CreditAttribution: joelpittet commented
Component: CSS » theme system
Issue tags: +CSS
star-szr’s picture

star-szr
he/him
Primary language English
CreditAttribution: star-szr commented
Version: 8.0.x-dev » 8.1.x-dev
Issue summary: View changes
Status: Active » Postponed

Postponing, this is a nice-to-have and could go into a future minor version of 8.x.x.

star-szr’s picture

star-szr
he/him
Primary language English
CreditAttribution: star-szr as a volunteer commented

Just want to mention the fact that we are using libraries everywhere negates the need for this a bit in my opinion. Because libraries can contain a whole handful of CSS files that can be removed en masse.

Lukas von Blarer’s picture

Lukas von Blarer
he/him
CreditAttribution: Lukas von Blarer commented

I agree that this is a feature request we could postpone. But the fact that the system module adds 40 CSS files, this would be quite annoying to have that in 8.1.x because these 40 lines of code will end up in every single project I create. Can we rethink this? It would be nice to be able to to this:

stylesheets-remove:
  - core/modules/system/css/components/*
Lukas von Blarer’s picture

Lukas von Blarer
he/him
CreditAttribution: Lukas von Blarer commented
Status: Postponed » Active
Issue tags: +TX (Themer Experience)

Setting this back to active.

star-szr’s picture

star-szr
he/him
Primary language English
CreditAttribution: star-szr as a volunteer commented

I think if we add this it should be to libraries-override, not stylesheets-remove. stylesheets-remove is deprecated now.

Jeff Burnz’s picture

Jeff Burnz CreditAttribution: Jeff Burnz commented

Agree with #7 of course this is the right approach, however we need this to happen because right now this is a huge PITA and the only way is stylesheets-remove or some trickery in hook_css_alter().

Lukas von Blarer’s picture

Lukas von Blarer
he/him
CreditAttribution: Lukas von Blarer commented

To be precise this would happen in hook_library_info_alter(). Which is a clean solution. But we should introduce this functionality to the .libraries.yml as well.

Do we have to change the issue title and summary in this case?

star-szr’s picture

star-szr
he/him
Primary language English
CreditAttribution: star-szr as a volunteer commented

Just to emphasize my point in #7, this is how you would in 8.0.x remove all CSS added by the system module (everything in system.libraries.yml):

mytheme.info.yml:

libraries-override:
  system/base: false
  system/admin: false
  system/maintenance: false
  system/drupal.system: false
  system/drupal.system.modules: false
  system/diff: false
  system/drupal.system.date: false

8 lines of code in an .info.yml file isn't so bad IMO. I'd like to know more about the use case for the wildcard approach because to me it could be much less predictable than library-based removal.

Edit: If you look at system.libraries.yml actually a bunch of those libraries are just JS, but the point still stands.

Lukas von Blarer’s picture

Lukas von Blarer
he/him
CreditAttribution: Lukas von Blarer commented

Well my suggestion was kind of outdated I guess...

Ok, but stylesheet-remove does a quite different thing. In most cases I don't want to remove all JS the system module adds but all of it's CSS.

Besides that if you are using classy you can double this 8 lines yo will have to add all of those as well:

classy/base: false
classy/book-navigation: false
classy/dialog: false
classy/dropbutton: false
classy/file: false
classy/forum: false
classy/indented: false
classy/messages: false
classy/node: false
classy/progress: false
classy/search-results: false
classy/user: false

I guess this will get a lot worse installing contrib modules.

Is there a way to get rid of all CSS added by modules?

star-szr’s picture

star-szr
he/him
Primary language English
CreditAttribution: star-szr as a volunteer commented

Check out hook_css_alter and hook_library_info_alter :)

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.