Active
Project:
Language Icons
Version:
7.x-1.x-dev
Component:
Icon collection
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
17 Mar 2013 at 17:57 UTC
Updated:
15 Apr 2013 at 08:53 UTC
Jump to comment: Most recent
Comments
Comment #1
Freso commentedWhile the two first points are valid, the 3rd one definitely isn't. Far most sites using Language icons (which I have seen), only have a couple (2-3) languages enabled (none use all, I haven't seen any using more than 10). There are around 55 flags in the current collection (which is continuously expanded). Having a sheet containing all the image files thus require you to fetch around 11 times as much data as you need for displaying (using five languages). If you have a site using >40 languages, I can definitely see how fetching a single sheet (even if it has some unused entries) would be preferable to fetching 40 different images, but this is a use case for a very small minority of sites. Without having run tests, I'm fairly sure that for 2-3 language sites, the overhead reduction of the first two do not mitigate the reduced load suggested by the third point.
Not to mention, it'd be much more difficult to maintain a single sheet if you want to also keep the images orderly.
With all that said though: patches are accepted and if I can agree with the approach, I will merge it. It just still needs to be based on single images (a PHP function could join them on a single sheet) and it needs to work without requiring the sheet as well. Won't-fix'ing for now. Feel free to reopen if you have code to submit. :)
(Also, you should update your Language icons to 7.x-1.0 instead of using the old release candidate. Versions prior to 7.x-1.0 contained a security flaw.)
Comment #2
heyyo commentedI think it could be more effective if the icons were a css background instead of a direct image.
Like this a sprite could be generate by anyone as desired for the languages used, and hover state could be used too.
Language icons will gain in performance and in flexibility.
Comment #3
JulienThomas commentedI agree. I created a separated ticket to first handle the CSS background aspect of it, with patch proposal (https://drupal.org/node/2155287). Going into sprite is then next step