Move all CSS to the theme

It's a good idea.

The only way this would be feasible is to develop a standard of supported mark up patterns. Module developers simply need to output certain elements and classes and the theme will take it from theme. It would need to be extensive enough to cover every conceivable UI pattern a contrib module could need to achieve it's goal; for admin, and front facing interfaces.

I proposed something similar on a smaller scale here: #1595292: Create a style guide for Drupal's mobile UI

It has some good examples of mark up pattern libraries.

I think if you start removing CSS from modules then everything will start to look really poor out the box which will hurt users who use Drupal in a point and click, non developer way. Currently stuff tends to look fairly acceptable out the box. If you aren't happy with "acceptable", then you're probably a bit more of a power user (for want of a better term), in which case the tools are already there for you to do something about it. The most obvious of which would be hook_css_alter()

Hmm ok. I see what you're saying, at least for core modules providing css. Maybe all Drupal's core themes should inherit from a "system" base theme to save a bit of duplication within core. So all the basic stuff like styling of messages etc would be in the system base theme. Stark, Bartik, Garland etc would use that as their base.

That would mean that if your were creating a custom theme, but wanted to keep the defaults you would simply inherit from the base system theme. Anyone that wants a completely clean slate would just not do so.

I'd prefer to break these two out – Drupal default system styles can go. Contrib is more complex so can we go for the easy win?

Dropping system styles from Drupal is not a complex change at all, but would be incredibly welcome. The core themes should absorb the system CSS where necessary for those just wanting something out of the box, and D8 versions of contrib themes would need to update to account for this, but it's not a huge deal.

This would remove the need for overrides, reducing file size, reduce page rendering load, speed up theme development and make Drupal frontend devs much happier and creative!

I don't mind the idea of core themes sharing a base theme, though it limits their individual creative scope somewhat – the theme should be the theme, and style everything so it is harmonious with itself imo.

mortendk wrote a blog post on splitting up contrib CSS files into base, admin and theme, allowing contrib to provide reasonable defaults but still allow them to be overridden where needed: http://morten.dk/blog/css-file-naming-now-glorious-batman-style

How would this work with calendar module or other kinds of views for example? I mean Drupal core is a tiny fraction of the UI you see on sites, the majority is provided by panels, views, calendar, etc. etc...

We could split any Drupal-specific "styling" off into *.style.css files, but modules still need to define their contents' structure. We should put together a list of styles that could be split off, and create an issue for each *.style.css.

We need things to work "out-of-the-box", without any CSS defined in the theme, like Stark. The correct way to do this would be to split them off into individual files so that it's easier for themes to swap out the CSS files.

It feels very reckless to make a core change without considering the affect on contrib. We would at least need a game plan for every module that assumes system CSS is available.

How would this actually make anyone's life easier? As far as I can see, you'd just end up overriding a stylesheet from a theme, instead of overriding a stylesheet from a module. Both of these tasks are about as easy as each other IMO.

Also, if all stylesheets were in the themes, how would you make the relevant stylesheets appear & disappear when core modules were turned on & off?

This assumes we all use Drupal's core themes and modify them. We don't. I always build themes from scratch, or choose themes to build off where I don't need to override stuff.

I'd definitely vote for some sort of file-replacement scheme, ala templates; going down the path of "css only goes in themes" will just introduce (more) bloat and put a greater burden on themes.

Isn't that how it works currently? See Mortens FOAD technique

Maybe allow theme .info files to allow you to block css files without requiring the hook_css_alter() approach? Something along the lines of:

// Block all system stylesheets
stylesheet_blacklist[system]

// Block all stylesheets from the user module
stylesheet_blacklist[system][user]

// Block just user.css from the user module
stylesheet_blacklist[system][user][user.css]

// Block all stylesheets from views
stylesheet_blacklist[contrib][views]

// Block *all* contrib stylesheets
stylesheet_blacklist[contrib]

So don't change the current "css in modules" approach, just add better tools for themers to deal with it. That single stylesheet_blacklist[system] line would be sufficient for "power users" to nuke all core css and get a blank slate.

#21 sounds like a duplicate of #575298: Provide non-PHP way to reliably override CSS

I think the good intentions of this issue could be refocused on the above issue, and this issue itself marked won't fix.

I agree.

I still haven't heard any arguments to convince me that core CSS shouldn't all be in the theme though. The fact that the core themes themselves have to override the system CSS shows that this hasn't been fully thought through. I understand the wider need for modules to have very minimal CSS, but core is currently some and some; it should be thought of holistically.

When you have core styles like .item-list ul, it's a massive pain to override cleanly.

Yep ok fair enough. Sounds like the best answer is that mentioned in #22. Can we still have core styles a little less drill-down though, to make them easier to override? :)