SmartSprites
  1. SmartSprites
  2. SMARTSPRITES-23

Support of !important in background-image attribute

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 0.2.0
    • Fix Version/s: 0.4.0
    • Labels:
      None

      Description

      I have a lot of background-image definitions which have the !important keyword added in the end like this:

      background-image: url(../js/grid/page-first.gif) !important;

      But currently it's not possible to annotate this with SmartSprite like this:

      background-image: url(../js/grid/page-first.gif) !important; /** sprite-ref: hsprite; */

      I think this is a vital point - unless there's a workaround for this case.

        Issue Links

          Activity

          Hide
          Stanisław Osiński added a comment -

          Good point, Philipp! I can't think of an immediate workaround, but I'll try to fix this ASAP.

          Show
          Stanisław Osiński added a comment - Good point, Philipp! I can't think of an immediate workaround, but I'll try to fix this ASAP.
          Hide
          Stanisław Osiński added a comment -

          Hi again,

          I've put together a quick fix, you can download the updated version from:

          http://smartsprites.osinski.name/download/smartsprites-0.2.1-alpha.zip

          (or you can use the latest trunk from svn)

          One thing that we cannot solve nicely (until I implement SMARTSPRITES-22 you filed) is this: if the original background-image property has an "!important" modifier (just like in your example) – should the generated background-position property also have the "!important" modifier? For now, I assumed that both the generated background-image and background-position would have it, but I'm not sure how that matches your specific case.

          Anyhow, I'm curious about your feedback.

          Show
          Stanisław Osiński added a comment - Hi again, I've put together a quick fix, you can download the updated version from: http://smartsprites.osinski.name/download/smartsprites-0.2.1-alpha.zip (or you can use the latest trunk from svn) One thing that we cannot solve nicely (until I implement SMARTSPRITES-22 you filed) is this: if the original background-image property has an "!important" modifier (just like in your example) – should the generated background-position property also have the "!important" modifier? For now, I assumed that both the generated background-image and background-position would have it, but I'm not sure how that matches your specific case. Anyhow, I'm curious about your feedback.
          Hide
          Philipp Rosenhagen added a comment -

          Nice! I'll try this tomorrow.

          As you already said: until #22 is not implemented there is some gray area on how to manage the !important keyword for the attributes to set.
          At this stage I'm just replacing the existing ones which have "background-image" attributes - and not the ones with the short syntax "background". But even when the "background:" attribute have the !important flag it should be preserved (that's relevant for #22).
          For the current case - yes - your assumption should be right. Because the !important keyword overwrites effectively other definitions (added via css inheritance) - the background-image have to be in the right place - and that's only savely possible if you apply the !important keyword to the background-position attribute as well. Maybe it gets more complicated when there is also a "background-position" attribute in the original css with the keyword !important... which takes precedence? The one defined by the user or the one generated by SmartSprites? In the FAQ you advice that those attributes should be positioned before the SmartSprites-annotated background-image attribute. So I think currently the generated one overwrites the original position. I think that's ok.

          Mmm... what about this case:

          div.foo

          { background-image: url(bar.jpg) !important; /** sprite-ref: hsprite; */ }

          div

          { background-position: -10px 20px; }

          The generated css by SmartSprites would be:

          div.foo

          { background-position: 0px 10px !important; /* example values - depending on the image dimensions */ background-image: url(hsprite.png) !important; }

          div

          { background-position: -10px 20px; }

          The second definition would be overwritten by the !important keyword added by SmartSprites. So maybe this interferes the layout intended by the designer. So I think the FAQ should be extended by this issue. Overwriting styles via inheritance can not be detected by SmartSprites (because the reformating can occur in every style after and outside the currently processing style definition). And this is not just a problem when using the !important keyword. So when using SmartSprites - this fact should always be kept in mind.

          Show
          Philipp Rosenhagen added a comment - Nice! I'll try this tomorrow. As you already said: until #22 is not implemented there is some gray area on how to manage the !important keyword for the attributes to set. At this stage I'm just replacing the existing ones which have "background-image" attributes - and not the ones with the short syntax "background". But even when the "background:" attribute have the !important flag it should be preserved (that's relevant for #22). For the current case - yes - your assumption should be right. Because the !important keyword overwrites effectively other definitions (added via css inheritance) - the background-image have to be in the right place - and that's only savely possible if you apply the !important keyword to the background-position attribute as well. Maybe it gets more complicated when there is also a "background-position" attribute in the original css with the keyword !important... which takes precedence? The one defined by the user or the one generated by SmartSprites? In the FAQ you advice that those attributes should be positioned before the SmartSprites-annotated background-image attribute. So I think currently the generated one overwrites the original position. I think that's ok. Mmm... what about this case: div.foo { background-image: url(bar.jpg) !important; /** sprite-ref: hsprite; */ } div { background-position: -10px 20px; } The generated css by SmartSprites would be: div.foo { background-position: 0px 10px !important; /* example values - depending on the image dimensions */ background-image: url(hsprite.png) !important; } div { background-position: -10px 20px; } The second definition would be overwritten by the !important keyword added by SmartSprites. So maybe this interferes the layout intended by the designer. So I think the FAQ should be extended by this issue. Overwriting styles via inheritance can not be detected by SmartSprites (because the reformating can occur in every style after and outside the currently processing style definition). And this is not just a problem when using the !important keyword. So when using SmartSprites - this fact should always be kept in mind.
          Hide
          Philipp Rosenhagen added a comment -

          Sorry for the late reply.

          The Unable to render embedded object: File (important thing works as desired - thanks) not found.

          Show
          Philipp Rosenhagen added a comment - Sorry for the late reply. The Unable to render embedded object: File (important thing works as desired - thanks) not found.
          Hide
          Stanisław Osiński added a comment -

          Is the "The Unable to render embedded object: File" some kind of error you are getting?

          Show
          Stanisław Osiński added a comment - Is the "The Unable to render embedded object: File" some kind of error you are getting?
          Hide
          Philipp Rosenhagen added a comment -

          lol - no - this looks like a bug in the JIRA software .. I'm pretty sure I've just posted "The !important thing works as desired - thanks" ... it looks like that the parser of the comment-function is trying to transform this to something else

          Show
          Philipp Rosenhagen added a comment - lol - no - this looks like a bug in the JIRA software .. I'm pretty sure I've just posted "The !important thing works as desired - thanks" ... it looks like that the parser of the comment-function is trying to transform this to something else
          Hide
          Stanisław Osiński added a comment -

          Interesting Thanks for the report!

          Show
          Stanisław Osiński added a comment - Interesting Thanks for the report!
          Hide
          Stanisław Osiński added a comment -

          Moving out of the 0.3.0 release.

          Show
          Stanisław Osiński added a comment - Moving out of the 0.3.0 release.

            People

            • Assignee:
              Stanisław Osiński
              Reporter:
              Philipp Rosenhagen
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 50m
                50m

                  Development