Allow CSS to be added at end of page by rendering assets with placeholders

@gapple we'd need to add a new interface with a new method, update the existing implementations to support the new method, as well as the new system asset controllers to handle it. When only the old method/interface is implemented, would keep everything in the header and ignore the declaration.

Some naming issues to deal with and the logic is fairly complicated (although most could be copied from the js version), but it's doable.

I was wondering what happens with this and big pipe.

The answer is that big pipe relies on the AJAX system, and the AJAX system does:

   add_css(ajax, response, status) {
      if (typeof response.data === 'string') {
        Drupal.deprecationError({
          message:
            'Passing a string to the Drupal.ajax.add_css() method is deprecated in 10.1.0 and is removed from drupal:11.0.0. See https://www. drupal.org/node/3154948.',
        });
        $('head').prepend(response.data);
        return;
      }

I wonder if we actually need to add the CSS to the HEAD of the document now that it can appear in the body? But also wonder what this means for FOUC, presumably we'd still want the new CSS file to be downloaded before the new HTML is rendered.

This makes me think about this solution in general. If we add js-style header and footer to library definitions, then this allows libraries to determine where they're loaded, but I don't think it's possible for the module to know what's going to be appropriate.

Instead maybe we want everything to work a bit more like BigPipe does:

For CSS that is specific to certain page elements, if it's always loaded via #attached or single directory components, then BigPipe kind of handles it because those CSS files will not be in the aggregates when the page is initially loaded, allowing the page to render faster not just because it's being streamed but because placeholdered content will load the CSS later too.

Then I looked at Renderer::renderPlaceholder(), and I think it might be possible to change that (or add a new placeholder strategy) that works similar to BigPipe - i.e. collect the assets from the placeholder, build any CSS aggregates right there and render them just before the markup, leave the JS handling as-is.

It would then be up to themes to rely on #attached to add CSS as much as possible to take advantage of this.

But this way:

- CSS for non-placeholdered elements and in the theme's .info.yml 'libraries' key goes in the head as now.
- CSS for placeholdered elements - rendered when the placeholder is.

To make #15 work we would need to track during the request which libraries have had their CSS rendered already, and then remove them from the libraries to render at the end of the request only for the CSS renderer. This would be a bit like ajaxPageState but it would have to be tracked separately because the JS still wants to be all together at the end of the page. Would need to happen in HtmlResponseAttachmentsProcessor::processAssetLibraries()

+1 for this.

#15 is already how BigPipe has always worked for no-JS BigPipe clients! 😄

This would be a bit like ajaxPageState but it would have to be tracked separately because the JS still wants to be all together at the end of the page.

Why would it be different for CSS than for JS?

For js for anything that's not in the header, we already load it in the footer so that it's non-blocking. If we started progressively rendering (not sure what to call it, but using this instead of 'inline') JavaScript assets it would then block rendering again - so we should keep it in the footer as it currently is.

For CSS it is blocking and we currently render all of it in the header, so by progressively rendering some CSS as we go, we're making it less blocking.

My first idea here was to add the 'header/footer' concept to CSS, but I think adding the assets 'progressively' with the placeholders they're attached to is the way to avoid FOUC.

So for JavaScript header + footer is good, but for CSS header + progressive is good.

I haven't tried to make this work yet, but I think it might be able to look something like this:

All the fun is in HtmlResponseAttachmentsProcessor::processAttachments() and the rest of that class.

Before rendering placeholders, get the current set of libraries. This gets us all of the page-level CSS that needs to be in the header (even if it's also attached via a placeholder).

When we render placeholders, we get $assets from the rendered placeholder.

For CSS, we then prepend the CSS link tags to the markup, but we need to exclude the following:
1. ajax_page_state
2. Page-level libraries
3. Any other libraries already prepended to a different placeholder.

Then when we render the page level CSS (in the place we already do that), we can just use what we got in the first place. For JavaScript we'll need to maintain an extra assets array, and this one gets all the placeholder libraries added to it as it currently does.

I've just realised you might have meant essentially the opposite with #17.

We could send non-footer JS that's attached to a placeholder in the same way as CSS - that would then get it out of the header too, that would give us header + progressive + bottom JavaScript then and should work fine.

Just took me 10+ minutes to find this issue again, trying to make it a bit more searchable.

I had another look at what would be necessary to do this, and the above is about right, but it would be a non-trivial change.

In wondering what would benefit from the change in core, I discovered that'd be less than you might expect, due to #3432183: Move system/base component CSS to respective libraries where they exist. So we might want to work on re-organising things a bit before spending too much effort here.

When https://jakearchibald.com/2016/link-in-body/ was written, chrome would still block rendering on stylesheets in the body, but now it doesn't - just got this confirmed by someone from the google chrome team.

However, Safari apparently does block rendering on these stylesheets (although it wouldn't for ones rendered via big pipe that use loadjs because it can't know they're possibly going to be added). Don't have a reference for this yet.

Firefox more or less does what Chrome does.

Unresolved HTML spec issue: https://github.com/whatwg/html/issues/1349

Safari not optimizing for this wouldn't necessarily mean we shouldn't do it, if it's an improvement in chrome/firefox and neutral or neutral-ish for safari.