Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.2.4
    • Labels:
      None

      Description

      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.

      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.

      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:

      div#id1,
      div.logo,
      ul > li > div.x {
        background-image: url("../img/logo.png"); /** sprite-ref: sprite */
      }
      

      Until this duplicate removal is implemented, the above should work as a workaround.

        Activity

        Hide
        Kevin Vanderbeken added a comment -

        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!

        Show
        Kevin Vanderbeken added a comment - 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!
        Hide
        Stanisław Osiński added a comment -

        Hi Kevin,

        The same point has been made on the discussion group, moving to 0.2.4 release and increasing priority.

        S.

        Show
        Stanisław Osiński added a comment - Hi Kevin, The same point has been made on the discussion group, moving to 0.2.4 release and increasing priority. S.
        Hide
        Stanisław Osiński added a comment -

        Implemented in trunk, binaries available from:

        http://download.csssprites.org/smartsprites-0.2.4-dev.zip

        Show
        Stanisław Osiński added a comment - Implemented in trunk, binaries available from: http://download.csssprites.org/smartsprites-0.2.4-dev.zip
        Hide
        Stanisław Osiński added a comment -

        Hi Kanu,

        Just for your reference, I implemented the duplicate removal in a slightly different way than suggested in your patch. Instead of comparing individual image paths, I'm comparing the bitmaps individual sprite references produce. This way, even if the same image has two different file names, it will be included in the sprite only once. More importantly, this method correctly takes into account the individual image's margins and other properties I'll be introducing e.g. in: SMARTSPRITES-39. Therefore, beware with your original version: if you have two references to the same image differing only by margins (sprite-margin-*), these will be incorrectly linked to the same image within sprite, though in fact they should produce two different images within the sprite.

        S.

        Show
        Stanisław Osiński added a comment - Hi Kanu, Just for your reference, I implemented the duplicate removal in a slightly different way than suggested in your patch. Instead of comparing individual image paths, I'm comparing the bitmaps individual sprite references produce. This way, even if the same image has two different file names, it will be included in the sprite only once. More importantly, this method correctly takes into account the individual image's margins and other properties I'll be introducing e.g. in: SMARTSPRITES-39 . Therefore, beware with your original version: if you have two references to the same image differing only by margins (sprite-margin-*), these will be incorrectly linked to the same image within sprite, though in fact they should produce two different images within the sprite. S.
        Hide
        Stanisław Osiński added a comment -

        Hi Kanu,

        1) removes duplicate images. creates background-position with the same co-ordinates for same images
        2) added parameter to copy non annotated CSS files.
        3) added parameter to process/ignore smartsprite annotations.

        I've implemented point 1) in a slightly different way, but I have a question about the use case for 2) and 3). I'm assuming that you're using a combination of these two options (copy non-annotated CSS files + ignore annotations) to simply copy your design files from the source location to the output dir? If so, maybe a simple Ant copy task, possibly with some mappers (http://ant.apache.org/manual/CoreTypes/mapper.html) would do instead?

        Thanks,

        S.

        Show
        Stanisław Osiński added a comment - Hi Kanu, 1) removes duplicate images. creates background-position with the same co-ordinates for same images 2) added parameter to copy non annotated CSS files. 3) added parameter to process/ignore smartsprite annotations. I've implemented point 1) in a slightly different way, but I have a question about the use case for 2) and 3). I'm assuming that you're using a combination of these two options (copy non-annotated CSS files + ignore annotations) to simply copy your design files from the source location to the output dir? If so, maybe a simple Ant copy task, possibly with some mappers ( http://ant.apache.org/manual/CoreTypes/mapper.html ) would do instead? Thanks, S.
        Hide
        Kanu Dialani added a comment -

        That sounds like a great idea and it will save a lot of unnecessary processing. Great

        Show
        Kanu Dialani added a comment - That sounds like a great idea and it will save a lot of unnecessary processing. Great
        Hide
        Stanisław Osiński added a comment -

        Closing for the 0.2.4 release.

        Show
        Stanisław Osiński added a comment - Closing for the 0.2.4 release.
        Hide
        Stanisław Osiński added a comment -

        Reopening to delete a comment.

        Show
        Stanisław Osiński added a comment - Reopening to delete a comment.

          People

          • Assignee:
            Stanisław Osiński
            Reporter:
            Stanisław Osiński
          • Votes:
            5 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 6h Original Estimate - 6h
              6h
              Remaining:
              Remaining Estimate - 0h
              0h
              Logged:
              Time Spent - 6h 5m
              6h 5m

                Development