style_fallback.css? Where did this come from?

[Don Chambers]

OK, in a recent thread we were discussing inline styles that are inserted by the entry editors. In that thread is this:

I think both Yellowled and I have both advocated the removal of the media manager inline styles.. the problem is that many templates would then have no styling for inserted images.

Well, we could use /templates/default/style_fallback.css for that now that we have it, right? Garvin?

YL

Later in the thread, Garvin does say that inline styles are gone with 1.5, which I have not really been playing with. At the time of that thread, YL's comment about style_fallback.css went right past me....

So today, a couple of interesting things happened.. first, I updated bulletproof with styles I recommended in the thread above.

Second thing is that I am experimenting with s9y 1.5 beta 2, inserted an image with a comment, and low and behold it is not styled the way my template styles it. Quick peek with firebug and I see another stylesheet is loading: /templates/default/style_fallback.css. So THAT'S what YL was talking about!

Now I understand the intention - many people had no styling in their template for what was being provided inline by the editor. However, this fallback stylesheet goes further than that... it begins to style things the editor never did, such as images with comments. It also picks up a bunch of other rules otherwise defined in the default template such as message classes.

This appears to be an attempt to help older templates that did not style certain things. In my case, I have some newer templates that will need to be modified because this fallback code does something my template does not specifically override. For instance, I do not use a background color on the div containing images with comments - this fallback does, so now I need to specifically override it.

A good 80-90% of these rules are the same as what are in my stylesheets, so either I leave them in both places, which makes them redundant, or I delete them from my template if they are the same... which I do not want to do because my stylesheets are organized differently.

Or, I realize I could put a style_fallback.css that had nothing in it at all into my template folder and would therefore never inherit those styles....

Regardless of knowing how to get around this, I do not like the concept one bit. We look for style.css in the template folder, and load it if it exists... if not, we load it from /default/. And now.. we do the same thing with this style_fallback.css. Every serendipity site will load a minimum of 2 stylesheets. Many - I would say most - sites already have most of these rules in their stylesheets, so they are redundant... the only ones likely to be missing are images WITHOUT comments, because those were styled by the editor. The editor did not provide inline styles for images WITH comments.

If a template is missing something - like padding or border rules for images, then that template needs to be updated. A template should not be effectively penalized because it styled these things, but perhaps did not specify something that this fallback does. I also think its silly to load a second stylesheet for this purpose... I use multiple stylesheets most of the time when it makes sense for code organization (ie, rules for navigation, rules for tabs, etc).... but each stylesheet is yet another request from the server.

[yellowled]

At the time of that thread, YL's comment about style_fallback.css went right past me....

Gotta pay attention. Always.

Now I understand the intention - many people had no styling in their template for what was being provided inline by the editor.

The intention of style_fallback.css goes way beyond the editor. As you mention yourself, it is meant to style things a) older templates did not style or b) people forgot to style in their stylesheets. Moreover, it provides fallback styles for crucial elements of almost any s9y blog.

It also contains some styles for the plugins of which I edited the emitted (X)HTML code, i.e. .plainList. So it provides backwards compatibility for these, which I think is essential.

In my case, I have some newer templates that will need to be modified because this fallback code does something my template does not specifically override. For instance, I do not use a background color on the div containing images with comments - this fallback does, so now I need to specifically override it.

Okay, so maybe style_fallback.css isn't perfect yet. I have to admit I haven't really looked at it since my templates usually do contain these styles.

A good 80-90% of these rules are the same as what are in my stylesheets, so either I leave them in both places, which makes them redundant, or I delete them from my template if they are the same... which I do not want to do because my stylesheets are organized differently.

You do not really expect us to remove these because it gives you extra work, do you?

Every serendipity site will load a minimum of 2 stylesheets.

Which does absolutely no harm, especially since the fallback stylesheet is very small. You may not like the fact that some styles are defined twice in the "collective" stylesheet, but it is most definitely not an issue at all. Even the extra server request is not really an issue here in my humble opinion.

YL

[Don Chambers]

Hey, we usually agree on everything... and this is not about me at all. We both know I can get around it in all kinds of ways.

I know it goes beyond the media manager... but I think the logic of this is flawed. It is a little too "big brother" for me. It is forcing stylesheet rules that have either already been defined by a thorough template or must now be defined because the designer disagrees with newly added styles that did not previous exist. Its not the place of the core code to force this. Emit a gazillion classes. Fine - you would not believe how many extra classes and IDs I built into Kinetic and other templates... but do not dictate specific rules - especially esthetic ones.

The example that caught my attention happened to be image with comments. Since Jesus was a baby, those are often styled with a background color of #ededed... but this background color has never been forced by anything... just carried over from one template to another... even bulletproof has this. But just because the old default template has a background color for these, and bulletproof, the new default template, has it does not mean that ALL templates have to have it unless they add extra code to reverse it.

Core code should emit html as required - it should not style it. We have simply relocated where the "separation of structure and appearance" are now occuring. We lost inline code, but now gained forced css.

Every template in the core distribution can be appended with the rules for images without comments ... and anything else in that fallback stylesheet provided it does not interfere with anything the template already defines. We can make that list of styles available somewhere as "suggested styles". We should not be including this second stylesheet as mandatory in all serendipity sites. I continue to strongly disagree with this concept.

Ain't personal though - we agree on nearly everything, and I love the willingness of everyone to distance ourselves from old legacy stuff... but I think this is not really forward progress but rather a relocation of a problem. I will happily examine every single template in our core distribution and include these rules provided they are not already defined, but I do NOT think loading this fallback stylesheet is a good idea.

[yellowled]

It is forcing stylesheet rules that have either already been defined by a thorough template or must now be defined because the designer disagrees with newly added styles that did not previous exist.

You're right: A well-formed template should not need style_fallback.css. (Maybe there is some way to set a variable in a template's config.inc.php to omit style_fallback.css? Garvin?)

Then again, look at style_fallback.css. All it includes are:

* .plainList (which makes a lot of sense here since most people don't seem to even know it exists, although I documented it properly in German and English in my blog and the forum)
* styles for the s9y messages (which I, personally, tend to forget in a template's style.css because I hardly ever see them while testing it)
* style for images from the media db (which, as the recent example of user1234 proves, can be kind of tricky)

So I think the point you're actually "upset" about are the media db styles. I, on the other hand, think that style_fallback.css will come in very handy if we're ever about to implement something like those new media db code examples. That's the upside of style_fallback.css, and I, for one, think it outweighs the downsides by a landslide.

Its not the place of the core code to force this. Emit a gazillion classes.

I actually think that we already emit way too many classes in the core and lots of plugins.

But just because the old default template has a background color for these, and bulletproof, the new default template, has it does not mean that ALL templates have to have it unless they add extra code to reverse it.

For crying out loud, Don. No one said style_fallback.css has to stay the way it is now. As far as I can see, Garvin simply copied some default styles from BP to this, committed it, and never looked at it again. I didn't look at them, either. You didn't even notice the file existed until yesterday, and a lot of people didn't either.

It's not supposed to be "the perfect fallback code". It's basically a "quick hack", and yes, it probably needs to be revised. But I think the file itself can be a very helpful tool.

Core code should emit html as required - it should not style it.

Theoretically, I agree. Practically, this is almost impossible in s9y right now, especially if we consider backwards compatibility for templates from the stone age. Because, as you of course know, this would mean -- if done "the right way" -- to remove any inline styles from the core (and the plugins, while we're at it). Do you have an estimate how many s9y blog would fall apart if we did that because they use templates which don't cover every single plugin?

Every template in the core distribution can be appended with the rules for images without comments ...

You wanna go ahead and do that? Keep every core template up to date with changes like this? 'cause I sure as hell don't. I've had enough of that when I edited some core plugins.

Besides, I really don't think that the core templates are the issue here. It's the ones on spartacus. And those are way too many to keep them up to date.

I think this is not really forward progress but rather a relocation of a problem.

It's neither. It's simply a practical means. I agree, it doesn't actually solve the problem.

I would be perfectly fine with a system which limits CSS to the template. If we ever decide to go that way, I'm the first to fire up an editor and start removing inline styles from any XHTML code generated by core or plugins. But we simply cannot do that unless we drop backwards compatibility.

In fact, I think this is a huge issue for the whole system. Having backwards compatibility in mind most definitely slows down the progress in terms of standards compatibility, which I personally think should be a top priority. But right now, it's next to impossible.

YL

[garvinhicking]

Hi!

First of: I'm sorry that this fallback-style puts a strain on you.

There's always a very thin line between keeping backwards compatibility and being forward compatible. A way between supporting easiest upgrade paths and improvements. To me, backwards compatibility is one of the key features of Serendipity. We try to not break anything on a user customization as long as its possible.

With this fallback style, we can do that quite easily. Performance wise, there's no feelable impact on combining style_Fallback with the usual style. The contents of fallback should be kept to a bare mininum.

When implementing this, my main interest was: I want to remove inline styles, but when removing them without providing a fallback, everyone's blog pictures will look ugly. We cannot modify every template that users have installed to provide the new needed classes, as we do not host all templates. Now the only other way that came to my mind is to force the new classes on them, which is also a great way to inject new CSS code in the future, that current template authors may not think about. Like new default jquery/lightbox classes, if we ever go that route.

Means for template authors that now about these new classes are easy: Just provide an empty style_fallback.css file, and no other lines of CSS will be prepended. I believe this is preferable over a config.inc.php code switch.

I am reall open for suggestions on how to solve the key problem differently, which is: Eradicate inline styles, but do not break custom created templates. Many s9y users customize their templates (like I did for my blog) and would be heavily annoyed if after an update, new images would be skewed or displayed inproperly. The current solution on the other hand, will not be noticed by most users though, so no breakage for them.

That means of course, or style_fallback.css should be as little invasive as possible, and as clear as possible to not badly affect any templates. Like yelloweLED said: I just copy+pasted the code from current s9y templates, so if they impose problems, let's tighten those CSS rules up -- or find another solution that walks the thin line.

Best regards,
Garvin

[yellowled]

To me, backwards compatibility is one of the key features of Serendipity. We try to not break anything on a user customization as long as its possible.

I realize this is more or less a different discussion, but I feel that sooner or later, we're gonna hit a roadblock with this philosophy.

Don't get me wrong -- backwards compatibility is an asset, although I don't think it's the primary feature which attracts users to s9y. (Again, that's a different discussion; whoa, rambling!)

But I sense that sooner or later, we're gonna get to a point at which we're gonna have to decide whether to break everything and start from scratch or to keep it backwards compatible, but no longer up to date to current web standards. HTML5, for instance, could be that kind of roadblock.

Question on the side for you: We already have "Requires" as a minimum s9y version requirement for templates. Would it be possible to have sort of a "maximum counterpart"? Theoretically? Some rule saying "This templates only works w/ s9y up to version 1.5"?

We cannot modify every template that users have installed to provide the new needed classes, as we do not host all templates.

Even with the ones hosted on spartacus, users would still have to update them.

Like new default jquery/lightbox classes, if we ever go that route.

Hmmm. I'm no jQuery wizard (Yet ), but maybe we could use it to somehow detect whether certain crucial styles are actually applied by a template, and add an extra class if not.

Something like this: Test whether a crucial CSS statement is set (like "Do images with the class serendipity_image_left have 'float: left'?"). If not, add a suitable CSS class (like 'float-left', which would be only .float-left { float: left; }, period). I'm not sure this is possible, let alone if it would mean JS overhead, but it's probably worth trying. (No, it would not work for people with JS deactivated. But I think that would be acceptable.)

YL

[Don Chambers]

It has been stated that the reason for this fallback stylesheet was to make sure that templates looked the same once inline styles are removed. Problem I have with that is a) the stylesheet goes farther than that, and most templates will, as a result, look DIFFERENTLY than they did before and b) we are loading a second stylesheet.

CSS is never universal - it is template specific. It should remain that way IMHO. If we believe certain common styles should be applied to certain templates, then lets do it. Otherwise, I continue to recommend these be left out of the core. If someone upgrades to 1.5, and notices a difference, then we can recommend "add this to your stylesheet", modifying as necessary for your particular needs".

Either that, or a template could be modified so as to import this fallback stylesheet if, and only if, the template designer wanted to include that specific css.

[garvinhicking]

Hi!

HTML5, for instance, could be that kind of roadblock.

We'll cross that bridge when we get there

Question on the side for you: We already have "Requires" as a minimum s9y version requirement for templates. Would it be possible to have sort of a "maximum counterpart"? Theoretically? Some rule saying "This templates only works w/ s9y up to version 1.5"?

Hm, basically we could add such a thing. But ideally, I would like to keep that back until it's really required, because if we put it in now we might get templates where people enter "Serendipity 2.0" without knowing if it'll ever stop working there. Once we have a template that doesn't work with new versions, we might introduce that, but only if no other solution can be found.

I'm still very sure that we can keep a degree of BC and still introducing new cleaner functionality, actually just like we did with the fallback CSS at this point.

Hmmm. I'm no jQuery wizard (Yet ), but maybe we could use it to somehow detect whether certain crucial styles are actually applied by a template, and add an extra class if not.

This would be possible, but puts a browser strain on evaluation, and people without javascript would hit a border case -- so I wouldn't rely on that, also because it has a performance impact for the visitor.

Don:

a) the stylesheet goes farther than that, and most templates will, as a result, look DIFFERENTLY than they did before and b) we are loading a second stylesheet.

If it goes to far, we need to adapt that stylesheet. I need your help (also YellowLED) on this, though. You are much more proven with the CSS of s9y than I am.

b) It's not really a second stylesheet, it all is bundled into a single stylesheet... (and it's even prepended to the style, so that a style.css can easily override it)

A certain amount of our CSS definitely is a framework, which we should rely on to have certain functionality across all templpates. This is also a unique distinction to WordPress - we do not have templates that are tottally incompatible with everything else, they mostly base on a common ground. And I'm really happy that this common ground is there to establish a certain "s9y branding" and something that other plugins can rely on to work on every template. I hate it that in WP certain plugins don't work in templates or you have to adapt them to get them started at all.

When someone updates to 1.5 and something is "off" - the damage is done, we might have lost that user because he's disturbed and won't even bother to care what the reason for this is.

Really. We cannot expect that a user gets into the CSS portion to investigate, and that he first has to download various other parts/template updates in addition to a s9y update to make everything work/display again. Plus, older templates might no longer be supported by an author and never get an update. Or think about people who got their custom templates and paid for them, then update s9y and have lost touch to the original designer. They might never be able to get him to rework the template, even though a single batch of 5 CSS lines would be sufficient to render the images.

Regards,
Garvin

[yellowled]

But ideally, I would like to keep that back until it's really required

Being an overthinker in every aspect, I guess I can accept that

If it goes to far, we need to adapt that stylesheet. I need your help (also YellowLED) on this, though. You are much more proven with the CSS of s9y than I am.

It should be enough to remove borders and background-colors for images from the media db. I'd also like to have the "font-size: 8pt;" for .serendipity_imageComment_txt replaced by a sensible value -- pt is fine for print stylesheets, but not for screen. I think "font-size: 75%;" would be suitable.

Plus, older templates might no longer be supported by an author and never get an update.

I still think there are lot of templates in the core we could/should drop, simply because they're outdated. We could archive them on spartacus.

They might never be able to get him to rework the template, even though a single batch of 5 CSS lines would be sufficient to render the images.

Well, they could still ask in the forum and would probably get help quickly

YL

[garvinhicking]

Hi!

It should be enough to remove borders and background-colors for images from the media db. I'd also like to have the "font-size: 8pt;" for .serendipity_imageComment_txt replaced by a sensible value -- pt is fine for print stylesheets, but not for screen. I think "font-size: 75%;" would be suitable.

All is fine with me, I fully agree to what you and/or Don and/or others want to check out, maybe if you have time to test changes with at least the shipped s9y templates and the most popular spartacus themes like mimbo (don'T know about others) that would be awesome.

I still think there are lot of templates in the core we could/should drop, simply because they're outdated. We could archive them on spartacus.

Yes, I think so too, we could loose some weight. Especially I think the mt* alternatives could be dropped and maybe reworked easily with a new config.inc.php that dictates 2-3 colour schemes.

Well, they could still ask in the forum and would probably get help quickly

I think there are still very many users that don't join our forum here, especially due to captchas, mail feedback for user activation etc...

I have a twitter search for "s9y" and "serendipity" and you wouldn't believe how many people complain there about trouble without ever asking here on the forum for very easy solutions to their problems.


Regards
,Garvin

[Don Chambers]

Well, it seems as if we will have to agree to disagree on this issue.