I noticed that only some ExtJS components/widgets use CSS sprites for the images and icons. But was wondering why hasn't this been implemented universally across all widgets and components.
The icons in the Tree component, for example, doesn't use sprites.
In IE6, where the browser only allows for up to 4 concurrent outbound connections per-domain, it takes a bit of time to download all the Tree icons (i.e. the folder and elbow icons). Implementing this using CSS Sprites would make loading quicker in this case.
I could easily implement this on my own using my own css file to override the default ExtJS css rules, however I would rather avoid this so that I don't have to keep on updating with each release (should the icons change).
My questions for the ExtJS dev team are:
Are there any technical limitations or things to be aware of when implementing CSS Sprites for components such as the Tree?
Will we see universal implementation of CSS Sprites across all/most ExtJS components in the future?
I think the goal is to migrate to more of a sprite-based system. I'm tryiing to stir up discussions (Sent an internal email) to get the process of "normalizing" things in the framework going for at least 4.0 if possible.
Performance is perhaps the most important thing to us when it comes to ExtJS improvements.
In IE6, for example, you could literally see the images get painted as they come across the net. I first see the background shadow and then slowly the foreground images tile by tile. It's not pretty. CSS Sprites would go a long way in improving this.
It's not much of an issue in non-IE6 browsers (as they allow for a greater number of concurrent connections), but IE6 support for us is crucial. Our customers -- mega pharmaceutical companies -- still live on IE6.
I sincerely hope support for CSS Sprites is added 3.3, but I know it may be wishful thinking.
I've just finished of a big stock control system for a client of mine (over 150000 lines of js code). I normally leave all the optimisations to the end, namely combining all js files and minimising them, similarily for css files, creating a custom extjs build utilising only called components etc. Once these steps are taken, a large extjs project really flies. The biggest bottleneck I'm noticing at the moment is however the loading of all the images to build the UI.
Whilst I agree that the ongoing javascript code optimisations help (and well done to the team for them all), I believe at this juncture in ExtJS's development that the greatest benefit would be derived through the use of sprite optimisations for UI components.
I could easily implement this on my own using my own css file to override the default ExtJS css rules, however I would rather avoid this so that I don't have to keep on updating with each release (should the icons change).
My questions for the ExtJS dev team are:
Are there any technical limitations or things to be aware of when implementing CSS Sprites for components such as the Tree?
Will we see universal implementation of CSS Sprites across all/most ExtJS components in the future?
Your top statement pretty much summed up why it hasn't been done. It is a management nightmare. I don't think there are any technical limitations just more of a time limitation.
Eric Berens
Intranet Systems Manager @ Best Buy
You should follow me on twitter here.
@danigoldman: I am happy You brought this topic up! So far the arguments for using css sprites have been about the browser and e.g. the amount of connections the browser can handle per domain.
But there is also (sometimes) another reason for limiting the amount of connections from the server. In resource limited environments such as an embedded environment you might need to limit the amount of open connections as a way to share available resources on the device hosting the web server and other services.
It would be great if a tool existed that could:
1. Browse through all css files searching for png's and jpeg's.
2. Catch the individual images, sort them so the biggest is picked first and placed at the start (0,0) and that the combined image is ending up to be somewhat square in dimensions and saved preferably in png (but users might have different opinions on that.)
3. The resulting css file(s) are referring to the sprite.
, meaning - the user should NOT care about maintaining some css sprites but use a utility for that. Meaning user art work could be easily combined with that of ExtJS. It would be great if jsbuilder ( extjs.com/products/jsbuilder/ ) could be that utility!
Regarding gifs - I would rather choose to not mix those into a sprite.
There might be images that the user would like to choose not to get into a css sprite - e.g. an image from a web cam, an ever changing advertisement, a very large image (and perhaps rarely used) or something else. Here it might be possible to add a simple css selector to where the image is mentioned in the css file either by naming scheme x-no-sprite-my-huge-panel-image or something else that is simple and clean.
At csssprites.org they use annotations - I think the solution should be something where the user does not need to care about that so that it is simpler for the user to use. Rather have some general improvements to the utility to make general better optimizations than changing the original css files by hand to give instructions to the utility.
, here they use another approach which I have not seen before so it is both possible to use 1) one file for all images and 2) base64 encoding so it even works in IE 6+: http://cappuccino.org/discuss/2009/1...appuccino-0-8/
They use MHTML for IE6+ to support base64 encoding - pretty smart! However I wonder what the size difference is for say 1,2 or 3 large sprites of either png or jpeg format compared to base64 encoding+gzip of the common file containing everything - but anyway e.g. for embedded usage: Having one file to download would be just great!
The great thing is of course then there is no need to analyse how each image is dimensioned regarding making a "sprite", but you may still want to exclude some images referenced by css-files.
This should also allow gif-support without hassle.
However I wonder about what kind of support Microsoft have put into MHTML regarding base64 encoding. In IE 8 there is support for data URI, but according to http://en.wikipedia.org/wiki/Data_UR...#Disadvantages and http://msdn.microsoft.com/en-us/libr...97(VS.85).aspx it is specified that there are only 32 kilo bytes available.
MHTML is explained here: http://en.wikipedia.org/wiki/MHTML
, especially in the links on that wiki page. However I "guess" mhtml does not have this 32 kb limit, since it can be used for flash files, java etc. - which is kind of neat.
As well as combining CSS, gzipping and using sprites we also spread ExtJS and other core assets across multiple domains for parallel loading as described here:
Not all Ext components use CSS Sprites - why?
Originally Posted by danigoldman
Reply With Quote
