yellowled wrote:For future themes: stop using extra stylesheets besides style.css. Instead, apply classes to <body> (preferably, I guess) and use those for i.e. theming.
I've done this plenty of times - in fact, I am doing it to the theme I am working on now, but this is not an ideal replacement to using separate stylesheets for color sets, especially if there happen to be more than just a few colorsets. It is often far easier to develop and maintain different files of code, than to merge everything into one. An example is {include file="whatever.tpl}. I know not including it is more efficient, but from a maintenance and delivery perspective, sometimes that external document makes more sense.
yellowled wrote:Yes, it may (depending on the size and number of colorset stylesheets) be better for performance to not load every colorset.
Absolutely - imagine a theme with many colorsets, or even just a few colorsets, but imagine each colorset has MANY lines of style declarations... I personally feel only the colorset styles selected by a theme option should be loaded via a stylesheet. I do not feel one much larger stylesheet, with every possible color style styles is better than the extra request for a single, smaller colorset stylesheet.
yellowled wrote:But the possibilities and benefits (especially for users) of the dynamically generated serendipity.css, including but not limited to adding a user.css, outweigh that.
What possibilities? I understand the benefits of a dynamically generated serendipity.css, and I am fully on board with it. I think its great to combine style.css, with fallback and plugin styles./
yellowled wrote:Also, not every theme has colorsets
Not every theme uses banner images either, but that doesn't mean we shouldn't have a mechanism to select them from the media library via a theme option.
I remember when we added the concept of user stylesheets... it was a great idea then, and it is a great idea now. When originally introduced, it was a theme option, which meant a theme designer could choose whether or not to include it, and where in index.tpl it was emitted... in Bulletproof, and many other themes based on BP, it was the last stylesheet loaded - which gave it the ability to override everything else before it, which is the very nature of 'cascading" in css.
Now we auto-include user.css.. but it is the only stylesheet (excluding plugins) other than style.css that is included in serendipity.css.
I understand the desire to limit stylesheets to one monolithic stylesheet. But there are valid reasons to having the possibility of more than a single theme stylesheet. Other than reasons previously mentioned, another one that comes to mind is the ability to distribute addendum stylesheets for a theme. For example, I might initially release a theme with stylesheets red_style.css, blue_style.css, and green_style.css.... using a theme option that detects files named *_style.css, I can later distribute a new style named, for example, orange_style.css without completely revising a theme's master style.css. Not only can I do it, anyone can create a new colorset for a theme and share that with the community without ever modifying a theme's core style.css.
SO, after two very wordy responses, I
STRONGLY feel we need a different solution for user.css so that it behaves more like it originally did - a stylesheet that fully overrides all previously emitted styles... and the way I see that happening is to be able to specify where, in index.tpl user.css is loaded, or perhaps, the ability to also also include additional stylesheets (ie, red_style.css, blue_style.css, etc) in serendipity.css followed by user.css.
Whew! I need a drink!