Nothing happens when task runs

[bubbleheadinc]

Hi. This plugin looks like it will help me a ton. Just can't seem to get it to work.

"grunt-dr-svg-sprites": "~0.9.4" installed fine.

Here is the setup task from my gruntfile:

'svg-sprites': {
  options: {
    spriteElementPath: 'src/images/for-sprite/*.svg',
    spritePath: 'build/svg-sprites',
    cssPath: 'src/base',
    cssPrefix: '_svgSprite'
  }
},

I register the task 'svg-sprites', like all other tasks and run grunt dev. All tasks run but in verbose mode it says "'svg-sprites task" with no other info and nothing is output.

Any idea what could be going wrong?

Thanks for any help and your time.

[phloe]

options.spriteElementPath should just be a path - it doesn't (currently) accept a glob pattern like in your options - though It would be very very easy to support though :)

Throwing some warnings whenever running unsupported options would be a big help I guess. I'm on it.

[bubbleheadinc]

Thanks for the quick response. I was able to get it to run the task and it generates the stylesheet and sprites, but they are empty.

My gruntfile is now:

'svg-sprites': {
  spriteElementPath: 'src/images/for-sprite',
    options: {
      spritePath: 'build/svg-sprites',
      cssPath: 'src/styles/sass/objects',
      prefix: '_svgSprite',
      cssSuffix: 'scss',
      cssPngPrefix: '.no-svg'
  }
},

The output stylesheet (_svgSprite-spriteElementPath-sprite.scss):

{
    background-size: -Infinitypx -Infinitypx;
}
.no-svg  {
    background-image: url("../../../../build/svg-sprites/_svgSprite-spriteElementPath-sprite.png");
}
{
    background-image: url("../../../../build/svg-sprites/_svgSprite-spriteElementPath-sprite.svg");
}

The SVG output (_svgSprite-spriteElementPath-sprite.svg):

<svg baseProfile="tiny" xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="xMinYMin meet" viewBox="0 0 -Infinity -Infinity" width="-Infinity" height="-Infinity"></svg>

It seems to find the folder of SVG's fine. Do I have a config wrong?

Thanks again for your time.

[phloe]

I don't think it found the SVG folder - actually ;)

spriteElementPath needs to be inside options:

'svg-sprites': {
    options: {
      spriteElementPath: 'src/images/for-sprite',
      spritePath: 'build/svg-sprites',
      cssPath: 'src/styles/sass/objects',
      prefix: '_svgSprite',
      cssSuffix: 'scss',
      cssPngPrefix: '.no-svg'
  }
},

See if that makes a difference.

[bubbleheadinc]

Hmm. Putting it back in options results in the original behavior, where it doesn't output anything. When running grunt it isays: Running "svg-sprites" task. Then it just moves on to the next task without doing anything.

Current gruntfile:

'svg-sprites': {
  options: {
    spriteElementPath: 'src/images/for-sprite',
    name: 'svgTest',
    spritePath: 'build/svg-sprites',
    cssPath: 'src/styles/sass/objects',
    prefix: '_svgSprite',
    cssSuffix: 'scss',
    cssPngPrefix: '.no-svg',
    cssSvgPrefix: '.svg'
  }
},

[bubbleheadinc]

Ok. Got it to work. I wrapped it in a task. Used "all" as seen in working gruntfile below:

'svg-sprites': {
  all:{
    options: {
      spriteElementPath: 'src/images/for-sprite',
      name: 'svgTest',
      spritePath: 'build/svg-sprites',
      cssPath: 'src/styles/sass/objects',
      prefix: '_svgSprite',
      cssSuffix: 'scss',
      cssPngPrefix: '.no-svg',
      cssSvgPrefix: '.svg'
    }
  }
},

Now to try and get the sprites working in my project :)

Thanks much!

[phloe]

Ah yes - each individual sprite has to be defined as a target as you just did with all :)

[bubbleheadinc]

Is there a way to set the output path to the sprites? When I generate the sprite and css, I make it a scss partial in my src directory that grunt then compiles with all other partials into a final minified css file. But I am generating the sprites directly into the build/images/sprites directory. So the background URL is out of sync. Is there a way to set the output background url path explicitly?

'svg-sprites': {
  build:{
    options: {
      spriteElementPath: 'src/images/for-sprite',
      spritePath: 'build/images/sprites',
      cssPath: 'src/styles/sass/base',
      prefix: 't-icon',
      cssPrefix: '_svgPng',
      cssSuffix: 'scss',
      cssPngPrefix: '.no-svg',
       cssSvgPrefix: '.svg'
    }
  }
},

Output background url path in .scss:

background-image: url("../../../../build/images/sprites/t-icon-build-sprite.svg");

It would be great to be able to set the path relative to the generated/final css file like:

background-image: url("../../images/sprites/t-icon-build-sprite.svg");

I don't see an option for that.

Thanks!

[phloe]

Hmmm, I would've expected your CSS pre-processor to handle that sort of thing (LESS does)... Are you concatenating your scss-files outside the SASS-compiler?

[bubbleheadinc]

Well the plugin generates the background URL path, right? Looks like it determines the path based on where the sprites are output  relative to where the CSS files is output. 

How does LESS change those paths if they are generated by the plugin?

I have a src directory with a sass dir that has all the scss partials. This is where I have the plugin put the css(scss) file. So it can be compiled with all the other sass partials into a minified CSS in a new build dir. I have the sprites generated and put directly into the build dir. So I'd like to be able to have the background URLs in the new sprite css file point to the sprites in the build dir. 

Does that make sense?

• Sam

On Wed, May 28, 2014 at 4:12 PM, Rasmus Fløe notifications@github.com wrote:

Hmmm, I would've expected your CSS pre-processor to handle that sort of thing (LESS does)...

Are you concatenating your scss-files outside the SASS-compiler?

Reply to this email directly or view it on GitHub: https://github.com/drdk/grunt-dr-svg-sprites/issues/20#issuecomment-44458191

[phloe]

What you want makes perfect sense - but it should be your compiler (SASS) that should be taking care of translating the paths. Translating paths beyond the delivered sprite package (sprites, stylesheets, preview pages) shouldn't be the spritebuilders responsibility IMHO.

If this is how SASS behaves - this must be a problem that a lot of SASS-users have encountered and found a workaround for. I wonder if @benfrain would lend his SASS chops and insights on this matter?

[bubbleheadinc]

I don't think it is Sass related, but more of a workflow issue perhaps. The plugin decides on the background image url path based on the CSS's location relative to the sprite. Sass doesn't have access to change this path.

I ended up outputting the sprite and CSS into the build directory in the same relation that they have in the source, so the background image URL is the same relative path. It makes the gruntfile kind of convoluted, but works.

Question regarding how you deal with hover state: SVG sprites are nice and I love that the grunt-dr-svg-sprites creates the css and png sprite, but how do you deal with hover states? Say I have an icon that is in a button. I set the class for the sprite icon something like this <button>Sweet button<i class="icon-arrow"></i></button> but then want a hover state where icon-arrow is a different color. I don't want to edit the output CSS file to change the bg position b/c it gets rebuilt on each grunt run. Is there a typical workaround for changing sprite states with grunt-dr-svg-sprites? Sorry if this question is out of place. Let me know if it needs to be moved somewhere else.

Thanks again!

[phloe]

Adding a states feature is a great idea!

This grunt-plugin is just a light wrapper for the actual spritebuilder. Most feature requests should probably be made there: https://github.com/drdk/dr-svg-sprites

You can sort of pull states off right now using options.map:

var options = {
    // some options
    prefix: "icon",
    map: {
        "arrow-hover": "arrow:hover", // arrow-hover.svg -> .icon-arrow:hover
        "arrow-click": "arrow:active" // arrow-click.svg -> .icon-arrow:active
    },
    // some more options
};

Though it won't work with more advanced options (options.sizes).

[benfrain]

I would (respectfully) suggest you have some issues in setup and workflow.

Changing the image for an element (via background-position) on :hover is exactly what an image sprite is best utilised for.

You may be better off writing your CSS 'by hand' for the image sprite (including hover states) into a separate file that doesn't get overwritten automatically by grunt on each build.

On 1 Jun 2014, at 14:48, bubbleheadinc notifications@github.com wrote:

I don't think it is Sass related, but more of a workflow issue perhaps. The plugin decides on the background image url path based on the CSS's location relative to the sprite. Sass doesn't have access to change this path.

I ended up outputting the sprite and CSS into the build directory in the same relation that they have in the source, so the background image URL is the same relative path. It makes the gruntfile kind of convoluted, but works.

Question regarding how you deal with hover state: SVG sprites are nice and I love that the grunt-dr-svg-sprites creates the css and png sprite, but how do you deal with hover states? Say I have an icon that is in a button. I set the class for the sprite icon something like this Sweet button but then want a hover state where icon-arrow is a different color. I don't want to edit the output CSS file to change the bg position b/c it gets rebuilt on each grunt run. Is there a typical workaround for changing sprite states with grunt-dr-svg-sprites? Sorry if this question is out of place. Let me know if it needs to be moved somewhere else.

Thanks again!

— Reply to this email directly or view it on GitHub.

[bubbleheadinc]

rasmusfl0e Thanks I'll give mapping a shot.

@benfrain Thanks for looking at my issue. I do have a workflow issue, but I feel it seems to have value, IMHO. I want to keep all of my untouched files in src. Anything that is generated or manipulated programmatically goes into build or build/temp. I was able to reconfigure my gruntfile to work with the spite generator, but it does make things a bit more convoluted. I would prefer that I would be able to set the bg image url path through grunt options. Projects are getting more and more complicated and where and how grunt tasks run and output isn't always straightforward (at least for me).

Hand coding anything related to the CSS or sprite output kind of defeats the purpose of the plugin in my mind. The biggest benefit of the plugin is that there is no need to keep up with file names, class names, and ideally paths. So having to hand code state changes would mean having to keep the class names in sync when file names change. I realize I'm asking to have my cake and eat it too. I'll give the map option a try as rasmusfl0e suggested, but there again I have to keep naming in sync, which reduces the programmatic benefit. I am currently having to use data uri for classes with hover states, which isn't horrible, but I would prefer just to use a sprite with the same icons.

Thanks all!

[phloe]

options.map can also accept a function - so you could write a custom function to do the translation.

I was thinking maybe implementing something like options.states:

var options = {
    // some options
    states: {
        "-hover": ":hover", // arrow-hover.svg -> .icon-arrow:hover
        "-click": ":active" // arrow-click.svg -> .icon-arrow:active
    },
    // some more options
};

SVG names ending with a key in states would get translated. The actual naming would be up to each user.

[bubbleheadinc]

Yes! That would be a nice option that would solve the syncing of file and class name issue. Although, wouldn't that also create class names for the hover states? That may be a bit of unnecessary bloat. An OK compromise though.

[bubbleheadinc]

Quick thought...

Although, if you have the icon on it's own tag like <button>Button<i class="icon-arrow"></i></button> the hover wouldn't activate unless the icon tag is the element hovered. Hovering on the button wouldn't trigger the state change of the icon. I guess the markup would need to be something like:

<button class="btn icon-arrow">Button</button>

with CSS on the button:

.btn { 
  padding-right: whatever-icon-width-is;
}

It limits things a little, but not the end of the world.

[phloe]

Yeah - I'll have to put my thinking cap on to come up with a real solution...

[bubbleheadinc]

I wish I could jump in and help, but it's a bit outside my wheelhouse. I'd be happy to help test if you are able to implement it. - Sam

On Sun, Jun 1, 2014 at 6:03 PM, Rasmus Fløe notifications@github.com wrote:

Yeah - I'll have to put my thinking cap on to come up with a real solution...

Reply to this email directly or view it on GitHub: https://github.com/drdk/grunt-dr-svg-sprites/issues/20#issuecomment-44790781