Remove drupal_add_css() from update.module

yup.

 3 files changed, 28 insertions(+), 2 deletions(-)

Gosh, really? :( We seriously need every module that has even 2 pitiful lines of CSS to add to an arbitrary page to define:

- A "Library" definition (12 lines of code) for said CSS, even though that CSS will never, ever, ever be used outside of that one page?
- An "assets" array (another 8 lines of code) to render said CSS to the page?

This seems like a pretty huge step backwards, DX-wise. :( Esp. given we lost the ability to add CSS files in .info.yml files with one line of code, too.

Can we please get a (major) follow-up filed first, in order to talk about how we can possibly make this far less painful on people? I'm all about this stuff being able to be cached, but this is crazy-cakes, IMO.

@webchick: A solution which has various beneficial side effects is #1996238: Replace hook_library_info() by *.libraries.yml file.

I'm told sdboyer has something up his sleeve in #1762204: Introduce Assetic compatibility layer for core's internal handling of assets to make that easier as well.

i do indeed have something up my sleeve for this that could make it easier, but it's still a matter of some discussion as to whether it's a good idea. see Wim's second item in #1762204-159: Introduce Assetic compatibility layer for core's internal handling of assets.

he and i are gonna talk about it tomorrow, but as it is, the new system would allow direct declaration of such one-off assets without requiring a library hook (or yaml, if #1996238: Replace hook_library_info() by *.libraries.yml file goes in). problem is, assets declared in such a way cannot be declared as a dependency.

problem is, assets declared in such a way cannot be declared as a dependency.

I actually think this is totally fine, and was my main objection to this patch. It escalates what is probably some of the least-maintained CSS in the entire code base to the level of a "library" same as jQuery, Autocomplete, etc. are. It makes the work of a module developer harder to suss out what's important and not, because the equivalent of print_r(module_invoke_all('library_info')); contains not only actual library libraries, but also this kind of one-off code. There is no reason anyone, ever, would want to depend on this for their own admin interface (only possible use case I can think of is Upgrade Status, and it declares its own CSS). So the extra 8+ lines of code (whether it's in PHP or YAML) feels totally superfluous to me.

+100 on a way to declare assets ad-hoc for the "I want these 20 lines of CSS on one admin page in the whole system" use case.

I think the misuse of library the primary point of confusion. If we rename library to asset it will make more sense.
Patch still applies cleanly and blocks #2073819: [META] Remove direct calls to drupal_add_css()

No, it's not a point of confusion. It's a point of verbosity. The word "asset" vs. "library" makes absolutely no difference if you still need 20+ lines of code to add a single stupid CSS file that does nothing of great importance. :)

And the patch only shows one instance of this file, not two, unless I'm mistaken. Nevermind, I am. :)

However, I guess this is what we're stuck with for now until/unless the new fancy assets library is in, so...

Committed and pushed to 8.x.