fixed bug in less.js where relative url()s were being resvolved based ...

[maranomynet]

...on the path of the containing .less file, instead of the original (topmost) .less file.

This brings the behavior of less.js in line with lessc.

Fixes #471 & #465 and probably a few others.

[kevinpschaaf]

I would have fixed it the other way: meaning the url() should be relative to the file that defines it, not to the topmost file that eventually imports it. Abstractly speaking, if you are defining a relative path, you MUST have an idea of what it is relative to so the assets can be placed at that location. Since you have no idea where a given .less file may be imported into, making it relative to some eventual importer's path is dubious--how can you guarantee the assets will be put at the correct place? The only sensible thing is to make it relative to the file that defines the URL, which is what the client-side Less.js already does.

I am a lead on the Enyo framework (http://enyojs.com), and we are looking at including LESS as a part of a solution to enable theming UI widgets. In such a library scenario, it is important to a.) define library CSS/LESS that points to library assets, while b.) allowing that library LESS file to be imported into an application-scoped LESS file so that variables, etc. can be overridden.

I'd like to submit a pull request that does the opposite of this one, bringing lessc behavior in line with Less.js, but I need to know which direction the maintainers choose to go, as it will affect our decision here...

[SalimBensiali]

+1 @kevinpschaaf, It just makes more sense. I just implemented a fix that does exactly what you mentioned. I will send a pull request soon.

[lukeapage]

This will be configured with a relativeUrls option, with url paths being adjusted when on and not being touched when off.

In tandem with this is the rootpath option which can specify a root path for all resources.