relative paths future request

[lauda]

linked to Issue #118

let's see following path structure (from site root):

/a.less
/b/b.less

a.less:
@import "b/b.less";
.a {color: red;}

b.less:
.b {background-image: url('b.gif');}

compilation result for a.less is:
.b {background-image: url('b.gif');}
.a { color:red; }

so, b.gif will not be found, because it located in /b/b.gif. May compiler change relative paths according to path to root .less file?

[alxlit]

+1 for this

[hades200082]

+1

[leafo]

Is this a lessjs feature?

[hades200082]

Yes. @import paths should always be relative to the file containing the @import statement.

[leafo]

I think this issue refers to rewriting the path inside of the url() based on the import path.

[hades200082]

Yes, my bad. It should obviously rewrite the url() paths relative the file in which it was found.

[leafo]

I tested with lessjs and this is not the case.

[hades200082]

Where do we post the request to lessjs then? ;)

It should be... it's logical. It allows you to logically structure your .less files into bundles that either have their own image folders/resources or share a common one or both.

[leafo]

I think it's an interesting idea. In my case image assets are normally organized into their own folders so this isn't a problem for me.

https://github.com/cloudhead/less.js/issues

[lmeurs]

+1

If I am correct: .less files parsed by less.js load images relatively to the .less files, just like .css files do. My guess is that a lot of lessphp users generate a single combined .css file somewhere in their document root, relative paths then become invalid.

Example: your images are in "/images" and "/images/home", your .less files are in "/styles" and "/styles/home". In .less file "/styles/home/footer.less" you reference to an image using "url('../../images/home/logo.png')". This works fine for less.js, but when you generate a .css file in ie. "/styles", the path brakes.

I use lessphp in a custom Drupal theme which has .less files stored in "~/sites/[client_name]/themes/[theme_name]/styles/". With these kinds of paths you have to use relative paths. And when one uses a lot of .less files (like Bootstrap does), a bit of organizing with sub-folders is a must.

Imho I think that an optional parameter ie. "root_url" for lessc() would be great: each time this function enters a sub-folder, it adds it's name to the root_url. When urls are inserted, a path like "../images/logo.png" becomes http://domain.tld/sites/[client_name]/themes/[theme_name]/styles/homepage/../images/logo.png".

[leefernandes]

This is a big issue, has anyone addressed it?

[roborourke]

Hi @leafo, I think @lmeurs has the same idea as I just had - being able to pass in a URL for the parser to calculate relative URL paths from would be an awesome addition and would make .less files much more portable. For example using twitter bootstrap requires some modification for image paths to be worked out.

Lessjs does it for the main .less file at least, I'm personally not fussed about relative paths in subdirectories because I keep my styles at the same level and the graphic elements in a separate folder. It's something for lessjs to work out and implement first.

I'd definitely like to see an optional argument for passing a URL into the parser though. What do you think?

[ghost]

This issue also concerns font-face urls, like:

@font-face {
    font-family: 'MyFont';
    src: url('../fonts/MyFont.eot');
    src: url('../fonts/MyFont.eot?#iefix') format('embedded-opentype'),
    url('../fonts/MyFont.woff') format('woff'),
    url('../fonts/MyFont.ttf') format('truetype'),
    url('../fonts/MyFont.svg#MyFont') format('svg');
}

[Krinkle]

Note that this can get tricky when dealing with abstractions like mixins.

/* -- /css/common/mixins.less */
.icon-thing (@url) {
   background-image: url(@url);
}

/* --- /css/widgets/foo.less */
@import "common/mixins";
.widget-foo-icon {
    .icon-thing("images/foo-icon.png");
}

lessphp:
  importPath: [ css/ ]
  parse: [ css/widgets/.*less ]

Aside from what lessphp and/or lessjs currently do, it's not obvious imho whether this should reference foo-icon.png from:

• css/widgets/images (relative to where the string was written)
• css/common/images (relative to where the url is used)
• or even css/images (relative to importPath, this might be feasible if we treat url expansion similar to importPath, e.g. current directory has precedence with fallback to discovery in the import paths)

[ghost]

IMO the path should be relative to where it is written.
So in:

/* --- /css/widgets/foo.less */
@import "common/mixins";
.widget-foo-icon {
    .icon-thing("images/foo-icon.png");
}

The file would be in /css/widgets/images/foo-icon.png

[Nodge]

I think it would be clearer if the path will be relative to where url() function is written.
For example:

/* -- /css/common/mixins.less */
.icon-thing(@url) {
   background-image: url(@url);
}

/* --- /css/widgets/foo.less */
@import "common/mixins";
.widget-foo-icon {
    .icon-thing("images/foo-icon.png");
}

The file would be in /css/common/images/foo-icon.png.

If we want to use the /css/widgets/images/foo-icon.png file so we can use url() function like this:

/* -- /css/common/mixins.less */
.icon-thing(@url) {
    /* leave the path unchanged because the '/css/common/css/widgets/images/foo-icon.png' doesn't exists. */
    background-image: url(@url);
}

/* --- /css/widgets/foo.less */
@import "common/mixins";
.widget-foo-icon {
    /* the path will be changed to '/css/widgets/images/foo-icon.png' */
    .icon-thing(url("images/foo-icon.png"));
}

The file would be in /css/widgets/images/foo-icon.png now.

[ghost]

What if you want to move the mixins and not the images? What if you move the icon-thing method to a different include file which gets included by the mixins.less?
It would make it very difficult to find out what the url should be relative to.
It is, IMO, much more logical and simple to make the url relative to the file you place the url in.