Skip to content
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

Closed
mcbrwr opened this issue Jun 12, 2014 · 4 comments
Closed

full css powered fallback for spritefile #13

mcbrwr opened this issue Jun 12, 2014 · 4 comments
Assignees

Comments

@mcbrwr
Copy link

mcbrwr commented Jun 12, 2014

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.

@jkphl
Copy link
Owner

jkphl commented Jun 12, 2014

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 {{sprite}} variable should contain the path to the appropriate sprite file (you should use it with triple braces, however, like {{{sprite}}}, to avoid escaping of slashes).

Does this answer your question?

Cheers,
Joschi

@mcbrwr
Copy link
Author

mcbrwr commented Jun 12, 2014

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:
PNG template like this:

 {{#selector}}{{/selector}}-png {
     background-image: {{{sprite}}};
}

SVG template like this (I like this mixin approach for some projects)

{{#selector}}{{/selector}}-absafter(@top:0; @pad:{{width}}px;) {
    padding-right: @pad;
    position: relative;
    &:before {
        content: "";
        display: block;
        position: absolute;
        right: 0;
        top: @top;
        background-position: {{position}};
        background-repeat: no-repeat;
        width: {{width}}px;
        height: {{height}}px;
                // load the PNG fallback from PNG template:
                .{{#selector}}{{/selector}}-png;
                // load the SVG file
        background-image: linear-gradient(transparent, transparent), url(/assets/sprite/{{{sprite}}}{{/sprite}});
    }
}

Or can I add a variable in the grunt setup like "png-sprite-path" that I could use in the LESS template like this:

background-image: {{png-sprite-path}}
background-image: linear-gradient(transparent, transparent), url(/assets/sprite/{{sprite}});

btw: thanks A LOT for creating and sharing iconizr: I love it, and it's becoming a part of our teams workflow.

@jkphl
Copy link
Owner

jkphl commented Jun 12, 2014

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!

@jkphl
Copy link
Owner

jkphl commented Jun 19, 2014

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 png variable (which is in fact a callback replacing the .svg file extension against .png — VERY quick'n dirty). Now have a look at this Mustache template (CSS style; for the sake of clarity, I stripped out the unnecessary parts):

{{#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 png callback is applied to the SVG sprite path, effectively returning the path to the PNG sprite. Of course, this relies on the PNG sprite named appropriately, but as long as you don't modify the iconizr sources, the SVG and PNG sprites will always have the same name ...

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants