user stylesheets and colorset stylesheets

Skinning and designing Serendipity (CSS, HTML, Smarty)
User avatar
Don Chambers
Regular
Posts: 3633
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

user stylesheets and colorset stylesheets

Post by Don Chambers » Thu Feb 25, 2016 3:27 am

We had a discussion on Gibhub about user.css hierarchy. That discussion focused mostly on user.css existing in a theme folder vs. 2k11, etc.

I am about to release a new theme that, like Bulletproof, uses color sets (green, blue etc).... so, in addition to style.css, the theme will load optional style sheets for these colors. Using bulletproof as an example:

Code: Select all

{if $template_option.colorset}<link rel="stylesheet" type="text/css" href="{$serendipityHTTPPath}templates/{$template}/{$template_option.colorset}_style.css" />{/if}
The purpose of these colorset style sheets, is to override default styles listed in style.css, just as user.css overrides style.css.

User.css is appended to style.css.. unlike color stylesheets which are loaded in addition to style.css... and in past practice, after the core style.css so as to override anything that needs to change for that color.

By automagically including user.css, we no longer have the ability to determine where user.css loads. So, we either have this:

style.css
user.css (auto appended via {$head_link_stylesheet})
mycolor_style.css

or we have this:
mycolor_style.css
style.css
user.css

So, at the moment, the only way for user.css to override a colorset, is to load the colorset BEFORE the theme's core stylesheet. I am not a fan of loading a colorset before style.css - If no colorset is selected, then style.css is the only theme stylesheet loaded. If colorsets exist, then at least one colorset must be loaded to represent the default colors, which are then replaced by different colorset styles. I hope that made sense.

This isn't just about colorset stylesheets - some themes also contain stylesheets for printing, different browsers, etc. For user.css to truly override anything in a theme, it must be called after all other styles...

Thoughts?

Anyway, what I am wondering is this: can we have a hook or something that can be used (perhaps as an option) to determine exactly where a user stylesheet gets loaded?

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

Re: user stylesheets and colorset stylesheets

Post by Timbalu » Thu Feb 25, 2016 11:37 am

I think everything is ok!

Styles are added to serendipity.css by fallback, styles.css, plugins styles, user.css, and in this order.
Every other styles are based to a user decision:
  • a) by adding them manually to the index.tpl or
    b) by using a config option in the template config.
Why should a user want to change the color stylesheet options by a user.css, when he is forced to do this in the templates config.inc options?
For this extremly rare case you could either create a field for a user color css purpose (or a faking additional color-user.css) in the template config options, or force the user to append it manually to the index file, IMHO.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
yellowled
Regular
Posts: 7002
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: user stylesheets and colorset stylesheets

Post by yellowled » Thu Feb 25, 2016 1:22 pm

Don Chambers wrote:This isn't just about colorset stylesheets - some themes also contain stylesheets for printing, different browsers, etc. For user.css to truly override anything in a theme, it must be called after all other styles...

Thoughts?
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. See for example 2k11's way of applying the webfonts (which is actually a bad example because it also loads an external stylesheet) by setting a class to body.

Yes, it may (depending on the size and number of colorset stylesheets) be better for performance to not load every colorset. 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. (Also, not every theme has colorsets.)

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
Don Chambers
Regular
Posts: 3633
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: user stylesheets and colorset stylesheets

Post by Don Chambers » Thu Feb 25, 2016 6:53 pm

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. :wink:

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!

User avatar
Don Chambers
Regular
Posts: 3633
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: user stylesheets and colorset stylesheets

Post by Don Chambers » Thu Feb 25, 2016 6:53 pm

Timbalu wrote:Why should a user want to change the color stylesheet options by a user.css, when he is forced to do this in the templates config.inc options?
For the same reason a user may want to change anything in style.css. Users should be able to override ANYTHING a theme offers, including the ability to override stylesheets other than style.css
Timbalu wrote:For this extremly rare case
rarity is not the issue - the functionality of a user override stylesheet should work for all styles used by any theme - as it did when originally introduced as a theme option
Timbalu wrote:...you could either create a field for a user color css purpose (or a faking additional color-user.css) in the template config options
This would result in inline styles - not horrible, but lacks the benefits of an external stylesheet.
Timbalu wrote:...or force the user to append it manually to the index file, IMHO.
This was the original behavior of user.css. We need to try to return the concept of a user override stylesheet to themes - as it stands right now, user.css cannot override additional stylesheets unless a) those stylesheets are loaded before style.css or b) using specificity in user.css.

User avatar
yellowled
Regular
Posts: 7002
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: user stylesheets and colorset stylesheets

Post by yellowled » Thu Feb 25, 2016 7:24 pm

Don Chambers wrote:It is often far easier to develop and maintain different files of code, than to merge everything into one.
There are quite a few tools to make this easier in development without having to split it up into seperate files in production, though (preprocessors, build scripts). Just sayin'. :wink:
Don Chambers wrote: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.
Well, it's not really about what you feel (sorry), it's about what is measurable. That's a bullet I've had to bite a few times now. It may be easier to develop and simpler to maintain, but it may very well be that the single file performs better. I don't know (since I don't do colorsets myself anyway).
Don Chambers wrote: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: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 have, by the way, at at least one point suggested to extend this to a) include more stylesheets from the theme directory and/or b) to include external stylesheets from plugins (for example, lightbox). It's not that I'm against it, but there were some (PHP-releated) reasons (that I can't explain well) not to implement that back then.

I'm just not as opinionated on the whole thing as you are because my way of creating themes is (and will be) very different to yours (which is not even a bad thing).

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

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

Re: user stylesheets and colorset stylesheets

Post by Timbalu » Thu Feb 25, 2016 7:35 pm

Don Chambers wrote:Users should be able to override ANYTHING a theme offers, including the ability to override stylesheets other than style.css
Again, since this being a very edge case, you still are able to do this (even when being loaded before), by using cascading styles with id / class specifity or even use the "eval" !important. In most cases it probably is a matter of being able to build some creative workarounds... :)
Don Chambers wrote:rarity is not the issue - the functionality of a user override stylesheet should work for all styles used by any theme - as it did when originally introduced as a theme option
Well in this case - respecting that things may change over time - learn your themes to build colorsheets in a valid way - ready for an easy override in the user.css file.
How? You could fake your theme being a plugin, using the "css" hook. This should work?! I did not test this myself, but i hope to remember right one being able to do an approach like this in the config.inc.
Don Chambers wrote:This would result in inline styles...
No. This is not what I meant. I meant a config field holding user.css like CSS data, either passed to a theme based total-end-user.css file or passed dynamically into the css hook, which would then be before user.css data, hopefully.

See the changed behavior as an advantage to be creative... :mrgreen:
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
Don Chambers
Regular
Posts: 3633
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: user stylesheets and colorset stylesheets

Post by Don Chambers » Thu Feb 25, 2016 10:35 pm

The idea concept of a user stylesheet is that it overrides EVERYTHING that comes before it without using specificity. User.css initially did this by being the final stylesheet loaded.

The idea of appending user.css automatically into serendipity.css after style.css is a fairly new thing... but it brought with it the very real issue of no longer being the last stylesheet loaded. It only works as originally intended provided no other stylesheet exists in the theme.

For those using Bulletproof, or any theme based on bulletproof, the user stylesheet functionality is different than when it was introduced. It probably wasn't noticed a lot because there are not many bulletproof users and/or there are not many who have customized it via user.css.

I feel VERY strongly about:

1) We must preserve the ability for themes to have alternate stylesheets to contain declarations independent of style.css (ie, blue_style.css) because:

a) all possible alternates may not be anticipated when theme is released (ie, a new color)
b) new alternates can be distributed by anyone without affecting core styles
c) every possible alternate set of styles shouldn't be included in the core style.css as typically only 1 or 2 of these color/concepts is selected at a time... in other words, if I had a dozen colors, each with 200 lines of style declarations, the theme shouldn't need to emit all 2400 lines of declarations all the time.

2) We need a way to ensure that user.css is loaded after ALL other theme stylesheets, otherwise, it really isn't a true user override - it is a style.css & plugin overide

I am not suggesting we return to the old days of doing this in index.tpl:

<link style.css>
<link color_body.css>
<link color_everything_else.css>
<link some_other_design_concept.css>
<link shitty_browser_version.css>
<link_even_shittier_browser_version>
<link obscure_print_issues.css>
<etc......>

If we are going to build a single serendipity.css, I believe we need a mechanism to include additional selected stylesheets (ie, colors) within serendipity.css, and in a specified order which occurs prior to user.css.

Perhaps a trigger in index.tpl that essentially means "include user.css here" (which could then be any stylesheet name??!!)

Or perhaps: could we build some kind of array that consists of one or more stylesheet names that are loaded in an order specified in config.inc.php, starting with style.css, ending with user.css, with any number of specified css files in between?

I do not have the tech skills to make this happen, or I would have done it already.

PS - using specificity or !important are not the workarounds I was looking for, and use of these only underscores the point that the user stylesheet isn't a native override.

User avatar
yellowled
Regular
Posts: 7002
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: user stylesheets and colorset stylesheets

Post by yellowled » Thu Feb 25, 2016 11:32 pm

Don Chambers wrote:The idea concept of a user stylesheet is that it overrides EVERYTHING that comes before it without using specificity. User.css initially did this by being the final stylesheet loaded.
For the record, you can not necessarily override specifity just by a statement being written in the last stylesheet loaded. It always depends on the specifity of the original style and the user style.

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
yellowled
Regular
Posts: 7002
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: user stylesheets and colorset stylesheets

Post by yellowled » Thu Feb 25, 2016 11:37 pm

Timbalu wrote:Again, since this being a very edge case, you still are able to do this (even when being loaded before), by using cascading styles with id / class specifity or even use the "eval" !important.
I agree that it is an edge case to some extent, but that is not a valid reason to propagate worst practice CSS. You should always use the least specifity necessary.
Timbalu wrote:In most cases it probably is a matter of being able to build some creative workarounds... :)
Actually, smart CSS would be to avoid the need for “creative workarounds” in the first place. Is this the way you would propose to write PHP code? No, you would not.

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
yellowled
Regular
Posts: 7002
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: user stylesheets and colorset stylesheets

Post by yellowled » Thu Feb 25, 2016 11:49 pm

Well, since the problem is that usually the colorset stylesheet is referenced after the serendipity.css (and thus after the user.css), another easy solution would be to include it before the dynamically generated stylesheet.

This would require the theme author to have all “colorset styles” in external stylesheets – also the ones required for the default. So you would no longer override the default styles in the colorset stylesheet but set those in something like colorset_default.css (not in style.css).

Code: Select all

<link rel="stylesheet" type="text/css" href="{serendipity_getFile file="colorset_default.css"}">
<link rel="stylesheet" type="text/css" href="{$head_link_stylesheet}">
And then, the first stylesheet's name could just be a theme option and those styles could easily be overridden in the user.css.

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
Don Chambers
Regular
Posts: 3633
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: user stylesheets and colorset stylesheets

Post by Don Chambers » Fri Feb 26, 2016 12:04 am

yellowled wrote:Well, since the problem is that usually the colorset stylesheet is referenced after the serendipity.css (and thus after the user.css), another easy solution would be to include it before the dynamically generated stylesheet.

This would require the theme author to have all “colorset styles” in external stylesheets – also the ones required for the default. So you would no longer override the default styles in the colorset stylesheet but set those in something like colorset_default.css (not in style.css).

Code: Select all

<link rel="stylesheet" type="text/css" href="{serendipity_getFile file="colorset_default.css"}">
<link rel="stylesheet" type="text/css" href="{$head_link_stylesheet}">
And then, the first stylesheet's name could just be a theme option and those styles could easily be overridden in the user.css.

YL
Yes, I already showed that as an example above.... but loading colorsets before style.css seems counter intuitive... the nature of "cascading" styles is that successive styles [can] override previous style declarations.... having a core stylesheet come after the "options' seems quite odd to me... sort of like having dessert before dinner! :)

I also think it would be crazy to have a default "color" as its own stylesheet..... why not just include it in the core? That is exactly what is happening with this next theme I am working on. It has both color sets, and "skin" sets... color sets are accent colors, like red, blue, green, etc.... and the skin is primarily background colors.. the defaults for both are in style.css. if the user is happy with the defaults, there are no additional css files loaded. If they want a different color, or a different skin, the optional stylesheets are loaded via theme options.

I am happy to do this somehow in config.inc.php, or a combination of that and index.tpl, but I believe those options should be emitted AFTER style.css and BEFORE user.css.

User avatar
Don Chambers
Regular
Posts: 3633
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: user stylesheets and colorset stylesheets

Post by Don Chambers » Fri Feb 26, 2016 5:47 am

So I have discovered how to emit stuff into serendipity via both serendipity_plugin_api_event_hook and serendipity_plugin_api_pre_event_hook_css. Now I need to:

read the selected color stylesheet, and emit its contents AFTER style.css is included and BEFORE user.css. Any tips or suggestions?? :wink:

User avatar
Don Chambers
Regular
Posts: 3633
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: user stylesheets and colorset stylesheets

Post by Don Chambers » Fri Feb 26, 2016 7:15 am

I thought I was onto something with this:

Code: Select all

function serendipity_plugin_api_event_hook_css($event, &$bag, &$eventData, &$addData) {
    global $serendipity;
    $themestyle_data = array();  
    $themestyle_data['colorset'] = '';
    $themestyle_data['skinset'] = ''; // I'll deal with this later when colorset is working...
    $colorset_file = dirname(__FILE__) . '/' . $template_loaded_config['colorset'] . '_style.css';
    if (is_readable($colorset_file)) {
        $colorset_css = file_get_contents($colorset_file);
        if (!empty($colorset_css)) {
            $themestyle_data['colorset'] = $colorset_css;
            echo $themestyle_data['colorset'];
        } else {
            echo "Colorset file is readable but empty" . $colorset_file;
        }
    } else {
        echo "Colorset file not readable: " . $colorset_file;
    }
    echo "\n\n";
}
Problem I am having is that $template_loaded_config['colorset'] is empty, even though the config option is set to a selected color....

I've probably missed something really simple, but it is late, and I need sleep. Any suggestions appreciated.

User avatar
yellowled
Regular
Posts: 7002
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: user stylesheets and colorset stylesheets

Post by yellowled » Fri Feb 26, 2016 12:02 pm

Don Chambers wrote:but loading colorsets before style.css seems counter intuitive... the nature of "cascading" styles is that successive styles [can] override previous style declarations.... having a core stylesheet come after the "options' seems quite odd to me...
I think that's just in your head. It may be unusual, but there's not technical reason against it. And since you only “extract” styles from style.css to the colorset stylesheets to make them themeable, just think of them as core styles.
Don Chambers wrote:I also think it would be crazy to have a default "color" as its own stylesheet..... why not just include it in the core?
Well, now you're just discussing for the sake of discussing. Because it is a pragmatic solution.

I may be reading between the lines here, but I'm hearing a lot that sounds like “but I'm used to doing it differently” and “I want it to work the way it used to work”. Why? What's a good technical reason to not use the above proposal?

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

Post Reply