Add js/css/libraries/head links to HTML fragments and pass it along to the page.

Thanks, dawehner!

+++ b/core/lib/Drupal/Core/Page/HtmlFragment.php
@@ -234,4 +243,40 @@ public function isCacheable() {
+  public function &getCss() {
+    return $this->css;
+  }
+
+  public function setCss($css) {
+    $this->css = $css;
+    return $this;
+  }

These need to be turned into add*() methods, like addLinkElement() and addMetaElement(). There's no reason for style and script tags to be handled differently at this level than any other header. That means they come out of the constructor, too.

+++ b/core/lib/Drupal/Core/Controller/HtmlControllerBase.php
@@ -73,11 +75,37 @@ protected function createHtmlFragment($page_content, Request $request) {
     $cache = !empty($page_content['#cache']['tags']) ? array('tags' => $page_content['#cache']['tags']) : array();
-    $fragment = new HtmlFragment($content, $cache);
+    $fragment = new HtmlFragment($content, $cache, $js, $css, $library);

I do think JS and CSS belong there, maybe even html_head, but adding library, will be a problem as there can be arbitrary things in attached now at this moment, see drupal_process_attached(), and this should parse the libraries down to CSS / JS.

As that is all that e.g. an ESIFragmentRenderer should care about.

There's nothing special about CSS and JS as far as *adding* them. Honestly I don't even think $cache belongs in the constructor here. This is a setter-filled object. Use 'em.

I agree they probably don't belong in the constructor, however given how browsers work, and if I understand the plan correctly that you want to e.g. use a ESIHtmlFragment, what you want to do is:

- Special case CSS, you need to e.g. queue them via JS if retrieving a ESI fragment as it can no longer change the original assets. You then want to get them in aggregated form of what CSS is not yet present on the page.
- Special case JS, you need to queue them for a ESI case, but for a Big Pipe workflow case you probably want to just put them in the original JS, but output in the footer. You want to possible combine them with the existing aggregates.
- Process all other #attached things and convert to JS / CSS.

Another special case is html_head, which just is queued via JS and then attached to the element, I cannot see currently why an ESIFragment would like to change the HTML head though.

Also cache is a very important information for an HTMlFragment, not only the #cache tags, but also the 'header' or a TTL of the content and usually also the global cache granularity (per page, per role, per user). I know we now have generally cache contexts, but the granularity is still important for determining if an ESI Fragment could be cached, especially if talking of recursive caching.

Just my thoughts, FWIW, I am prototyping some things of this in contrib.

1. +++ b/core/lib/Drupal/Core/Controller/HtmlControllerBase.php
   @@ -73,11 +75,40 @@ protected function createHtmlFragment($page_content, Request $request) {
   +    $fragment = (new HtmlFragment($content, $cache))
   +      ->setCss($css)
   +      ->setJs($js)
   +      ->setLibraries($library);
   

   That syntax is lovely, but only works on PHP 5.5. :-(

2. +++ b/core/lib/Drupal/Core/Page/HtmlFragment.php
   @@ -234,4 +240,55 @@ public function isCacheable() {
   +  public function &getJs() {
   +    return $this->js;
   +  }
   +
   +  public function addJs($js) {
   +    $this->js[] = $js;
   +    return $this;
   +  }
   +
   +  public function setJs($js) {
   +    $this->js = $js;
   +    return $this;
   +  }
   

   CSS and JS should be modelled with a StyleElement and ScriptElement, like Link and Meta. Those two in particular also allow for bodies.

   Mutating the array form of a render array's asset definitions to the object form should be RenderHtmlRenderer's job. (As soon as that finally lands...)

Wha? I thought that was added in 5.5. Carry on then! (But then I don't know what the fatal is about.)

looks outdated