Thought about CSS files.

Topic: Thought about CSS files. (Read 24037 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Thought about CSS files.

June 15, 2013, 06:15:15 pm

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 – June 15, 2013, 10:28:23 pm

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 #2 – June 15, 2013, 10:45:08 pm

Better add something to this. Yes, it's another Ant Rant! Yay!

Please bear with me, as it is useful information. It's about this: https://github.com/elkarte/Elkarte/pull/525#issuecomment-19503585

There are two (sane) ways you can do multi-variant themes.

The first way will make it easiest for beginner themers to turn out basic colour variations that don't touch anything else. If that is your main objective, that's fine, but it will incur a performance penalty.

The second way will give best performance, but anyone who just wants to make a basic variant will have to dig through more code.

The first way is to have a basic index.css which only contains code for layout and dimensioning, with absolutely no code for background, colours, images and any other eye candy. All the eye candy goes in the variant.css file.

If you just want to change a few colours, this way is convenient because the variant.css file will be quite small and easy to work with. I used to use this method back when I first made multi themes, where the variants were just eight or so different colours. Doing it this way also minimises the total amount of CSS that has to be stored on the server.

There's a catch. It's worse for performance. The performance hit comes in two ways. You have two http requests instead of one. Also, despite having less CSS stored on the server, the amount of CSS that has to be parsed on each page load is increased. This happens because you have to declare quite a few things twice.

Take the example of the main forum wrapper div. Currently it's this in index.css:

Code: [Select]

#wrapper, .frame {
	margin: 0 auto;
	width: 95%;
	max-width: 100em;
}
#wrapper {
	margin-top: 20px;
	background: #fbfbfb;
	border: 1px solid #444;
	border-radius: 8px;
	box-shadow: 0 3px 4px #222;
}

If you want to split that into an index.css and a variant.css, you would use this in index.css:

Code: [Select]

#wrapper, .frame {
	margin: 0 auto;
	width: 95%;
	max-width: 100em;
}
#wrapper {
	margin-top: 20px;
}

...and you would also have to use this in the variant.css:

Code: [Select]

#wrapper {
	background: #fbfbfb;
	border: 1px solid #444;
	border-radius: 8px;
	box-shadow: 0 3px 4px #222;
}

Now that isn't much more code in total, but that's just one example. When it comes to things like drop menus the amount of bloat increases. From past experience doing multi-variant themes, the increase in CSS to be parsed on each page load will be at least 10%, and possibly up to double that (depending on how clever they get).

So, that's the catch with doing it that way.

The second way of doing it is for every variant to only have a complete variant.css file that does everything, with index.css being deprecated. This saves an http request, and will probably save at least 10% on CSS parsing per page load. Obviously, if you're concerned with performance you should do it this way.

The catch with doing it this way is that you will have to store more CSS on the server (which IMO is not a significant consideration) and that if someone just wants to change a few things they will have more code to hunt through. That can be a bit of a nuisance for beginners.

So, it comes down to what you want to optimise for. Take your pick.

Re: Thought about CSS files.

Reply #3 – June 15, 2013, 10:49:51 pm

Quote from: IchBin – June 15, 2013, 10:28:23 pmSplitting 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

Admin is already split out. I was just wondering if anything else could usefully be done.

Re: Thought about CSS files.

Reply #4 – June 15, 2013, 11:43:49 pm

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 #5 – June 15, 2013, 11:54:35 pm

Ok, after lunch thought, just before I go back to cleaning up the garden.

If you really want to be innovative, here's another option. Say you want to ship default with two variants: light and dark. You want to make it easy for teh n00bz to play with colours for their sites, but you're also concerned about performance on big sites. Say you want the best of both worlds.

Ok, within reason, this is possible. From my point of view, the hard work here is getting the theme sorted to start with. Once that's done, splitting or collating sorted CSS into one or many files is a piece of cake. That's just basic search and compare stuff and can be done very quickly.

So, what you could do is have a choice of two settings in admin. Let's call them "pretty colourz" and "blazing fast". If "pretty colourz" is selected, a conditional in index.template,.php would call index.css. This would be a stripped index.css that only does layout. Along with the stripped index.css it would call the simple, eye-candy-only, variant.css file. This is the way teh n00bz will like it.

If "blazing fast" is selected in admin, the conditional in index.template.php does something different. It doesn't call index.css, and it doesn't call the basic eye-candy-only variant.css. Instead, it only calls a full-on-oh-si-we-haz-a-plethora variant_2.css file (called variant_2 to distinguish it from the other version).

Both of these options would look the same when rendered in the browser, but one offers greater ease of basic customisation, and the other gives better performance.

If people want to do this, it is extremely easy to arrange it. It would mean twice the number of variant CSS files stored on the server, but it does conceivably have some advantages.

Now I go back to garden.

Re: Thought about CSS files.

Reply #6 – June 15, 2013, 11:58:29 pm

Quote from: Xarcell – June 15, 2013, 11:43:49 pmDon't forget that CSS files are cached by the browser. It's only a heavy load that first visit.

I'm not forgetting about caching at all. You're forgetting about parsing.

Sure, in terms of load on the server, the CSS files only get downloaded once. That's not the same as what happens in the browser. I'm talking about how it all renders for the end user. If you do it the second way, there is more CSS to be parsed on every page load.

The most efficient way of handling it, both in terms of initial server load and rendering in the browser, is for each variant to only call one file which does everything. OTOH, it makes tweaking colours harder for n00bz.

ETA: Oh and the point about splitting stuff like admin and stats out is that it is stuff the majority of visitors to the site will never want to use anyway, so splitting it out means you don't have to cache it at all. That's better for the server and better for the browser.

ETA again: Actually, in performance terms the whole variant system sucks. Really, if you want best performance, you should strip the whole variant system out of the software and just run separate themes.

Re: Thought about CSS files.

Reply #7 – June 16, 2013, 02:28:46 am

Quote from: AntechinusYou have two http requests instead of one.

Elk combines variant css and most js into one single file (each) to be sent over, and then, it minifies of those files. It's already more efficient that SMF 2.0.
So there are no two http requests for variants, not even the first time (assuming the admin has enabled combine/minify feature of course): a single file is sent to the client. (as much as possible, anyway)

Quote from: hive_number file/* http://localhostish_elk/themes/default/index.css index_green.css */
// combined and minified code follows.

IIRC this has been mentioned before.
The server also keeps a cache of its combined and minified files.

To address runtime performance, these are much better ways than writing lots of code in a single file hardcoding everything.
To address easy extensibility, what Elk had started is to separate code within reason, in variants, and/or rarely customized css, so that it's handy during customization time. Development/customization time != runtime.

Quote from: StealthWombatThis is the way I always used to do multi themes, and as you pointed out it does make editing much easier. I'm happy to set it up that way.

(https://github.com/elkarte/Elkarte/pull/525#issuecomment-19503585)
Sounds great, and about the best trade-off for easy customizability, give or take some basics.

At least for the additions that would otherwise need cleaned up to even begin customizing. Wherever the limit is, I don't think it is in a single file for all colors, and other nice UI additions like shadows.

Re: Thought about CSS files.

Reply #8 – June 16, 2013, 02:46:30 am

Yeah, there's always flexibility vs. performance...

Quote... is for each variant to only call one file which does everything. OTOH, it makes tweaking colours harder for n00bz.

This. Harder or almost impossible for noobz, time consuming for skilled designers.. I've spend more than 4 hours to get my "green" variant back and I'm still not done (maybe, I'm considered a noob LOL).
index.css should imho be more of a framework.css with all that basic stuff (positions, light grey styling, a lightweight dropmenu ...) similar to bootstrap.

Colors, custom styling, box-shadows, after: content etc. should move to variant.css

IMO perfomance and all that is nice, but flexibility, easiness and code readability for the designer (a noob or a skilled one) is priority..
Take a look at:

Code: [Select]

/* Level 1 hover effects. */
#menu_nav .active, #menu_nav li a:hover, #menu_nav>li:hover>a, #menu_nav li a:focus, #menu_nav>li:hover>a, #menu_nav>li>a:focus,
#admin_menu li>a:hover, #admin_menu>.dropmenu>li>ul>li:hover>a, #admin_menu li a:focus,
#adm_submenus li a:hover, #adm_submenus li a:focus {
	background: #efefef url(../images/theme/lower_section.png) 0 8px repeat-x;
	color: #444;
	border: 1px solid #bbb;
	text-decoration: none;
}

Do you think the "average designer" is skilled enough to make the dropmenu the look they want?

Re: Thought about CSS files.

Reply #9 – June 16, 2013, 04:40:04 am

Well, they should be able to, since all they have to change is background, border, etc. But yes, the sheer amount of code will be intimidating for many.

I just wanted to be clear about what the trade-offs were. Norv mentioned "getting rid of redundant CSS" at Github, and I felt everyone shoud be clear that using index.css + variant.css actually makes for more redundant CSS, not less, and if you really want less you have to do it the n00b-scary way.

Not that I mind going for n00b-friendly, as long as everyone is clear on the side effects of it.

I have to disagree with this though:

Quote from: TE – June 16, 2013, 02:46:30 amindex.css should imho be more of a framework.css with all that basic stuff (positions, light grey styling, a lightweight dropmenu ...) similar to bootstrap.

No, I would not go with this suggestion. It's the worst of both worlds.

If you want ease of basic customisation, do not put any colours or backgrounds at all in index.css. None. Nothing. Nada. Zip. Why? Because it's useless code. You will probably just have to override it in the variant.css anyway.

If you want index.css to be basically a framework.css, which I am quite happy with as I've done it myself several times, then make it one and do it properly. Everything related to colours should go in the variant.css.

The idea that you have to have a bare bones, bargain basement "default theme" simply because it can only have some very basic styles, with an empty placeholder variant file, because you're scared of making it hard to modify, is totally the wrong way to do it.

Make the default look awesome. Go for it. Hold nothing back. But, put all of that eye candy in the variant file. That way, if someone wants to make a new variant, or change an existing one, it is still easy. In fact, it's even easier.

Trust me on this. I've done it before.

However, and this is purely personal preference, I would honestly prefer to do this a bit later, not right now. Right now I just want to get the default looking slick everywhere, as well as getting rid of all cruddy CSS. I'm doing both at once. I would prefer to be able to do it without having to jump between CSS files. For me, it will be easier to sort default first, then pull all the colours, backgrounds, gradients, dancing bananas and ponies that fart rainbows out of index.css and put it into the variant file.

The result is stll the same, but it's less trouble in the meantime (IMHO).

Re: Thought about CSS files.

Reply #10 – June 16, 2013, 05:14:16 am

Quote from: Antechinus – June 16, 2013, 04:40:04 amI have to disagree with this though:

Quote from: TE – June 16, 2013, 02:46:30 amindex.css should imho be more of a framework.css with all that basic stuff (positions, light grey styling, a lightweight dropmenu ...) similar to bootstrap.
No, I would not go with this suggestion. It's the worst of both worlds.

IMHO it's not, why do you think bootstrap is a very popular framework?

TE is tempted to write a full featured theme from scratch, anyway...

Re: Thought about CSS files.

Reply #11 – June 16, 2013, 05:19:26 am

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.

Re: Thought about CSS files.

Reply #12 – June 16, 2013, 08:10:12 am

Quote from: Antechinus – June 16, 2013, 05:19:26 amOk, 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.

You mean in the sense of default look and feel of the new installation for users? Set the default variant to the _green variant.
Thereby, the default look and feel is cool, good looking and pleasant to work with, for all forums; and, on the other hand, the interested customizer has at their disposal css with bare-bones basics.
I don't see the problem on this particular point, sorry. Am I misunderstanding something? Please, say so in that case.

Re: Thought about CSS files.

Reply #13 – June 16, 2013, 09:07:10 am

Yes, that's what I mean. I agree it's not a problem. However, it's not what TE was suggesting (unless I misunderstood). The impression I got was that he, and you for that matter, thought the default presentation should be absolute bare bones basic white, with the colours etc for that being presented in index.css. That's what I think is a bad idea.

If everyone is ok with having both light and dark defaults that look cool, with index.css being purely a layout framework, and the bare bones stylesheet as a boilerplate tool, then I think we're all on the same page.

I can make such a boilerplate file very easily. If doing that, I'd even go so far as to not use any hex codes at all for the minimal colours that might be required. I'd do it all with named colours, so it's even easier for n00bz. If they see a hex code it may not make sense to them,. If they see color: lightgray; they will be able to relate that to what they see in their browser.

I had another idea too. That bit of drop menu CSS that TE posted got me thinking. If I add classes to the dropmenu li, a, and ul elements this will simplify CSS and variant creation. At the moment they only have the dropmenu class on the top ul. That means defining things further down the pecking order requires descendant selectors. This is good for minimal markup, but not good for minimal CSS.

Say classes are added like this:

Code: [Select]

<ul class="dropmenu">
    <li class="lvl1_li">
        <a class="lvl1_a">Title</a>
        <ul class="submenu_lvl2">
            <li class="lvl2_li">
                <a class="lvl2_a">Title</a>
                <ul class="submenu_lvl3">
                    <li class="lvl3_li">
                        <a class="lvl3_a">Title</a>
                    </li>
                </ul>
            </li>
        </ul>
    </li>
</ul>

Doing that will slightly increase bandwidth usage and load on the server, but not a lot. However, it should dramatically simplify targeting of any dropmenu elements, which will mean simpler CSS. It also has the benefit that the selectors are more efficient by nature, since selection by HTML tag and descendant selectors are some of the least efficient ways of applying CSS rules.

So instead of needing this:

Code: [Select]

.dropmenu li li a, .dropmenu li li li a {...

You would just need this:

Code: [Select]

.lvl2_a, .lvl3_a {...

Re: Thought about CSS files.

Reply #14 – June 16, 2013, 10:11:41 am

Quote from: Antechinus – June 16, 2013, 09:07:10 amIf everyone is ok with having both light and dark defaults that look cool, with index.css being purely a layout framework, and the bare bones stylesheet as a boilerplate tool, then I think we're all on the same page.

emanuele likes this.

Quote from: Antechinus – June 16, 2013, 09:07:10 amSay classes are added like this:
Code: [Select]
<ul class="dropmenu">
    <li class="lvl1_li">
        <a class="lvl1_a">Title</a>
        <ul class="submenu_lvl2">
            <li class="lvl2_li">
                <a class="lvl2_a">Title</a>
                <ul class="submenu_lvl3">
                    <li class="lvl3_li">
                        <a class="lvl3_a">Title</a>
                    </li>
                </ul>
            </li>
        </ul>
    </li>
</ul>
Doing that will slightly increase bandwidth usage and load on the server, but not a lot. However, it should dramatically simplify targeting of any dropmenu elements, which will mean simpler CSS. It also has the benefit that the selectors are more efficient by nature, since selection by HTML tag and descendant selectors are some of the least efficient ways of applying CSS rules.

So instead of needing this:
Code: [Select]
.dropmenu li li a, .dropmenu li li li a {...
You would just need this:
Code: [Select]
.lvl2_a, .lvl3_a {...

Mixed feeling here.
At first sight seems a bit complex to read, though it sounds interesting.