[RFC|Rejected] Removal of subsilver2

[code reader]

My view on subsilver2:

• It causes extra work during development, that is not helping phpBB's main goal of becoming a better forum software
• It causes extra work for MOD authors to support two very different templates - many don't even bother support both templates
• Keeping two very different base templates up to date with MODs is a lot of work for users

So I agree that the best choice would be to get rid of it. We can still look into building a subsilver3 with CSS and some very few template changes with most stuff inherited.

one comment and one request:
comment:
currently, prosilver is performance-hostile. in some situations (slow servers and/or slow internet links) subsilver a a lifesaver.
getting rid of it might be a good thing, but IMO a preliminary essential step would be to fix prosilver performance issues.

request:
we invested countless hours ("we" as in 'shs, dhn and myself mainly in bug-reporting capacity, though i did contribute some patches too) making subsilver RTL-friendly.
then when prosilver was exposed (you can't imagine how grateful i was for the accident that forced its premature exposure - the original psotfx plan was to expose it on the day of releasing gold, if you can imagine that), we invested a second batch of countless hours making prosilver RTL-friendly.
please, if you want to replace subsilver with a prosilver-derivative or completely new CSS-based subsilver lookalike, *please* get at least one RTL-nik in the loop before unleashing it on the public.

thanks.

[naderman]

Since I hadn't addressed your points in my previous post here goes:

i think that the main issue here is style inheritance.
since we do support style inheritance now, i think that the question is: how many existing subsilver-based styles use it?
if there are some who do, to stop supporting it would mean that we deprive the developers of those style of the option of the option to upgrade to 3.1.

imo this would be a bad thing.
however, if all the subsilver styles are done in cut/paste, i do not see a huge problem with stopping the support.
maybe one of them will publish a "how to upgrade your subsilver based style to 3.1" on the wiki...

I agree that this is a problem and it might certainly be useful if someone were to maintain the subsilver2 template for 3.1, but I do not think it is important enough to put a lot of resources into that. If we can we should definitely provide instructions on how to upgrade, although I imagine that to be a process difficult or impossible to explain to regular users.

of course, a different issu altogether is the necessity to fix prosilver, especially where performance is concerned.
we know for some time now that prosilver has some serious issues, specifically around the use of css:
-- style.php is expensive, performance-wise.
-- unlike subsilver, the cache does not work as intended: modifying one of the .css files does not trigger automatic recompilation. i think it's becuase of the @inclusion, but i am not sure.
-- the whole "css in the database" is a mess.

in short: prosilver needs some fixin', not in the .html or .css, but in the php mechanism that handles the css.
this is not directly related to stopping the support for subsilver, except that for some time now subsilver was the "last resort" of those who got burned by one of prosilver issues mentioned.

Chris has already worked on these issues in the feature/ascraeus-experiment branch. Current intent is to use that code for 3.1. This means we will drop support for database stored css and get rid of a php request for "dynamic" styles by pre-compiling them for all language/template/imageset combinations. Apart from that, you're welcome to suggest improvements to the style itself, although we should really start a new topic for that

request:
we invested countless hours ("we" as in 'shs, dhn and myself mainly in bug-reporting capacity, though i did contribute some patches too) making subsilver RTL-friendly.
then when prosilver was exposed (you can't imagine how grateful i was for the accident that forced its premature exposure - the original psotfx plan was to expose it on the day of releasing gold, if you can imagine that), we invested a second batch of countless hours making prosilver RTL-friendly.
please, if you want to replace subsilver with a prosilver-derivative or completely new CSS-based subsilver lookalike, *please* get at least one RTL-nik in the loop before unleashing it on the public.

I do remember Paul's ideas on keeping the style secret until last minute and never quite liked that idea. There is not going to be any private style development of any kind. So no such issues should arise in the future.

[code reader]

thanks, on all accounts.
dropping "css in db" is a good thing, imo.
i have no suggestions for improvements. fwiw, i think subblue did a spectacular job with prosilver, and even though several years have passed, no other forum that i saw so far have closed the gap. (i think i mentioned it in the phpbb4 discussion, something to the effect that getting subblue to do the rhea style is "almost essential").
but even if i did not think so highly of prosilver, there is little chance of me suggesting improvement - i'm just not style-oriented...

(well, there is one thing - i would like to see "last post subject" in index and forum view. the software provides it, and some styles use it. if we don't want to "contaminate" the purity of the front page, we can use the "title" and show is as a tooltip)

the one thing that is "sort of kind of" in the code but i don't think works now (maybe because of "css in db", but maybe other reasons also) is force recompilation when any css file change. the subsilver logic is to look at stylesheet.css timestamp, but for prosilver "stylesheet" is just a shell with many includes, so we need to look at the content of the directory.
(btw: does the "cache-refresh" timestamp-based logic works as it's supposed to if the .html files use <!-- INCLUDE --> ? )

peace.

[naderman]

i have no suggestions for improvements. fwiw, i think subblue did a spectacular job with prosilver, and even though several years have passed, no other forum that i saw so far have closed the gap. (i think i mentioned it in the phpbb4 discussion, something to the effect that getting subblue to do the rhea style is "almost essential").

I've mentioned the idea to him, but it'll be hard to convince him But there's a lot of time left for that.

the one thing that is "sort of kind of" in the code but i don't think works now (maybe because of "css in db", but maybe other reasons also) is force recompilation when any css file change. the subsilver logic is to look at stylesheet.css timestamp, but for prosilver "stylesheet" is just a shell with many includes, so we need to look at the content of the directory.

Actually, unless I'm very mistaken there is logic in there which parses all the @imports. How else would we get the whole stylesheet into the database?

(btw: does the "cache-refresh" timestamp-based logic works as it's supposed to if the .html files use <!-- INCLUDE --> ? )

Yes.

[MattF]

Agreed with Nils mention that subsilver2 makes extra work for all! When I made my last mod it was so neat and tidy - then I looked into adding it to subsilver2 and I had to create a whole new set of variables and extra code just to get it to work with subsilver2...

Honestly the worst thing about subsilver2 right now is that its inclusion with phpBB3 has allowed it to propogate as style developers continue to create brand new phpBB3 styles based off of subsilver2!!! It simply needs to be eliminated, so all styles can be based off a single model, and savvy developers would be able to create styles with the look and feel of subsilver - but still be based on Prosilver - and I hope phpBB can pull that off with subsilver3 if they choose to tackle that.

But phpBB should give the community a good notice ahead of time to allow style authors to upgrade their styles before subsilver2 support is dropped.

[Oleg]

Can someone explain what is so bad about subsilver for those of us who are not styling experts?

Clearly all style changes need to be made twice, but if subsilver and prosilver are genuinely different and some users prefer subsilver, why would these users be happy with prosilver should subsilver be dropped?

I want to give my users a few styles to choose from, and several of them are subsilver based. I have a couple of modifications installed and while they are simple I don't see the big deal with making changes to two styles.

[naderman]

Can someone explain what is so bad about subsilver for those of us who are not styling experts?

Clearly all style changes need to be made twice, but if subsilver and prosilver are genuinely different and some users prefer subsilver, why would these users be happy with prosilver should subsilver be dropped?

subsilver uses a lot of tables making it quite inflexible and it is hard to style with CSS alone. prosilver is designed to be very flexible, you should be able to make it look entirely different with CSS alone, or at least with only very small changes to the template (e.g. header/footer). The use of tables also makes MODs more complicated (rowspan/colspan for example). People who like the look & feel of subsilver should be satisfied by a style looking the same way but done with prosilver + subsilver CSS.

I want to give my users a few styles to choose from, and several of them are subsilver based. I have a couple of modifications installed and while they are simple I don't see the big deal with making changes to two styles.

Do those MODs come with instructions for your subsilver based styles? The big problem are MODs that only come with the changes for one style. For those you actually need to make the modifications yourself. That requires knowledge of html/css/templating etc.

[code reader]

Actually, unless I'm very mistaken there is logic in there which parses all the @imports. How else would we get the whole stylesheet into the database?

surely we interpret the @import when compiling style.php, but this does not necessarilly mean we take it into account when *deciding* to recompile ("refresh cache").
this happens at a different point in the code.
ttbomk, some changes require the user to manuall instruct phpbb to "refresh cache", but it should be enough to modify one of the files: the system should sense that a refresh is required.
now i think the logic is there, i am just not sure it's actually working, with "css in db" muddying the waters.
so all i meant to say is that as part of the cleanup, we want to make sure the recompilation logic actually works.

peace.

[imkingdavid]

I think subsilver2 should be retired. I was sort of unhappy when I first saw that two styles were being shipped by default. Prosilver is more modern, both in frontend design, and in the coding infrastructure. Tables only allow limited possibilities as far as design, but CSS + Divs allow LOTS of possibilities. I'm not saying that subsilver2 is poorly made, but I think that prosilver should be kept and subsilver2 should be dropped.

It's also a pain to have both when trying to make a MOD. That's more work for both the author and the MOD Team when validating, as they have to both test it on both styles to make sure everything works. And same with the development team, both styles need to be supported in new versions.

I know how tough it is to try and support two styles on a live site when modifications are made and such, and I think that it's just, as you put it, a "thorn in the side".

[Desdenova]

Actually, unless I'm very mistaken there is logic in there which parses all the @imports. How else would we get the whole stylesheet into the database?

surely we interpret the @import when compiling style.php, but this does not necessarilly mean we take it into account when *deciding* to recompile ("refresh cache").
this happens at a different point in the code.
ttbomk, some changes require the user to manuall instruct phpbb to "refresh cache", but it should be enough to modify one of the files: the system should sense that a refresh is required.
now i think the logic is there, i am just not sure it's actually working, with "css in db" muddying the waters.
so all i meant to say is that as part of the cleanup, we want to make sure the recompilation logic actually works.

peace.

ACP->Load Settings->Recompile stale style elements.

Because the theme files are parsed through style.php, they are cached to reduce load. The "sensing" that something has changed would create a bit of load on more heavily used sites, so it's off unless recompile stale style elements is on. When you consider the CSS parsing stuff, it makes sense, in order to keep resource use down.

It causes extra work for MOD authors to support two very different templates - many don't even bother support both templates

Very true. In fact, because of the unflexible nature of subsilver2, I have and will forevermore flat-out refuse to support it in my modifications.