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

Component: theme system » CSS
Issue summary: View changes
Issue tags: -Twig +YAML
joelpittet’s picture

Component: CSS » theme system
Issue tags: +CSS
Cottser’s picture

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.

Cottser’s picture

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

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

Status: Postponed » Active
Issue tags: +TX (Themer Experience)

Setting this back to active.

Cottser’s picture

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

Jeff Burnz’s picture

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

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?

Cottser’s picture

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

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?

Cottser’s picture

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.