display: inline-block;

[adam-lynch]

Shouldn't this add or provide an option to add display: inline-block; to the sprites? I would assume that most people would be adding these to spans, etc.

[leslc]

Sprites might be used on block elements div or inline elements <a> and <span>.
Block elements should definitely retain their display type. But inline elements should be changed to inline-block.

I've been using this code along with the generated CSS to good effect.

// Expected class order of sprites is: "icon icon-<filename>".  If you do not list "icon" first, these styles won't kick in
span[class^='icon '],
a[class^='icon '] {
  display: inline-block;
}

Any <span> or <a> tag that has the class starting with "icon " will become inline-block.

[aslansky]

I am still thinking about the issue. Because I don't want to introduce extra classes in the templates and I also don't want to introduce another command line option for such a thing. The best idea I have right now is rethinking the structure of the templates and maybe introducing something like a small css sprite framework (kind of how fontawesome it does, but for images). But that would raise the maintenance effort especially with the different preprocessor options. So my point right now ... i don't know :-)

Any other ideas?

[leslc]

Btw, I think this is better than what I suggested above. The class order is based on "icon-" prefix and middle vertical alignment is more useful than the default. (However big assumption is that no other CSS classes have "icon-" as part their names).

// Any <span> or <a> tag is changed to inline-block to accept height and width to display icon
span[class*='icon-'],
a[class*='icon-'] {
  display: inline-block;
  vertical-align: middle;
}

This additional class definition makes the generated CSS ready to use "out-of-the-box", but users might want to manage that line of CSS differently. You could just possibly mention the issue with "inline-block" in the README and call it a day. :)