Cant you just have one mega CSS Sprite?

[digitalpoint]

Poor legacy support = not an option for many.

The nice thing is you can leave image based CSS definitions which will automatically be used by the browsers that don't understand CSS gradients (Internet Explorer basically).

 

[Erik]

The nice thing is you can leave image based CSS definitions which will automatically be used by the browsers that don't understand CSS gradients (Internet Explorer basically).

That's nice - I haven't really messed around with CSS3 gradients as thorough support has only recently evolved. Eventually I would like to see a whole colorspace system built into XenForo so I could do something like this:

.myButton {
background: {xen:linear-gradient '{H:@primaryHue, S:0, V:250} -> {H:@primaryHue, S:10, V:230}'}
}
 
.someOtherElement {
border-color: {xen:color '{H:@primaryHue, S:45, V:145}'}
}

Where you can define a linear-gradient completely dynamically, as well as basic colors. In this case the entire theme could be dynamically colored just by changing the value of the style property @primaryHue. And if it's possible to make @primaryHue a user-preference-defined style property, users could make the theme of your site any color they want just by dragging a slider or selecting a hue value in their personal control panel. The possibilities are limitless, really.

I've already sort of accomplished this functionality by using transparent gradients throughout my Flexile theme and then defining the background color as a style-property-defined hex color. Board owners can then make the color of the theme any color they want by dragging the hue slider in the control panel, which changes the hues of all the colors in that style property group. Full functionality like this would be amazing though.

Who knows, maybe I'll take this up as my summer project and create a mod if this functionality doesn't look like it's going to be implemented.

 

[Astrum]

Talk about reinventing the wheel. Perhaps XenForo should support SASS/SCSS (and Haml and CoffeeScript) through an asset pipeline.

 

[Erik]

Talk about reinventing the wheel. Perhaps XenForo should support SASS/SCSS (and Haml and CoffeeScript) through an asset pipeline.

Or this. Only thing is it would be rather expensive to compile the whole thing at runtime, and I don't really think any of the other features are needed, seeing as we already have variables with style properties.

 

[Astrum]

It doesn't need to be compiled when served, it could conceivably be compiled and minified after alterations just like it is now with the XenForo template syntax, much like the Ruby on Rails asset pipeline. I don't particularly care about Haml (although it would work), but CoffeeScript and SASS/SCSS would be nice to have support for. The reason SASS/SCSS would be nice is for mixin support, and CoffeeScript would be nice just because JavaScript has so many rough edges .

 

[Erik]

It doesn't need to be compiled when served, it could conceivably be compiled and minified after alterations just like it is now with the XenForo template syntax, much like the Ruby on Rails asset pipeline. I don't particularly care about Haml (although it would work), but CoffeeScript and SASS/SCSS would be nice to have support for. The reason SASS/SCSS would be nice is for mixin support, and CoffeeScript would be nice just because JavaScript has so many rough edges .

Sorry, but I absolutely hate the idea of mixins. I can't imagine the nightmare of having follow a trail of mixins to get to the actual CSS that you're looking for. CSS doesn't need to be that complicated in my opinion.

Whereas you can do everything you want without mixins (just with a little bit more work), it is impossible to do some stuff without variables and color functions.

Regardless of SCSS/no SCSS, one feature I would really like to see get implemented is the ability to designate any style property as user-controlled. This style property would be left as a variable to be used at runtime and not compiled in like all the other style properties, and would then show up in a forum user's control panel under a "style options" page. This would allow the user to change font face, size, background color, background images, etc. to their desire. While it has the ability to be misused, it opens up a lot of possibilities that currently have to be either hacked in through the use of JavaScript and cookies, or fulfilled by mods.

 

[DRE]

Size... as I have always told my girlfriend, is not as important as you 1st may think

Edit: skip to lower part if you dont want to read my brain splat
---------------------------------------------------------------------------------------------
Once you have the image, you have the image cached (unless you are in a no-cache environment), the biggest issue with large sprites is the huge amount of memory and bloat you add to the browser.

Having huge sprites and only displaying a small pixel in part of the background several times causes the browser to feel very laggly and bloated, that's why as much white space as possible should be removed from sprites (the data saving you gain from removing the white space from sprites is insignificant)

However, downloading even the tinest of images can sometimes take ages... some times it's just as fast to download a 1byte jpg as it is to download a 16kb jpg (keep in mind bytes are sent in packets, 1.4kB I believe?)

Most of the time is spent trying to get to the image:

* looking up DNS info,
* performing security handshakes,
* connecting to the server..
* waiting for responses..
* and then finaly downloading/trasfering the data

Actually downloading the data is often an insignificant fraction, so size is not that important, that's why as few http request should be done as possible (but still allowing for parallel requests) optimising the size of the image is no where near as important as spriting and keeping the number of request to an optimal number (but it's still worth optimising the images to some degree... but think packets, not size)

Images/ any http request will be downloaded in parallel (so it's almost shooting your self in the foot, even for performance, having one large sprite). Differenet browsers will have a different limits for the number of http request that they can do in parallel

Often people don't realise they also send header information when sending images (cookie information, etc), this can also tip an image over an optimal packet size (so using an external data provider can be useful if it's fast, a CDN could improve things). If the images are serverd from the same server, it's very important to keep your eye on header information that might build up (don't store user history in cookies, that's what a database can be used for!)

---------------------------------------------------------------------------------------------

Edit... there's way too much gumph up there, and I feel like I had only just started my brain dump, read here instead (I'm procrastinating):
.. Huge sprites = a no-no
* bloats browsers
* doesn't help spilt up requests for parallel downloading
.. sprites = good, huge sprite = bad

Hmmm. K say you have 500 smilies and you separate them into 5 different sprite-sheets. Is that better than having 1 sprite-sheet for 100 images and the 400 that are left are individual images instead of 4 other sprite-sheets for the remainding images?