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.
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
Better add something to this. Yes, it's another Ant Rant! Yay! :D
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:
#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:
#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:
#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. 8)
Admin is already split out. I was just wondering if anything else could usefully be done.
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.
Ok, after lunch thought, just before I go back to cleaning up the garden. :D
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. :)
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.
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)
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.
(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.
Yeah, there's always flexibility vs. performance...
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:
/* 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?
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:
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).
IMHO it's not, why do you think bootstrap is a very popular framework?
/me is tempted to write a full featured theme from scratch, anyway...
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.
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.
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:
<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:
.dropmenu li li a, .dropmenu li li li a {...You would just need this:
.lvl2_a, .lvl3_a {...
/me likes this.
Mixed feeling here.
At first sight seems a bit complex to read, though it sounds interesting.
Well it could use different class names if you're worried about that. I just chose the least verbose, and based on tag name. If you're worried that the example markup itself seems harder to read with classes added, don't be. Any markup looks like hell once it's shoved into a PHP template. :D
This is more than interesting. I'm kicking myself that I didn't think of it before. It has the potential to vastly simplify the huge pile of code related to all the dropmenus. The big advantage of it is that it will be a lot simpler to stop stuff you don't want cascading. I'm going to get it all written up and running live on local.
ETA: Changes will involve deprecating the dropmenu class as such, and just relying on #main_menu, #admin_menu, #adm_submenus, .poster and .quickbuttons to specify ul. That will involve a minor edit where superfish is initialised. No big deal.
It will be much better this way. The main menu, admin drops, sidebar menu, etc can still share most of the css for their droppy bitz (coz they all look the same anyway), but how it's specified will be simpler.
The simpler, the better indeed...
Here's how I'm doing it in Wedge, which as you'll remember is using my own CSS precompiler, so it's a bit of a cheat...
- You can ask Wedge to entirely scrap a CSS file, and replace it with yours, and keep the rest. (Dynamically.)
- 'reset' keyword: allows you to selectively remove all styling associated with a certain selector. Then, you can re-style it on your own terms.
- '@replace' command: allows you to simply target a rule (or several), and replace it (them) on the fly.
These are some of the things that I wrote with themers in mind, but I keep asking myself, are they frigging going to notice these exist at all..? I don't know, but I sure hope they will.
I think that the future of CSS, is in preprocessors, because CSS has been way too slow to implement simple useful things like CSS variables, and even then, their current implementation isn't exactly very CSSish. Heck, even Less's implementation is more it...
Had I known that Less had a PHP implementation back in 2010, I wouldn't have written my own, but by this point, there's too much in Wess that's not in Less, that I don't really see a point in making the switch. (Heck, they only recently implemented extends, which I was adamant they had since their first version...! What a surprise, really...)
Ok, been thinking. Will compromise with Teh Norv. Yes, radical notion, but I believe it is possible. :D
I'll make three new variant files/folders: _light (current default here), _dark (placeholder for now) and _basic (also placeholder for now).
I wont get into stripping index.css down to pure framework yet, just to keep up momentum. But, as soon as an area of presentation is finished (like the calendar is now) I'll split that into framework (index.css) and eye candy (index_light.css). This should keep momentum up while getting a start on the final arrangement.
Cool? :)
ETA: Oh and I've decided on this for a naming scheme for drop menu elements. After trying a pile of options, these seem like the clearest and easiest to read. Adding underscores into the class names just makes them less legible IMO.
<ul> #main_menu /* Menu bar: wrapper/background. */
<li> listlevel1 /* List positioning: not shown. */
<a> linklevel1 /* Menu bar: link or button. */
<ul> menulevel2 /* Drop menu: wrapper/background. */
<li> listlevel2 /* List positioning: not shown. */
<a> linklevel2 /* Drop menu: link or button. */
<ul> menulevel3 /* Next drop menu: wrapper/background. */
<li> listlevel3 /* List positioning: not shown. */
<a> linklevel3 /* Next drop menu: link or button. */
Ok, just as an example of how it's panning out, I've split the main/admin drop menu and sidebar menu coding into basic layout stuff that holds it all together (in index.css) and eye candy (in the_variant.css).
This has been done for two variants: the cool one that runs here, and a dead basic one that is as simple as possible, as a basis for n00bz and others to play with in their quest for coolness.
To run properly, these need images folders in themes/images, and calls for the variants in index.template.php, and language strings, etc. So, I'm not putting everything here, but these are the relevant excerpts from the three CSS files. Spacing and commenting can be altered, but I think it's pretty clear already.
index.css/* Styles for the standard dropdown menus. */
/* --------------------------------------------------*/
/* @todo - Lots of interdependent revision here to minimise code. */
/* This is layout code only. All the eye candy is in the _variant.css. */
/* NOTE: This layout code should NOT be altered */
/* unless you are really sure of what you are doing. */
/* ALL variants depend on this basic layout code for stability. */
/* ----------------------------------------------------------- */
/* Visible menu bar: wrapper/background. */
#main_menu {
position: relative;
margin: 6px;
padding: 5px 8px 4px 8px;
}
/* @todo - Collect all pseudo clearfixes in one declaration. */
#main_menu:after {
content:"";
display: block;
clear: both;
}
/* Wrapper for secondary admin/profile/etc menus- positioning only. */
#adm_submenus {
padding: 10px 15px;
overflow: auto;
}
/* Level 1 button positioning. No visible styling. */
/* 1px padding gives slight gap between buttons, and drop menus. */
.listlevel1 {
padding: 1px;
float: left;
line-height: 2.3em;
position: relative;
}
/* For the upshrink button in the main menu bar. */
#collapse_button {
position: absolute;
top: 4px;
right: 8px;
}
#upshrink {
padding: 4px 9px 3px 9px;
}
/* Level 1 Menu bar: link or button. General sizing. */
#main_menu .linklevel1, .admin_menu .linklevel1, #adm_submenus .linklevel1 {
padding: 0 0.5em;
display: block;
}
/* Levels 2 and 3: drop menu wrapper. */
.menulevel2, .menulevel3 {
z-index: 90;
position: absolute;
top: 100%;
left: -9999px;
width: 18.2em;
padding: 0.5em;
}
/* Level 3: drop menu positioning. */
.menulevel3 {
margin: -2em 0 0 15.3em;
}
/* Reposition Level 2 drop menu as visible on hover. */
/* @todo - Check Superfish class. I think .sfhover may be deprecated. */
.listlevel1:hover .menulevel2, .listlevel1.sfhover .menulevel2 {
left: 1px;
}
/* Hiding Level 3 drop menu off hover. */
.listlevel1:hover .menulevel3, .listlevel1.sfhover .menulevel3 {
left: -9999px;
}
/* Reposition Level 3 drop menu as visible on hover. */
.listlevel2:hover .menulevel3, .listlevel2.sfhover .menulevel3 {
left: -14px;
}
/* Level 2 and 3 button positioning. No visible styling. */
/* 1px vertical padding gives slight gap between buttons. */
.listlevel2 {
padding: 1px 0;
width: 17em;
position: relative;
float: none;
}
/* Levels 2 and 3 drop menus: link or button. */
.linklevel2, .linklevel3 {
position: relative;
line-height: 2.2em;
padding: 0 7px;
display: block;
}
/* @todo - Note: The next declarations are for keyboard access with js disabled. */
/*.dropmenu ul a:focus, .dropmenu ul ul a:focus {
margin-left: 9990px;
border: none;
width: 17em;
}
.dropmenu ul ul a:focus {
margin-left: 19950px;
}
/* @todo - Cancel those for hover and/or js access. */
/*.dropmenu ul li:hover a:focus, .dropmenu ul li.sfhover a:focus {
margin-left: 0;
width: auto;
} */
/* Styles for sidebar menus.
------------------------------------------------------- */
#main_container {
position: relative;
}
/* @todo - Collect all pseudo clearfixes in one declaration. */
#main_container:after {
content:"";
display: block;
clear: both;
}
#main_admsection {
position: relative;
left: 0;
right: 0;
overflow: auto;
}
#menu_sidebar {
width: 185px;
float: left;
padding: 0 10px 1em 0;
}
#menu_sidebar .catbg {
padding: 5px 8px;
font-size: 1.1em;
}
#menu_sidebar .sidebar_menu {
padding: 4px 0 9px 0;
}
/* Same styling for Level 1 and Level 2. */
#menu_sidebar .listlevel1 {
padding: 1px 0;
line-height: 2em;
float: none;
}
#menu_sidebar .linklevel1, #menu_sidebar .linklevel2 {
display: block;
padding: 2px 7px;
}
#menu_sidebar .listlevel1:hover .menulevel2, #menu_sidebar .listlevel1.sfhover .menulevel2 {
top: -1px;
left: 160px;
}
/* @todo - Check these again. */
/* Note: The next declarations are for keyboard access with js disabled. */
#menu_sidebar .linklevel2:focus {
margin-left: 10150px;
width: 17em;
}
/* @todo - Check these again. */
/* Cancel those for hover and/or js access. */
#menu_sidebar .listlevel2:hover .linklevel2:focus, #menu_sidebar .listlevel2.sfhover .linklevel2:focus {
margin-left: 0;
width: auto;
}
/*End sidebar flyout coding. */
_light.css (the one you see here)
/* This variant is the standard, light, Elkarte default theme. */
/* ----------------------------------------------------------- */
/* This is eye candy only. All the layout code is in index.css. */
/* NOTE: The layout code in index.css should not be altered
/* unless you are really sure of what you are doing.
/* ALL variants depend on the basic layout code for stability. */
/*----------------------------------------------------------- */
/* Styles for the standard dropdown menus.
----------------------------------------------------------- */
/* Visible menu bar: wrapper/background. */
#main_menu {
background: #4b863c;
background-image: linear-gradient(to bottom, #5BA048 0%, #3d6e32 100%); /* W3C */
border-radius: 6px 6px 0 0;
}
/* Needed for new PM notifications. */
.listlevel1 strong {
color: #fff;
}
/* Level 1 Menu bar: link or button. General sizing. */
#main_menu .linklevel1, .admin_menu .linklevel1, #adm_submenus .linklevel1 {
/* If there will be a border on hover, ensure there is a default border. */
/* Applying a default transparent border stops links jumping on hover. */
border: 1px solid transparent;
border-radius: 4px;
color: #fff;
}
/* Override link colour for admin/profile/etc menus. */
.admin_menu .linklevel1, #adm_submenus .linklevel1 {
color: #444;
}
/* Level 1 button hover and focus effects. */
#main_menu .active, /* Level 1 active button shares same styling. */
#main_menu .linklevel1:hover, #main_menu .listlevel:hover .linklevel1, #main_menu .linklevel1:focus,
/* For primary admin/profile/etc drop menus. */
.admin_menu .linklevel1:hover, .admin_menu .linklevel1:focus,
/* For secondary admin/profile/etc menus. */
#adm_submenus .linklevel1:hover, #adm_submenus .linklevel1:focus {
background: #fcfcfc;
background-image: linear-gradient(to bottom, #fcfcfc 0%, #e5e5e5 100%); /* W3C */
color: #555;
border: 1px solid #afafaf;
border-top: 1px solid #bbb;
text-decoration: none;
}
/* Main menu Level 1 active button and hover need a different border. */
#main_menu .active, #main_menu .linklevel1:hover, #main_menu .listlevel:hover .linklevel1, #main_menu .linklevel1:focus {
border: 1px solid #38642d;
}
/* Level 1 active buttons for primary admin/profile/etc drop menus... */
.admin_menu .active,
/* ......and for secondary admin/profile/etc menu strip. */
#adm_submenus .active {
background: #4b863c;
background-image: linear-gradient(to bottom, #5BA048 0%, #3d6e32 100%); /* W3C */
color: #fff;
border: 1px solid #38642d;
}
/* Hover effects for those buttons. */
.admin_menu .active:hover, .admin_menu .listlevel1:hover .active, #adm_submenus .active:hover {
background: #437837;
color: #fff;
box-shadow: 1px 1px 1px rgba(0,0,0,0.3) inset;
border: 1px solid #5aa049;
border-left: 1px solid #2d5024;
border-top: 1px solid #2d5024;
}
/* Level 1 active buttons get a bit more weight. */
.active {
font-weight: 600;
}
/* Top level subsection indicators. */
/* Comment these out if you don't want them. */
#main_menu .subsections .linklevel1, .admin_menu .subsections .linklevel1 {
padding: 0 0.8em 0 0.5em;
}
#main_menu .subsections .linklevel1:after,.admin_menu .subsections .linklevel1:after {
content:" \2193";
position: absolute;
top: 0.5em;
right: 0.3em;
font-size: 1.3em;
}
/* Levels 2 and 3: drop menu wrapper. */
.menulevel2, .menulevel3 {
background: #fff;
border: 1px solid #aaa;
border-radius: 4px;
box-shadow: 3px 3px 3px rgba(0,0,0,0.3);
}
/* Levels 2 and 3 drop menus: link or button. */
.linklevel2, .linklevel3 {
color: #555;
/* Applying a default transparent border stops links jumping on hover. */
border: 1px solid transparent;
border-radius: 3px;
}
/* Admin menu icons. */
.linklevel2>img {
vertical-align: middle;
margin: 0 0 0 -4px;
}
/* Levels 2 and 3: hover effects. */
.listlevel2:hover .linklevel2, /* linklevel2 highlighted with cursor over level 3. */
.linklevel2:hover, .linklevel2:focus, .linklevel2.sfhover:focus,
.linklevel3:hover, .linklevel3:focus, .linklevel3.sfhover:focus {
background: #fcfcfc;
background-image: linear-gradient(to bottom, #fcfcfc 0%, #e5e5e5 100%); /* W3C */
color: #555;
border: 1px solid #afafaf;
border-top: 1px solid #bbb;
text-decoration: none;
}
/* Level 2: subsection indicators. */
.listlevel2.subsections .linklevel2:after {
content: "\2192";
position: absolute;
right: 6px;
font-size: 1.3em;
color: #777;
}
/* Levels 2 and 3: highlighting of current section */
/* @todo - This should probably be applied to main menu as well, just for consistency. */
.linklevel2.chosen, .linklevel3.chosen {
font-weight: 600;
}
/* Styles for sidebar menus.
------------------------------------------------------- */
/* Same styling for Level 1 and Level 2. */
#menu_sidebar .linklevel1, #menu_sidebar .linklevel2 {
color: #555;
border: 1px solid transparent;
}
#menu_sidebar .linklevel1:hover, #menu_sidebar .linklevel1:focus, #menu_current_area .linklevel1,
#menu_sidebar .linklevel2:hover, #menu_sidebar .linklevel2:focus {
background: #fcfcfc;
background-image: linear-gradient(to bottom, #fcfcfc 0%, #e5e5e5 100%); /* W3C */
color: #555;
border: 1px solid #afafaf;
border-top: 1px solid #bbb;
border-radius: 3px;
text-decoration: none;
}
#menu_current_area .linklevel1 {
font-weight: 600;
}
/* Level 1: subsection indicators. */
#menu_sidebar .listlevel1.subsections .linklevel1:after {
content: "\2192";
position: absolute;
right: 6px;
}
/*End sidebar flyout coding. */
_basic.css (teh boilerplate version)
/* This variant is a very basic, boilerplate version of the default theme. */
/* It is intended primarily as a "clean slate" for custom theming. */
/* This variant uses named colours instead of hex codes, to make things easier for beginners. */
/* A complete list of CSS colour names can be found at http://www.w3schools.com/cssref/css_colornames.asp */
/* ----------------------------------------------------------- */
/* This is eye candy only. All the layout code is in index.css. */
/* NOTE: The layout code in index.css should NOT be altered
/* unless you are really sure of what you are doing.
/* ALL variants depend on the basic layout code for stability. */
/* ----------------------------------------------------------- */
/* Styles for the standard dropdown menus.
----------------------------------------------------------- */
/* Visible menu bar: wrapper/background. */
#main_menu {
background: forestgreen;
}
/* Needed for new PM notifications. */
.listlevel1 strong {
color: white;
}
/* Level 1 Menu bar: link or button. */
/* If there will be a border on hover, have a border here. */
/* A default transparent border stops links jumping on hover. */
#main_menu .linklevel1, .admin_menu .linklevel1, #adm_submenus .linklevel1 {
border: 1px solid transparent;
color: white;
}
/* Override link colour for admin/profile/etc menus. */
.admin_menu .linklevel1, #adm_submenus .linklevel1 {
color: black;
}
/* Level 1 button hover and focus effects. */
#main_menu .active, /* Level 1 active button shares same styling. */
#main_menu .linklevel1:hover, #main_menu .listlevel:hover .linklevel1, #main_menu .linklevel1:focus,
/* For primary admin/profile/etc drop menus. */
.admin_menu .linklevel1:hover, .admin_menu .linklevel1:focus,
/* For secondary admin/profile/etc menus. */
#adm_submenus .linklevel1:hover, #adm_submenus .linklevel1:focus {
background: gainsboro /* This is a pale grey. */;
color: black;
border: 1px solid darkgray;
text-decoration: none;
}
/* Main menu Level 1 active button and hover need a different border. */
#main_menu .active, #main_menu .linklevel1:hover, #main_menu .listlevel:hover .linklevel1, #main_menu .linklevel1:focus {
border: 1px solid black;
}
/* Level 1 active buttons for primary admin/profile/etc drop menus... */
.admin_menu .active,
/* ......and for secondary admin/profile/etc menu strip. */
#adm_submenus .active {
background: forestgreen;
color: white;
border: 1px solid black;
}
/* Hover effects for those buttons. */
.admin_menu .active:hover, .admin_menu .listlevel1:hover .active, #adm_submenus .active:hover {
background: darkgreen;
color: white;
border: 1px solid black;
}
/* Level 1 active buttons get a bit more weight. */
.active {
font-weight: bold;
}
/* Top level subsection indicators. */
/* Comment these out if you don't want them. */
#main_menu .subsections .linklevel1, .admin_menu .subsections .linklevel1 {
padding: 0 0.8em 0 0.5em;
}
#main_menu .subsections .linklevel1:after,.admin_menu .subsections .linklevel1:after {
content:" \2193";
position: absolute;
top: 0.5em;
right: 0.3em;
font-size: 1.3em;
}
/* Levels 2 and 3: drop menu wrapper. */
.menulevel2, .menulevel3 {
background: white;
border: 1px solid darkgray;
}
/* Levels 2 and 3 drop menus: link or button. */
.linklevel2, .linklevel3 {
color: black;
/* Applying a default transparent border stops links jumping on hover. */
border: 1px solid transparent;
}
/* Admin menu icons. */
.linklevel2>img {
vertical-align: middle;
margin: 0 0 0 -4px;
}
/* Levels 2 and 3: hover effects. */
.listlevel2:hover .linklevel2, /* < highlighted with cursor over level 3. */
.linklevel2:hover, .linklevel2:focus, .linklevel2.sfhover:focus,
.linklevel3:hover, .linklevel3:focus, .linklevel3.sfhover:focus {
background: gainsboro;
color: black;
border: 1px solid darkgray;
text-decoration: none;
}
/* Level 2: subsection indicators. */
.listlevel2.subsections .linklevel2:after {
content: "\2192";
position: absolute;
right: 6px;
font-size: 1.3em;
color: black;
}
/* Levels 2 and 3: highlighting of current section */
.linklevel2.chosen, .linklevel3.chosen {
font-weight: bold;
}
/* Styles for sidebar menus.
------------------------------------------------------- */
/* Same styling for Level 1 and Level 2. */
#menu_sidebar .linklevel1, #menu_sidebar .linklevel2 {
color: black;
border: 1px solid transparent;
}
#menu_sidebar .linklevel1:hover, #menu_sidebar .linklevel1:focus, #menu_current_area .linklevel1,
#menu_sidebar .linklevel2:hover, #menu_sidebar .linklevel2:focus {
background: gainsboro;
color: black;
border: 1px solid darkgray;
text-decoration: none;
}
#menu_current_area .linklevel1 {
font-weight: bold;
}
/* Level 1: subsection indicators. */
#menu_sidebar .listlevel1.subsections .linklevel1:after {
content: "\2192";
position: absolute;
right: 6px;
}
/*End sidebar flyout coding. */
Given the complexity of multi-level drop menu coding, and taking into account the choice between drops or sidebar, I think this is close to as simple as we can make it.
And, on the subject of simplicity, I've started rearranging the contents of index.css to get all related stuff in one place. I'm over finding things declared more than once in hidden corners. Way to drive people mental when they're trying to fix something. Drives me mental anyway. :P
Anyway, I found all of this:
/* a descriptive style */
.description, .information, .plainbox {
padding: 6px 12px;
font-size: 0.9em;
border: 1px solid #ccc;
border-top: none;
border-radius: 0 0 3px 3px;
background: none;
margin: -1px 0 12px 0;
-moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box;
}
/* a simple full surrounding box */ /* @todo - How many types of silly plain boxes do we need? */
.simplebox {
padding: .5em 1em;
font-size: 0.9em;
border: 1px solid #ccc;
border-radius: 3px;
background: none;
margin: .5em 0 1em 0;
-moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box;
}
/* an informative style */
.information {
background: #f0f6f0;
margin: 2px 1px 12px 1px;
}
.information p {
padding: 12px;
margin: 0;
}
.para2 {
padding: 12px 0 44px 0;
margin: 0;
}
/* Styles for info boxes
------------------------------------------------- */
/* @todo - ZOMFG. More silly plain box styles. */
.noticebox {
color: #555;
/* @todo - Change background image for simple sprite combined with quickbuttons? */
background: #fff6ca url(../images/profile/warning_moderate.png) 10px 50% no-repeat;
text-align: left;
border-top: 1px solid #ffd324;
border-bottom: 1px solid #ffd324;
padding: 7px 10px 7px 35px;
margin-bottom: 12px;
}
.infobox {
color: #555;
/* @todo - Change background image for simple sprite combined with quickbuttons? */
background: #efe url(../images/icons/field_valid.png) 10px 50% no-repeat;
text-align: left;
border-top: 1px solid green;
border-bottom: 1px solid green;
padding: 7px 10px 7px 35px;
margin-bottom: 12px;
}
.descbox {
text-align: left;
padding: 7px 10px 7px 35px;
border: 1px solid #c5c5c5;
border-radius: 7px;
margin: 6px 0;
}
So in SMF 2.0.x there were the first three: .description, .information and .plainbox. Now it seems we have seven (!?!?!?!) classes of basic rectangular boxes with little borders around them. Methinks this is getting into seven deadly sins territory. I doubt we really need more than two such classes.
/me goes to sharpen his axe again. Teh axe is getting a real workout. ;D
ETA: HA! Did some searching.
/* @todo - .plainbox is only called on Line 939 of Display.template.php - kill it!
/
/ @todo - .simplebox is only called on Line 554 of ManageBoards.template.php, and on Lines 512 and 1066 of ManagePermissions.template.php - kill it!
/
/ @todo - Only two of .descbox, on Lines 586 and 1604 of Packages.template.php - kill this too! */
So that will easily knock it back to four classes.
Oh, it's good to see how it's shaping up! Something like this, give or take what's where, is a nice way to offer a basics, simple, css, up for us other mortals to customize. ;)
ETA: I guess after the upcoming PR, we should add '_basic' to the files to copy, when making a copy of the default theme in admin (dunno if the others too, but _basic will be needed for a copy, people make it likely to start customizing a bit and/or to test something).
Yeah having that copied would make a lot of sense. We should also document the process for adding extra variants to a theme. Something like:
1/ Edit index.template.php to add names for new ones.
2/ Edit language strings in /languages/Themes.*******.php.
3/ Copy a variant image folder and name the copy to suit.
Which is pretty easy, as long as they know. :)
IMHO installing (or uninstalling) variants should be possible via Packman and without file edits at all...
instead of theme_settings in index.template.php and a language string we should move it to the database.. Variant names IMO don't need a translated name, so a simple table structure (maybe elkarte_themes or a new one) would be enough.
We'd need the id_theme, (id_variant), the short variant name and a descriptive name.
Well the best way would be to copy an images folder and a stylesheet and rename those too. Otherwise I can see db storage being problematic, because there would be no obvious record in the files of what was installed. Themers do not like stuff being hidden, y'know. ;)
yep, agreed.
another idea: How about adding a new folder named "variants" where you can simply place your own variant folder...
/themes/default/variants/thorstensgreen/.. with sub-folders for css and images.
Basic variant infos (name, author, description) could be placed in a variant.xml (similar to package-info.xml)
/themes/default/variants/thorstensgreen/variant.xml
/themes/default/variants/thorstensgreen/css/index.css
/themes/default/variants/thorstensgreen/images/on.png
..
How do you generate the variant.xml? Manually? Isn't that as much trouble as doing it the way it's done now.?
Thought: the problem with file edits is not that they're file edits. It's that they can break stuff. If file edits didn't break stuff, nobody would care about hooks.
How likely is it that the edits required to add a variant to a theme will break stuff? My guess, about as likely as the server going feet up. All you have to do is add a language string to Themes/****.php, which is a simple search/add at the end of the file, or search/delete if removing.
Ditto for the list of variants in index.template.php. You just have to add your variant name last in the list, and it gets deleted if you uninstall. Files and folders? Easy. Point is that this is one example where I honestly don't see any need to panic about using file edits. Anything can break stuff occasionally. Hooks can be a PITA occasionally too.
Cool! Sure thing, commenting it better is quite necessary IMHO. Every of those ideas sounds great to me. Can only help a bit.
Bonzer. :) The old SMF way was to keep comments minimal. It was hard to get them to keep any comments, apart from the most basic, but then they didn't have auto minifying back then. We can afford to be more luxurious now. I like it. :)
Also, I'm going to start ordering stuff according to this bloke's system: http://csscomb.com/
I've looked through it, and his way is pretty much how I prefer to do it anyway. The differences are few and logical, so I think just adopting CSSComb's default ordering is sensible. This will help when reading long declarations, since it's easier to find a margin or whatever if it's consistently in the same place.
I've tried the online resort tool with the current local host version of index.css. Resorting is quite fast and seems to be very good. The only thing it seems to have trouble with is comments in odd places. This is fine:
.some_class {
/* Comment here. */
margin: 0;
padding: 0;
background: #555;
}This will break sorting:
.some_class { /* Oh hai, I stuck temporary comment here during devz! */
margin: 0;
padding: 0;
background: #555;
}So, as long as I (and anyone else) uses a neater commenting style even for temp stuff, CSScomb should be fine.
Obviously, it'd still make sense to test the resorted file before committing anything.