-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
full css powered fallback for spritefile #13
Comments
Hi Matthijs, I'm very interested in your approach, although I'm not yet convinced that Pau's implementation doesn't have any side effects (someone raised the question if modern browsers, that actually do support the transparent gradient, might suffer from a performance issue introduced by the gradient ... do you have any insights into this?). All the templates are rendered multiple times (1 x for SVG + data URIs, 1 x for SVG + sprite, 1 x for PNG + data URIs, 1 x for PNG + sprite). Each time, the template variables get appropriately loaded with values. In case the template is rendered for one of the sprite flavours, the Does this answer your question? Cheers, |
Thanks for your quick reply! To be honest: I haven't checked performance yet. I had a eureka moment and brainfarted this post.. Thinking it through might be a good step ;-) I'll see if I find some time for testing, As soon as I have something I'll let you know. And for the PNG sprite file.. I understand the PNG sprite path not available during rendering of the SVG less file. I do have an idea to create a less template for PNG rendering which renders some classes that I can include in a mixin that would be rendered during SVG sprite rendering (I don't use the data URI setup much) But this approach is focused on my personal use of iconizr and not at all suitable as feature at all... maybe it inspires anyone to push iconizr to the limits ;-) to illustrate, a buggy sketch of what I'm thinking of:
SVG template like this (I like this mixin approach for some projects)
Or can I add a variable in the grunt setup like "png-sprite-path" that I could use in the LESS template like this:
btw: thanks A LOT for creating and sharing iconizr: I love it, and it's becoming a part of our teams workflow. |
Hey Matthijs, glad to hear that iconizr helps you & your team! :) Okay, I understood your point. I'm pretty overloaded at the moment, but as soon as I find some time to work on iconizr, I will see what I can do! |
Hey @mcbrwr, instead of adding a variable specific to the sprite path, I added a more general approach to svg-sprite: Now you can define custom variables for the Mustache rendering processes (see commit bbd051e940e7b6373ed56277251a8affb03b1c10). This way it is also possible to pass callback functions into Mustache. For your specific task, a combination of a customized template along with the appropriate variable definition could do the trick. Imagine these configuration: /* ... */
render : {
css : true
},
variables : {
png : function() {
return function(sprite, render) {
return render(sprite).split('.svg').join('.png');
}
}
}
/* ... */ They define a {{#svg}}{{#selector}}.{{expression}}{{^last}},
{{/last}}{{/selector}} {
background-position: {{position}};
background-repeat: no-repeat;
background-image: url({{#png}}{{{sprite}}}{{/png}});
background-image: linear-gradient(transparent, transparent), url({{{sprite}}});
}
{{/svg}} As you can see, the I think this should be a rather universal approach and you should be able to render your custom output, right? Please let me know what you think and feel free to reopen this issue in case of problems! Cheers, Joschi |
like this: http://pauginer.github.io/invisible-gradient-technique/
I'm already baking a new less template but haven't figured out how to address the sprite's png file from the template.
The text was updated successfully, but these errors were encountered: