Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 0.2.4
-
Component/s: None
Activity
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 0.2 [ 10053 ] | |
| Fix Version/s | 0.1.1 [ 10080 ] |
| Fix Version/s | 0.2 [ 10053 ] | |
| Fix Version/s | 0.3 [ 10090 ] |
| Original Estimate | 4h [ 14400 ] | |
| Remaining Estimate | 4h [ 14400 ] | |
| Description | If an image has more than one reference in the original CSS, it will be also included multiple times in the sprite image. Ideally, if one individual image is added many times to one sprite image, it should appear in it only once. |
h3. Motivation Currently, if an image has more than one reference in the original CSS, SmartSprites will include it multiple times in the sprite image. Ideally, if one individual image is added many times to one sprite image, it should appear in it only once. h3. Discussion The reason I've not stumbled upon this limitation in my previous SmartSprites-based designs is that I'd usually remove the duplication on the CSS code level, i.e. collapse many rules that used the same image like this: {code} div#id1, div.logo, ul > li > div.x { background-image: url("../img/logo.png"); /** sprite-ref: sprite */ } {code} Until this duplicate removal is implemented, the above should work as a workaround. |
| Priority | Minor [ 4 ] | Major [ 3 ] |
| Fix Version/s | 0.2.4 [ 10135 ] | |
| Fix Version/s | 0.3.0 [ 10090 ] |
| Description |
h3. Motivation Currently, if an image has more than one reference in the original CSS, SmartSprites will include it multiple times in the sprite image. Ideally, if one individual image is added many times to one sprite image, it should appear in it only once. h3. Discussion The reason I've not stumbled upon this limitation in my previous SmartSprites-based designs is that I'd usually remove the duplication on the CSS code level, i.e. collapse many rules that used the same image like this: {code} div#id1, div.logo, ul > li > div.x { background-image: url("../img/logo.png"); /** sprite-ref: sprite */ } {code} Until this duplicate removal is implemented, the above should work as a workaround. |
h3. Motivation Currently, if an image has more than one reference in the original CSS, SmartSprites will include it multiple times in the sprite image. Ideally, if one individual image is added many times to one sprite image, it should appear in it only once. h3. Implementation Within each sprite image, there should be exactly one individual image per one sprite reference. Equal sprite references collected across different locations in a CSS file or different CSS files should point to the same sprite and individual image within the sprite. Sprite references should be considered equal if all of their properties are equal. Currently, this includes {{sprite-ref}}, {{sprite-alignment}} and {{sprite-margin-*}}. In the future, the newly added properties that affect the way the image is rendered within the sprite, such as {{sprite-width}} and {{sprite-height}}, should also be considered during equality testing. h3. Discussion The reason I've not stumbled upon this limitation in my previous SmartSprites-based designs is that I'd usually remove the duplication on the CSS code level, i.e. collapse many rules that used the same image like this: {code} div#id1, div.logo, ul > li > div.x { background-image: url("../img/logo.png"); /** sprite-ref: sprite */ } {code} Until this duplicate removal is implemented, the above should work as a workaround. |
| Original Estimate | 4h [ 14400 ] | 6h [ 21600 ] |
| Description |
h3. Motivation Currently, if an image has more than one reference in the original CSS, SmartSprites will include it multiple times in the sprite image. Ideally, if one individual image is added many times to one sprite image, it should appear in it only once. h3. Implementation Within each sprite image, there should be exactly one individual image per one sprite reference. Equal sprite references collected across different locations in a CSS file or different CSS files should point to the same sprite and individual image within the sprite. Sprite references should be considered equal if all of their properties are equal. Currently, this includes {{sprite-ref}}, {{sprite-alignment}} and {{sprite-margin-*}}. In the future, the newly added properties that affect the way the image is rendered within the sprite, such as {{sprite-width}} and {{sprite-height}}, should also be considered during equality testing. h3. Discussion The reason I've not stumbled upon this limitation in my previous SmartSprites-based designs is that I'd usually remove the duplication on the CSS code level, i.e. collapse many rules that used the same image like this: {code} div#id1, div.logo, ul > li > div.x { background-image: url("../img/logo.png"); /** sprite-ref: sprite */ } {code} Until this duplicate removal is implemented, the above should work as a workaround. |
h3. Motivation Currently, if an image has more than one reference in the original CSS, SmartSprites will include it multiple times in the sprite image. Ideally, if one individual image is added many times to one sprite image, it should appear in it only once. h3. Implementation Within each sprite image, there should be exactly one individual image per one sprite reference. Equal sprite references collected across different locations in a CSS file or different CSS files should point to the same sprite and individual image within the sprite. Sprite references should be considered equal if they refer to the same sprite (equal {{sprite-ref}}) and have equal bitmap renderings. In particular, equal bitmaps will be produced for equal {{sprite-alignment}} and {{sprite-margin-*}} properties, but when further sprite reference properties are added, the same rendering may be achieved by different sets of properties. h3. Discussion The reason I've not stumbled upon this limitation in my previous SmartSprites-based designs is that I'd usually remove the duplication on the CSS code level, i.e. collapse many rules that used the same image like this: {code} div#id1, div.logo, ul > li > div.x { background-image: url("../img/logo.png"); /** sprite-ref: sprite */ } {code} Until this duplicate removal is implemented, the above should work as a workaround. |
| Remaining Estimate | 4h [ 14400 ] | 6h [ 21600 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Attachment | smartsprites.zip [ 10161 ] |
-
- Time Worked:
- 6h 5m
- Implementation, refactoring, unit tests.
| Time Spent | 6h 5m [ 21900 ] |
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 3 ] | Resolved [ 5 ] |
| Remaining Estimate | 6h [ 21600 ] | 0h [ 0 ] |
Hide
That sounds like a great idea and it will save a lot of unnecessary processing. Great 
Show
Kanu Dialani added a comment - 05/Sep/09 09:25 PM That sounds like a great idea and it will save a lot of unnecessary processing. Great
| Status | Resolved [ 5 ] | Closed [ 6 ] |
| Resolution | Fixed [ 1 ] | |
| Status | Closed [ 6 ] | Reopened [ 4 ] |
| Status | Reopened [ 4 ] | Closed [ 6 ] |
| Resolution | Fixed [ 1 ] |
I just thought i'd raise why this is still a very valid and important feature request.
The problem here arises because for organisational purposes on large or multi-part sites such as ours, we have separated files for different application components... such as our movie news and our tv guides sections of the site.
These are kept in separate files for easy compartmental workflow of the team as well as reducing file size of all css when minified on the fly by the server. If image references are shared between css files (h3 or h4 decorations, gradients, etc) because of common styling, then the above way of writing code isn't applicable, because of the split files.
eg:
Movies css:
.movies-header { background-image: url("../img/deco.png"); /** sprite-ref: sprite */ }
TV css:
.tv-header { background-image: url("../img/deco.png"); /** sprite-ref: sprite */ }
An inconvenient work around could be forced with an additional css file which overrides selectors with the applicable background image of all the separate css files and defines all the backgrounds there. Like "backgrounds-all-over-the-site.css". This is however, highly impractical and a nightmare to manage!