Add autoload option in css() helper for plugin CSS
The whole blocks feature will probably lead to a rise in the number of plugins users will install. Obviously it seems like a nice idea, to have custom block plugins that offer certain functionality (like a gallery, a map, buttons, media players, whatever) – but many of them require custom CSS in the frontend.
To install these custom blocks, the user currently has to manually include the custom block frontend CSS files for each block separately in their header template, which is tedious and a source for problems (e.g. removing a custom block plugin but forgetting to remove the css reference from the header).
Therefore I think it would be a good idea, if there was a “autoloading” functionality in the css helper for plugin-specific css – similar to the autoloading for template files.
The current parameter @auto could be renamed to @auto-template and the new plugin CSS loading option could be called @auto-plugin and both could be combined as @auto. Though this would be a breaking change.
To be honest I don’t think plugins should provide CSS at all. Each site’s CSS structure and styles are quite different, so plugin CSS won’t fit with the site styles. It would create a plugin mess similar to other CMS like WordPress.
In my opinion, block plugins should mostly provide the Panel experience and may include a default template that can be used as a starting point for a custom template.
@Lukas I understand your objections. I am not suggesting that this should be enabled by default or something. But I’d still like the technical possibility to use this – if I want.
I disagree with your statement that plugins should not provide CSS at all. I think it’s very important for more complex plugins to have the possibility to come with CSS included.
To make this more concrete: I built a a custom Mapbox plugin, to show an interactive map with a marker location and address overlay / additional information in the embedded area on my website.
There are quite a lot of styles required for this plugin. Obviously this might not look good on every page, but I could easily ship several variants (like different themes) of CSS with the plugin, so the user can select one of those designs in the panel or settings.
Having the possibility to ship self-contained blocks/plugins including CSS and using them immediately (without adding/editing CSS in the templates) looks like a very desirable option to me.
I agree that there can be use-cases where it makes sense, like the one you are describing.
However I think it should always be possible for the plugin user to enable the plugin styles one by one (for example to enable the styles of plugin A, but not the ones of plugin B). In this context there could also be support for different themes or variants per plugin.
What we should avoid is that the user prints plugin CSS in general in their templates, but then only has the option for “everything or nothing”.
While I really like the idea of making plugins plug-and-play, but I think this puts the general philosophy of Kirby in question. Kirby does not provide any CSS/JS by default, because it is intended for custom websites. That’s also the reason, why Kirby cannot automatically generate RSS feeds, like e.g. WordPress does.
WordPress can do this, because its content structure is highly standardized. This makes sense for enabling features, such as easy theme switching and combining different plugins, that bring their own frontend code.
Kirby acts more like a framework, where the developer has total control over the structure and look of the content. This often results in a bit of extra-work for developers, but helps to create very tailored and fast websites.
For my ImageSet plugin (Kirby 2 era), I just added instructions to the readme for how to setup your template in order to use the provided JS/CSS code. This is not a perfect solution, as it requires some tedious copy & paste work, but I think it has worked for the few hundred customers I had while selling the plugin. Although it might even have been a poster-child for the requested feature, because it just provided functional CSS code for placeholders for images, which where designed to fit into any design.
But for most use-cases, I am totally agreeing with @Lukas Bestle, that plugin-CSS should not load automatically after installing a certain plugin.
Here is a use case: I wrote a plugin that uses custom html elements. These do not work out of the box but require simple CSS rules, similar to the client styles that come with every browser.
The plugin uses:
<inline-icon></inline-icon> and <emoji-icon></emoji-icon>
This is valid HTML. To make it work this CSS is part of the plugin:
inline-icon, emoji-icon {
display: inline-block;
width: 1em;
height: 1em;
margin-right: .5em;
}
inline-icon {
background-position: center center;
background-size: contain;
background-repeat: no-repeat;
content: attr(alt);
color: transparent;
overflow: hidden;
}