data-uri function uses path of data-uri call, not the string with the path to the file in.

[lukeapage]

from #2541 but I've seen this in projects

// mixins.less
.background(@image) {
    background-image: data-uri(@image);
}

// app/content/button.less
button {
  .background("images/btn.jpg");
}

I would expect the image to be fetched from app/content/images/btn.jpg but it is fetched from images/btn.jpg.

I welcome feedback on whether this is a breaking change (warranting a major up) or a bug fix.

[rjgotten]

I welcome feedback on whether this is a breaking change (warranting a major up) or a bug fix.

FYI: You can elegantly implement this without breaking backwards-compatibility in a very simple way.

Currently the data-uri() function accepts a Quoted tree node holding a string as the file path and resolves it internally as a URL against the location of the file holding the function call. You can overload the data-uri function to also accept a Url tree node holding an actual URL. This way the URL should normalize against the location where the url() CSS function is called and should no longer be normalized internally in the data-uri() Less function.

E.g.

// app/content/button.less
button {
  .background(url("images/btn.jpg"));
}

[seven-phases-max]

@rjgotten

For me it looks more like a workaround rather than a fix. At further iteration they will try to avoid verbosity by moving url to the mixin and the problem comes again. The other problem is that taking the original use-case where this issue came from (#2541), it's often to be used like this:

// mixins.less
.background(@image) {
    background-image: data-uri("@{image}.jpg");
}
// app/content/button.less
button {
  .background("images/btn");
}

(E.g. for a font-face mixin as an example it's usually multiple woff, ttf, eot, eot?#iefix etc. extensions appended to the same file name). And this way the earlier url is also impossible.

[rjgotten]

@seven-phases-max

Then I don't really think there's a suitable solution period. You need some way of determining the context against which a relative URL should resolve. Either you take that context from the file info of the file that defined the string value going into the data-uri() function, or you make the cut-off point more explicit via the url() function and the Url tree node.

If you want to support path variable substitution, then things quickly become tricky because you need to figure out how the various parts of the path need to be normalized.

E.g. , how do you normalize something like:

// mixins.less
.background(@image) {
    background-image: data-uri("../../@{image}.jpg");
}
// app/content/button.less
button {
  .background("../images/btn");
}

How would you combine the relative url resolution and the token substitution-driven combination of those two paths?

I suppose one option is to only resolve against the file defining the string that is being substituted for a replacer token, when the replacer token is at the head of the final URL value going into a url() or data-uri() function and ignore cases such as the above. That seems most logical.

Another solution could be to introduce some path handling functions to join paths or add/remove/edit file extensions (similar to how the unit() function works for dimensions, maybe?) and make things more explicit.

E.g.

// mixins.less
.background(@image) {
    background-image: data-uri(extension(@image, "jpg"));
}
// app/content/button.less
button {
  .background(url("./images/btn"));
}

[seven-phases-max]

For your first example, it does not need any special normalization, "../../@{image}.jpg" expands to "../../../images/btn.jpg" just as it's written (and then it's up to data-uri to handle the path).
And the second example is just... stacking a function to workaround a function to workaround a backward-compatibility with... what exactly? Wrong file paths when calling a mixin defined in other file?

After all if it will be supposed to work "as expected" only with .background(url("images/btn.jpg"));, how it's different from simply writing .background(data-uri("images/btn.jpg")); directly with no changes at all? :)

---

In other words what I mean is that if this is to be fixed then it should be fixed strait with data-uri no matter how breaking it could be. (Honestly I don't know what would be a better strategy: a. wait for more reports/requests for this and then (if there's enough of them) change or b. modify it earlier to minimize possible breaking impact).

---

_{More over, since `url` actually suffers from the same issue itself with `--relative-urls: on`, technically I'd expect the same to be changed same way for `url` then too (unfortunately this will be even more breaking change). In other words, assuming `url` and `data-uri` were initially designed as interchangeable (i.e. `data-uri` is just a special version of `url` (and compiles to CSS `url` in the end)), it would be quite painful to describe why exactly `ulr` behaves "like this" (with options like that) while `data-uri` behaves "like that" (with options like this), and to get certain behavior you'll need `data-uri(url())` combo, limited to "`data-uri` inside a mixin and `url` _out_ of it with `--relative-urls: on`" <- Bhrrrr... :)}

[lukeapage]

For me it looks more like a workaround rather than a fix. At further iteration they will try to avoid verbosity by moving url to the mixin and the problem comes again.

Yeah I agree.

I'm slowly trying to build up to putting some more effort into less for a v3 release and just fixing this.

I was thinking of working out all the possible file paths and trying them one by one - though thats a bit nasty if there are multiple files at different locations... I think I agree its not possible to completely fix this forever, but at least we can fix the normal case.

Possibly a resolve() function might help to pass resolved url's to functions (but then if its not a complete path that wouldn't work and a complete path would work when this was fixed...)

Sorry just quickly jotting down thoughts.

[SomMeri]

This is just a quicknote, but we will have very same problem with import using variable interpolation.

[rjgotten]

import using variable interpolation.

That is both Interesting and unsettling.
Is it an actually supported use-case or a happy coincidence?

[SomMeri]

@rjgotten It is supported, however support is somewhat limited. It was tracked in #410

This works:

@variable: "path.less";
@import "@{variable}";

This does not:

.mixin(@variable) {
  @import "@{variable}";
}

Edit: modified to make link work.

[lukeapage]

I'm not sure I want to support variable @import's in mixins.
The whole variable import thing is a little bit magic and can create some counter-intuitive code.. so I'd rather discourage that.

[Ciantic]

A lot of discussion about workaround, maybe just fix the actual problem? Isn't it clear that data-uri should be relative to file being processed.

Right now I have file which imports a reference from another path, and it still complains about data-uri. At least that must be a bug? I mean if I import by reference it should not try to rewrite the paths to relative to current file.

[seven-phases-max]

@Ciantic

I mean if I import by reference it should not try to rewrite the paths to relative to current file.

Based on what exactly? What does it have to do with reference?

Right now I have file which imports a reference from another path, and it still complains about data-uri.

It sounds like the opposite to the issue above. Could you provide more details? (e.g. paths of the importing, imported and data files etc.).

[Ciantic]

styles.less

.something {
    background: data-uri("some.svg");
}

sub/test.less

@import (reference) "../style.less";
.test {
    color: green;
}

It compiles style.less, but not the test.less because it tries to use data-uri relative to test.less.

Why would reference import try to do rewriting the paths, it's not necessary when using references in my opinion.

[matthew-dean]

I would expect data-uri to follow the url rewriting rules in the options. Of course.... hard to say what that actually means with data-uri.

In general, data-uri should resolve relative to the "calling .less file". So in the case of a mixin, it should resolve relative to where the mixin is called, not relative to the mixin location. The mixin "mixes in" those statements and then resolves them. So @lukeapage I think your interpretation is correct:

// app/content/button.less
button {
  .background("images/btn.jpg");
}

It should look for btn.jpg at app/content/images/. If it's not, that's a bug because it's not how mixins should work. I don't think it's a "breaking change" but a bug fix.