Fix AJAX add_css – insert the needed CSS assets after the already-inserted ones

That's an issue indeed.

This is interesting.

My initial thought is that you would add CSS to style new content which you are adding via ajax which may not be in the original request. As these would (hopefully) have different classes/selectors to the content in the page it doesn't matter if you are prepending or appending to head. I believe that order precedence in CSS is only important if all other precedence are equal.

So your example (with jquery ui) should still work prepending or appending. Unless you are using IE then you will be caught by #1071818: Lazy-loading CSS fails in IE

The questionable advantage of appending is that you would be able to change existing styles.

One solution would be to provide an option which defaults to prepend, but allows you to append if you really want to.

Doing append() would mean module CSS overriding theme CSS, right? Is it possible to merge into the correct place? We already have <style> and <link> tags organized by library vs module vs theme, but I don't know how we can expose that information to the tags themselves for JS to insert each one in the right place.

but I don't know how we can expose that information to the tags themselves for JS to insert each one in the right place.

In theory it may be possible to change the text of the CSS, or the CSS in the DOM, but looking at this compatibility table I think we would be walking into a cross browser nightmare.

another good use-case for data- maybe?

@kristiaanvandeneynde

Stylesheet gets loaded on page load, or lazy loaded right after
Module stylesheet gets loaded and prepended to all other stylesheets
Theme (or system) stylesheet applies instead of module's stylesheet

This is why you would namespace your attributes/styles. That way it doesn't matter if they are prepended or appended.

If you don't do this and you append styles you will end up with CSS clashes and changing the styles on the page.

edit adding link to Specifity guide, remember position only affects what rules apply if specificity is equal, and then rules are combined rather than replaced.

In short if your module/library needs position to have it's styles apply it is probably not using CSS correctly. The only case when this is not true is if you are intentionally trying to change the styles already on a page.

After a lot of time spent trying various methods, I've come up with the following workaround which may help others.

I have a custom module that provides AJAXified editing capabilities using Dialog API.
My problems were twofold:
1) jQuery UI's CSS was being loaded into the Dialog after my theme's CSS, and I had customised the look of the Dialog in my theme's CSS.
2) Media's media.js kept loading in after my theme's script.js, and I had overriden Drupal.behaviors.mediaElement in my theme's Javascript.

I tried various methods of altering the AJAX commands, and also tried setting $form['#attached']['js] and ['css'] properties, but nothing worked.
Here's what's worked for me. It's not pretty, but it seems to do the trick. Even after managing to get my CSS output at the end, I found that the media.js file was still being loaded after my theme's, so used the jQuery update hook_js_alter() method to swap Media's media.js for my own version.

function MYMODULE_ajax_render_alter(&$commands) {
	$csspath = drupal_get_path('theme', 'MYTHEME') . '/style.css';
	$jspath = drupal_get_path('theme', 'MYTHEME') . '/script.js';
	//first unset the existing ones, and then add them onto the end 
	//(inside a command array the path has initial / prepended)
	if ( isset( $commands[0]['options'] ) ) {
		unset( $commands[0]['options']['js'][array_search( '/'.$jspath, $commands[0]['options']['js'] )] );
		unset( $commands[0]['options']['css'][array_search( '/'.$csspath, $commands[0]['options']['css'] )] );
		$commands[0]['options']['css'][] = '/'.$csspath; //ajax_command_append('head',$css);
		$commands[0]['options']['js'][] = '/'.$jspath; //ajax_command_append('head',$js);
	}
	$css = drupal_add_css( $csspath, array('group' => CSS_THEME, 'weight' => 20, 'every_page' => false) );
	$js = drupal_add_js( $jspath, array('group' => JS_THEME, 'scope' => 'header', 'weight' => 20, 'every_page' => false, 'defer' => true) );
	$commands[] = ajax_command_append('head',$css);
	$commands[] = ajax_command_append('head',$js);
}
function MYMODULE_js_alter(&$javascript) {
//swap default media.js for our one
	$javascript['sites/all/modules/media/js/media.js']['data'] = drupal_get_path('module', 'MYMODULE') . 'media.js';
}

You'll notice I've added the JS and CSS twice, and I don't know which of the two methods is the one that works, or if both are necessary (It's very late, been working the whole weekend, finally got it working now, and wanted to note this down before I forget it and move on to the next major problem tomorrow morning. will probably have to revisit this and tidy it up a little bit later on)
But I hope this helps someone and stops them spending as long as I have done trying to get it working!

Setting to minor since this would only cause problems in <1% of use cases and an easy workaround is namespacing.

I don't think this is an edge case - the CSS system allows 'group' and 'weight' to be specified on CSS files for a reason, and it's bad that they are sometimes ignored. Giving your CSS rules a higher specificity can help, but it's a workaround and not always a good option (for example, if the two files that are competing with each other come from code you don't control, e.g. an outside library, a contrib module, etc).

In the meantime here's the workaround I wound up using for this, if it helps anyone (this is Drupal 7 code):

/**
 * Implements hook_ajax_render_alter().
 */
function MYMODULE_ajax_render_alter(&$commands) {
  $libraries_added = drupal_static('drupal_add_library');
  if (!empty($libraries_added['MYMODULE']['MYLIBRARY'])) {
    foreach ($commands as &$command) {
      if ($command['command'] == 'add_css') {
        $command = ajax_command_append('head', $command['data']);
      }
    }
  }
}

(where MYLIBRARY is a library defined in MYMODULE's hook_library() that has the CSS files which I want to force to be appended)

This is simpler code than the example in the previous comment, but also more brute-force (it will force all CSS files added via that Ajax request to be appended, not just my own). If you care about the difference, then the earlier code example may work better for you.

Just ran into this when we enabling bigpipe for an existing site (found this while investigating #2886657: BigPipe changes CSS evaluation order). I personally think appending is a better default than prepending. Here is a simple patch to change this for anyone who needs it.

This is just a quickfix though. I agree the "real" solution would be to insert all CSS as you should expect based on the styling level, weight and dependencies.

@seanB Any reason to not mark this Needs review and have a test run?

Not really, let's see.

The attached patch is a re-roll of #20 that should apply cleanly to 8.9.x.

#20 applies cleanly to 8.8.x but not 8.9.x.

The attached patch is a 9.1.x re-roll of #23.

Here a patch for 9.2.x.

Just found something funky because of this patch.

1. The file /assets/vendor/jquery.ui/themes/base/core.css is added via multiple CSS libraries in core (core/drupal.dialog, core/drupal.autocomplete , core/jquery.ui).
2. When an AJAX request is executed, Drupal adds new CSS libraries to the page based on drupalSettings.ajaxPageState. This only compares libraries, not actual CSS/JS files.
3. This could lead to /assets/vendor/jquery.ui/themes/base/core.css being added a second time, and having .ui-front { z-index: 100; } override .ui-dialog { z-index: 1260; } from /themes/seven/css/components/dialog.css, since the new CSS files are now appended instead of prepended.

Fixed it with some custom CSS in our theme for now. Since jQuery UI is being removed it is probably not worth adding a new issue to make sure core/drupal.dialog, core/drupal.autocomplete , core/jquery.ui don't add the same file, even though that is the real cause.

Just spent some time figuring this out, so thought it would be good to share :).

@seanB, I think that #32 should be addressed as well.

And we definitely need test coverage.

#32 also seeing this when using the gin theme and this patch, css of media library is added after gin css and breaks the media library display.

My theory is that we have at least three ways of interacting with libraries.

Overrides
Dependencies
Extensions

This patch is great for overrides and dependencies, but extensions are a problem. See https://www.drupal.org/node/2497313

Overrides need to replace a library
Dependencies need to prepend a library
Extensions need to be appended to a library

Re-rolled patch from #25 for 10.0.x.

Re-rolled patch from #40 for 10.1.x.

Bit confused by this one, I've spent the day debugging some odd CSS issues with paragraphs and entity embed modals.

I've tracked it down to /core/themes/claro/css/components/jquery.ui/theme.css being added multiple times on the page when adding a new paragraph (added via the add_css command) but these CSS files already are appearing after the existing CSS files. This leads to some UI styling bugs like the one described here.

EDIT: Ahhh, prepend is only used if response.data is a string, which is now deprecated. So it's using loadjs instead.