Standardizing CSS generation in s9y

Discussion corner for Developers of Serendipity.
Post Reply
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Standardizing CSS generation in s9y

Post by yellowled »

Someone please correct me if I'm wrong, but to my knowledge, we (now) have the (theoretical) possibility to dynamically add all CSS that is generated by a given s9y installation to serendipity.css, right?
  • plugins can push plugin-specific CSS to it using event hooks
  • the core adds “must have” styles to it by pushing /templates/default/style_fallback.css to it
  • a theme's style.css is added to it
  • as is a theme's user.css, if present
So unless a user or theme author explicitly chooses to include seperate stylesheets in the <head>, there is no actual need for other stylesheets in the <head>?

Then let's please make sure that all plugins actually use this process. I volunteer as tribute, erm, to make a list and create a GitHub issue. Just wanted to check with you guys if this is actually true.

YL
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: Standardizing CSS generation in s9y

Post by Timbalu »

For me it does not make sense to push everything to streamed serendipity.css!

There are special plugin cases, where we have little CSS only, which is easy to add, say append to the serendipity.css $eventData.
In other more extended cases, this just blows up that file. Then a secondary css file added to head (or wherever) is good enough too. It always is a matter of how long does a second request and use the cache file takes vs gather all to the serendipity.css file, which then changes very often and has to be build and send far more often than before, I assume. And being a matter of coding clarity too. (You could say use get_file content(), but that would be another read/write process added, etc.)

So generally yes*, but not in every case! It would be nice to clear that by example and still have the choice to do it in either way by preference. I think there a more valid and private preference arguments to do it different than just html request arguments or other guidelines.

(*) could not even swear this is valid always and for ever! :)
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Re: Standardizing CSS generation in s9y

Post by yellowled »

Timbalu wrote:In other more extended cases, this just blows up that file. Then a secondary css file added to head (or wherever) is good enough too.
We can not measure if that's the case, though. We do not know if any given blog uses one plugin that references one extra stylesheet or five plugins with seven stylesheets altogether. We also do not know if the theme any given blog uses maybe already references a second stylesheet because it uses Google fonts.

What we do know is that if we push all the stylesheet assets to serendipity.css, the core will generate one stylesheet reference. I feel that approach is always better than not knowing, but I can respect that other people have different opinions.
Timbalu wrote:the serendipity.css file, which then changes very often
Why would that change “very often”? It changes if any of the components that push to it change something in their styles, does it not?

About the only argument that I see is plugins that use external libs (like lightbox, which ironically is how I even came to think about this). If it is not feasible to push the stylesheet files provided by those libs to serendipity.css, I can accept that because it would be a pain to maintain otherwise.
Timbalu wrote:It would be nice to clear that by example and still have the choice to do it in either way by preference.
I actually think the best solution would be to find a way to leave that up to the people who actually do know/can judge – the users. That would mean to have a plugin option for it – reference plugin stylesheet seperately or push it to dynamic stylesheet. That would actually be great IMO.

YL
Post Reply