Just took a brief look in there since I was responsible for a lot of those.
Question: WTF is this?
background: #fff url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAYAQAAAADb20ChAAAAAnRSTlMAAQGU/a4AAAApSURBVHjaY/zPgIL+MTL+aWb84c74QZ/xgT6yFJALFARKARUAlaFpBACuqxnhHOnncgAAAABJRU5ErkJggg==) 98% 50% no-repeat;
base64 encoded images, saves a lot of http requests ;)
Wonderful. You have just made it impossible for anyone to have a clue what the image is called, where to find it, and what the CSS actually is supposed to mean. I thought the plan was to make theming easier than SMF 2.0.x. Why do you want to make it harder?
Umm, how does this make this
at all user-friendly?!
As a novice admin, this means I don't know where an image is.
As a novice themer, this means I don't understand how to change images.
As a user, I DON'T GIVE A DAMN. Bandwidth is cheap. Even if my internet is metered, I guarantee you that the entirety of a forum's theme images weighs less than some users' signature images.
Please don't make this harder than it has to be.
She talketh sense. Are you trying to write code for a server, or to write code for humans to work with?
If the former, just do everything in machine code and be done with it. It'd be awesome efficient. Popularity may dwindle somewhat, though.
As a forum owner: less bandwidth, less HTTP requests, faster performance
As a novice themer: http://www.elkarte.net/community/index.php?topic=1124.msg7728#msg7728
As a user: bandwidth is IMHO still important, not for my PC @ home (cable TV internet is fast with a flatrate) but for my mobile phone (my rate is 200 mb with HSPA+ per month, traffic over 200mb will be reduced to 64kbit)
Yes yes yes, we understand the theoretical benefits. We're not stupid. However, you are still inflicting incomprehensible default code on people for a benefit which is more theoretical than practical.
Server bandwith is cheap. Have you priced a host lately? They're giving out bandwidth GBs as if it was candy, and that's not even the oversellers.
Are you trying to do this in lieu of letting images be cached?
^ that's a beautiful response to that
This is why mobile themes are important. I don't think bandwidth reduction to desktop themes are as high priority, and when it compromises user friendliness, especially for a new software without any stockpile of themes to use, user-friendliness should be the higher priority.
Just breaking this down a bit:
1/ Images are cached, so bandwidth is not a concern except for first time visitors. Ditto performance (which is fast anyway, for Elk in default form).
2/ Already answered.
3/ Then for your phone you will never want to view any images at all, right? You'll obviously be browsing with all images disabled all the time. Yes? No?
There are more benefits than those listed above:
- One is my example using custom.css (one file fits all, just place it in the themes folder and you're done with restyling)
- Editing sprite maps isn't easier, at least not for me.. ok, adding a single image at the end is easy, but replacing several of them with bigger ones means: funny job in photoshop and changing all the background positioning in CSS.
Converting a PNG to a base64 string is quite simple:, there are lots of online converters available http://webcodertools.com/imagetobase64converter
IMHO it's simple, just needs some guidance for the novice themer.
But one css file will do any minor theme tweaks anyway, so that's nothing to do with this.
Just using the image name is simpler. You are creating an extra hoop to jump through. :P
I still don't get it. Aren't images cached? What is the point of saving bandwidth when it's already saved?
You could just add a comment to tell you what the image is ;)
But that would add a couple more bits to the file ZOMGosh!!! I'm fine with this either way. If someone doesn't know how to use a CSS background or they can't understand how to change a background, they don't belong in the CSS files anyway. Novice user or not, if you are going to alter a theme, you should have a basic understanding on how to use css backgrounds. Besides there's like what? 5 or 6 of these lines...
So obviously they're going to give such a huge advantage that the inconsistency in format will have totally awesome performance benefits.
It's not a case of not knowing how to use a CSS background. I am well aware of how to use CSS backgrounds. The problem, IMO, is that this is a case of a picture being worth a thousand words. The examples are "thousand word code". A picture would be better.
Ok, say you want to change it. The first thing people will do is try to find out what the image is called and where it is. Right click FTW. This will not give them any useful result. Immediate reaction will be "WTF?". This means you will spend a lot of time fielding support questions that are basically variations on "WTF?". This is cool if your aim is to feel alternately exasperated and superior because "n00bz don't get it", but otherwise is a waste of time.
So ok, you say, they can RTFM. Yup, for a few inconsistent lines of CSS they can RTFM after someone can first take the time to document the inconsistency (you have to WTFM first). Then say they RTFM and get the idea and think this is how Elk CSS should be done, so they want to make their changes match.
First thing they'll probably want is a reference image, which they'll have to get for themselves by copying the existing and saving it somewhere. But hang on, that image on the screen: where does it go in the CSS? You sure can't search for image name. This aint n00b-friendly even so far, and it's looking like a nuisance even for experienced coders.
Ok, so you figure out which image it is and where it goes. So you want a different one. What do you do? You do the usual thing: a "funny job in photoshop" as TE called it. You make your new image. Then, instead of just upping that with the same name as the original, you have to go and find a base64 converter and get that code, then you have to edit that code into your CSS file, then you have to up that. Of course, you'll still need to make notes so you can remember what is what. All of this is called "making things easier".
there's exactly one place for that technique in index.css, the styling of the select boxes.
All other's are part of the editor css, mainly to save a buch of http requests.
Let's be a bit more realistic: how often have you seen a custom theme with it's own editor icons (made from a novice themer)?
Ok, so let's be a bit more realistic. Exactly what awesome benefits do you get from doing the select boxes, and only the select boxes, this way in index.css?
This is probably the most intelligent reply so far.
That'd be ok, for the editor buttons, if you comment them all. I still can't see the point of throwing this stuff into index.css though.
Of course, as soon as someone tries to make a dark theme they most likely will want to change all the editor images, for the simple reason that the defaults would be largely illegible on a dark background. Admittedly this is probably not something beginners are likely to attempt, but is something that I and others have done in the past with SMF themes.
Above each data url is a comment like /*background: url('../images/bbc/toggle.png');*/ at least in the BBC. And of course if they are using the combiner, all those comments are removed so they don't take up any extra space.
I did them that way because I was willing to do the work and thats how I chose to do it. At the time I felt the select should render with just css and not need another request to fetch a graphic to complete. Maybe someone will change it in the future, maybe not. Heck I may pull all that out and bury the looks in javascript, that way I can really have my way with them bwa hahahahah
I'm up for selects just using CSS, but don't really see why they needed an image there anyway.
About base64... is there a reason you're not doing it like Wedge? I.e. use your combiner to fetch files inside URL tags and if they're smaller than 3 or 4kb (ie small icons), output them as base64.
Of course it only is useful if the final CSS file is gzipped. Check out Class-CSS.php in Wedge for inspiration. At the very end.
That way, Emelia Tamerin won't be able to complain too much. ;)
And base64 is so much better than sprites! Try to put animated smileys into a sprite... :D
Why the gently caress would you want animated smileys in a sprite? :o
That's the point: you can't. So you can't use a sprite for smiley.
But you can use the base64 trick if you want (AFAIU).
Yes. Look at the Wedge source. If someone uses a smiley somewhere, it adds a CSS file (a few gzipped kb's) with all default smileys, encoded. It really is faster. Especially in the editor.
True that ... Just did that so they looked the same in all the browsers, well mostly the same. It was not the different arrows that was bothersome (to me) but the padding and shadowing that showed up around them. And some were square and some oval etc ... overall selects are just ugly to deal with.
Just never dawned on me to do that !
/me was thinking to do that way (or something like that) the addon to change board icons from the admin panel. O:-)
That would be cool !
Selects are horrible (as are most form elements). Question: how about just using one of the UTF-8 thingies instead of an image? There's stacks of them.
There should be a glyph that would work, some of the better arrows were missing from some of the fonts sets we use, I got caught by that a couple of times. There should be something we could use out of the font-awesome css as well since thats loaded by default, although in this case one of the standard font glyphs would be better.
Y'know personally I wouldn't worry too much about it. Selects can be done pretty well in FF and Chrome with the default droppy indicator. They look neat if they're just given some basic border and background tweaks. Safari* and IE have always been ugly, so :P to them. If anyone uses Safari* or IE they deserve ugly.
Sure, you can convolute the whole thing trying to get them perfect in all browsers, but it it worth it?
*Just checked and Safari looks fine too. It's only IE which is a bit uggers.
Here's a screenshot of some selects and the CSS that runs them. These are just basic selects, with no extra divs or other tricks. The CSS shown is the whole lot. There's nothing else used.
/* Inputs, etc. */
input, textarea, button, select {
font: 100%/150% "Segoe UI", "Helvetica Neue", "Liberation Sans", "Nimbus Sans L", Arial, sans-serif;
color: #444;
}
And:
#userarea select {
margin: 0 2px 0 0;
padding: 0;
width: 8em;
}
#background_select>select {
margin-top: 4px;
}