Thought about CSS files.
General pondering follows.
Back in early SMF 2.0.x dev days, they played around with the idea of breaking up index.css into smaller files. The way it was done ended up being a PITA, so it was decided to go with one big file, because it cut http requests and arguably made things easier to find.
Problem is that it's more css to parse on every page, so all things considered it's arguably worse for performance. The fastest CSS declaration is the one that doesn't exist.
I was thinking about this stuff last night, and I think I have an idea which could work. Splitting the file up makes sense in the case of admin and moderation stuff, which the vast majority of users/guests will never see. So, I started thinking about which other pages they will hardly ever see.
Over the years I've been using forum software I've found that if, I'm an admin on the site, I will visit the memberlist sometimes (not that often) , the forum stats page even less often, the calendar less often than the stats, and the profile stats pages never (or hardly ever). If I'm not admin, I will hardly ever look at the memberlist or calendar, and the forum and profile stats even less frequently.
This makes four areas that are hardly ever viewed, and if they are combined into one calendar_mlist_stats.css they account for roughly 7kb of CSS at the moment. If someone wants to do something like my SMF memberlist mod, that would increase to around 10 or 11 kb (un-minified). In rough terms, this amounts to about 10% of the total css, so the split may be worthwhile.
Re: Thought about CSS files.
Reply #1 –
Splitting out admin should take a good chunk out of it. I don't see a problem with doing the less visited areas too. Can it be kept to just the few you mentioned though? I see the possible rabbit whole this could lead to. lol
Re: Thought about CSS files.
Reply #4 –
Don't forget that CSS files are cached by the browser. It's only a heavy load that first visit. In my SMF fork, I managed to combine all the CSS files into one(except for rtl/editor) and it still doesn't exceed 2500+ lines. It's very lightweight, and loads rather easily. It just depends on how you do your theme.
If you decided to do more than one CSS file, then I recommend only doing two. One for styles loaded on every page, and the second for styles loaded strictly for that page. Although, I have never done this with a forum software(mostly other softwares), but I imagine it's possible.
All in all I don't see the point in creating a mass number of files that just get cached anyways.
Re: Thought about CSS files.
Reply #11 –
Because it provides the framework people want.
Ok, re the simple looking almost-no-styles variant idea. I think what you really want is a sort of "Elk boilerplate" variant stylesheet. In other words, one that pulls all layout and dimensioning from index.css, but only has enough colours etc of its own so that people can just tell what is what. Apart from that, it's a blank slate.
That's easy to do, but I'd do it as a separate file. IF someone wants to use it, they can. I wouldn't make that "the default theme" though. I'd consider it to be just a tool in the toolbox, if that makes sense.
Again, making something like this is not hard. It's basically just taking the default variant stylesheet and throwing stuff out. That's a piece of cake.
The "boilerplate ZOMG that's white" stylesheet can be either offered as a standalone download, or included as a third variant sheet in the install package. Whatever.