TYPO3 Core

Hi Georg,

thank you for your quick reply! Sorry, my late. ;-)

I've prepared some poc files and attached them to this comment. That was a lucky request on your side because creating these examples revealed it least one further implication. Maybe it's best to have a look at the files first and afterwards continue with the

Priority conondrum

In file f_asset-css-concatenated-and-single-inline-only-poc.html I show how 4 CSS files are included. Three of them are concatenated. One of them has the priority attribute set to true. The result is that the three files are ordered by the order of their ViewHelper instances within the fluid template and the priority attribute and then their contents are concatenated and rendered in a single style block in the resulting order. A fourth file is not concatenated and therefore is simply rendered in a separate style block which is placed after the concatenated block.

What if the fourth file was included with priority="true", too?

We have a style block with the content of concatenated CSS files, one with priority="true". The priority brings the files rendered within one style block into the right order.
And we have a style block with the content of a single CSS file. Priority="true" currently means that it must be rendered first. But the concatenated style block contains prioritized CSS that should be first, too.

Well I did not find a plausible solution to that. In the comments within in the files I write that one goal should be to allow for the maximum possible flexibility. But to be true, I don't see a reason why multiple inline style blocks should be needed other than someone is not able to handle CSS properly. So maybe concatenation of critical (and therefore inline) CSS should simply be the default. Sort all critical CSS files according to their order and priority and put their contents in a single style blick. Voila. If one needs a separate inline style block, let this be done by an explicit concatenate="false" and let the developer see how he/she handles avoidable conflicts then. (My examples use explizit concatenate="true" but this topic is still subject to discussion so I think that's fine for now.)

A second aspect to have in mind is that people like to include external libraries just as they are delivered. Usually libraries are included first. This seems to make perfect sense but we are talking about inlining CSS because it is critical and is therefore needed asap to allow the browser to start the render process without the need to wait for additional requests for assets to complete. I show this in file f_asset-css-inline-and-external-poc.html. An external library that is needed to start the render process also needs to be inlined. Otherwise the whole concept does not make sense. But, what if an external CSS src is not available when it is requested. Waiting for seconds for a reply is no real option. After all, we are talking about speed an efficiency here. Maybe the critical attribute should not be available for the inclusion of external libraries.

So, always have the inline (cricital) CSS block render first. Every additional CSS inclusion comes after that. Libraries and what ever linked CSS.

Regarding JS: The thoughts concerning the priority and the need to have multiple script blocks are essentially the same. That's why I suggest to

• collect all JS for the header and for the end of the body tag separately
• per collection: order it by the order of inclusion and priority
• per collection: render all inlined js in a single script block and all references to files afterwards.

But it is also valid to place inline script blocks anywhere in the HTML document. As far as I know that is not yet considered by f:asset.script. So ether leave it as it is and place JS in the head or before the closing body tag or add a further attribute like "inplace" which triggers rendering of the referenced JS right where it is placed within the fluid template. inplace can be used for

• included external files,
• inline JS which is written inline and
• inlined content of js files.

If such an attribute will be added it should not be possible to combine it with the concatenate attribute (or it should implicitly set concatenate="false" if it will be true by default).

I suppose, if f:asset.css and f:asset.script would take all the above annotations into account they would provide an even better support for asset handling as TypoScript ever did. ;-)

What do you think? Does this make sense or did I miss something?