Add an 'admin libraries' option for layouts

I've never actually used the 'admin css' feature in Panels in D7, but assuming I'm understanding it right, it is a CSS file to only load when you're in the Page Manager UI editing a Panels variant that uses that layout, right?

If that's the case, I'm not sure that that feature makes sense in layout_plugin. Since layout_plugin is used by both Panels and Display Suite (and could be used by any contrib module in the future), there's really no knowing what the admin UI will be like.

If you really need your layout to use different CSS when used in the admin theme, it'd probably be best to override the layout stylesheet in your admin theme! Using normal theming mechanisms, you can make it so that a different CSS file is loaded when in a particular theme.

Would that solve your problem?

Do you know where can I find the preview of the content blocks in D8 Panels? I can assign blocks to regions, but cannot preview it as in past.

This functionality hasn't been implemented in Panels yet. Please open an issue in the Panels queue! :-)

Ok, sorry! If my understanding of how 'admin css' works in D7 is incorrect, can you please explain how it actually works?

It seems like this is a chicken-and-egg problem between the layout's CSS, the front end theme and the admin theme? Maybe the simplest solution would be to make sure the layout's CSS is very barebones and then override the layout's classes in the admin subtheme to adjust it as needed?

I think the bottom line here is if the core version of layout plugin doesn't have an 'admin css', then then contrib version shouldn't either, otherwise we're introducing a feature and deprecating it at the same time

... and how should this introducing a feature and deprecating it at the same time???

I can address this part! layout_plugin was merged into core, and so the contrib module will be going away eventually. We're going to try and adopt everything that's in core (per #2854617: Backport all changes from core 8.3) and deprecate everything that isn't in core. If core has no 'admin css' (or equivalent) property, then if we were to introduce it to layout_plugin in contrib, we'd have to deprecate it right away. Any new features should be against core!

This is how we handle this, we move it to core as a feature request and it could then be backported to Layout Plugin (if it hasn't been abandoned by then).

The chicken-and-egg issue is related to the layout's CSS. There are multiple admin themes available, just as there are multiple frontend themes available. The layout's CSS should be able to be used no matter where it's used, it should be theme-agnostic. If you don't follow this recommendation then you're going to either have to define requirements / recommendations for the layout ("only suitable for use with Bootstrap-based themes"), otherwise how will you know if the "admin css'" would even work with the admin theme a site is using? What if the site is using a Bootstrap-based admin theme, would the admin CSS file work or would it break? How about using it with an admin theme based on AdaptiveTheme or Omega, or Forty Two, or Adminimal, are you sure the admin CSS would work there too? It really seems like you're talking about a "seven theme css" file rather than a generic "admin css" file.

In short, it's up to you to build up the necessary CSS in the admin theme to work with the layout.

One practical idea would be to include an extra CSS file with any redistributed layouts that's designed for people to add to their theme when they're using the Seven theme, and document in the layout's README.txt file that it should be manually added to the theme, but going beyond that leads to a world of assumptions.

CSS cannot be attached directly, a library (*.libraries.yml) must be used instead.

Just re-read through this issue because Tim updated it. :-)

To try and clarify why I think this feature doesn't make sense...

@hass in #9 wrote:

My frontend theme is bootstrap, admin theme is seven. Bootstrap has no extra css file for only layouts. If you want a layout you need to fully load the bootstrap framework. No problem in frontend... everything is loaded with the frontend theme.

But can I load full bootstrap framework into seven without any css class conflicts? No! This means I need to write a custom admin css for seven, that shows the layout inside seven without bootstrap. A small css file with just the seven layout code, no bootstrap.

It makes sense that the layout might need different CSS when used seven. However, how does your layout know that it's going to be used in seven and not another admin theme? The layout only gets a single 'admin library' (since CSS comes from libraries which Tim pointed out in #12), at least that's how it worked in D7. I suppose we could make that property take an associative array where the keys are the particular admin theme, but I'm not sure it makes sense to couple layouts and themes that much. It also opens up some interesting questions, like, if a library is targeting 'seven' do we also load that in children of 'seven' or only exactly 'seven'?

My suggestion in #3 was that you could override the CSS for the particular layout in your admin theme (same as you can override the CSS of any library in a theme). If you admin theme is 'seven' you'd need to make a new child theme to that. But that seems like the cleanest solution: the theme itself knows how to correct the layout's CSS to work in that theme, and the layout can remain super generic.

This feature never existed in core and will likely never be added.

We do not target to seven or any other theme. We need to implement a admin CSS that is totally theme independed and only contain the CSS required to show the layout. It must not conflict with other themes or reuse other theme CSS. This could be archived.

Hm. So, then I must be totally misunderstanding the use case for this... If it's not make it work with a particular admin theme, then what is it for? What is in the admin CSS that isn't in the frontend CSS? Can you give a concrete example? Otherwise, I'm just totally lost on what this is meant to accomplish.

@hass: Is the theme providing the layout? Or is it a module?

The 'radix_layout' module solves pretty much the problem from your example (in both D7 and D8) but without using the 'admin css' feature. What it does is provide the minimal Boostrap grid system CSS necessary to display the themes in the layout's main CSS. And then in the 'radix' theme (which includes all off Bootstrap) it will remove the 'radix_layouts' CSS so it's never added to the page.

The net result is that the 'radix_layouts' layouts will work in any theme, whether that's a different non-bootstrap frontend theme or an admin theme. But then in the 'radix' theme, it knows the CSS is unnecessary (and actually could have different breakpoints in a 'radix' sub-theme, if it customized those) so it's removed.

Would something like that work for your use case?

If you're actually defining the layouts inside the theme, then that gets a lot more weird (theme adding CSS to a layout but then also removing it?) but still possible. I guess I can start see how this would be useful for layouts defined in themes, because they would normally expect the theme CSS to be available. But for layouts in modules, you have to assume that your layout could be used in any theme.