Importing - Both CSS and Less

[SomMeri]

Must have also this feature: less/less.js#410

[SomMeri]

Things to keep in mind:

• error handling - test whether errors in imported files are shown
• variables and mixins scopes - they may be either limited to file they are not or not.
• import once vs import multiple times
• use full path to determine duplicates, not whatever path is used in @import.. which may be relative.
• CSS imports from included files are placed on top.

[SomMeri]

They implemented import over http pull 261

[SomMeri]

This seems to be important for a lot of people: #83, #59, #60

[SomMeri]

Some info on how less.js intends to implement variables in import: less/less.js#1108

[SomMeri]

• http://www.w3.org/TR/css3-cascade/#at-import
• http://www.w3.org/TR/CSS21/cascade.html#at-import

[SomMeri]

Import features:

• rewriting discussion Fix the differences between client-side and server-side handling of relative urls and imports less/less.js#961
• @import inside a selector @import inside a selector (feature request) less/less.js#656
• import with media declaration part New kind of import: @import "import/import-test-e" screen and (max-width: 600px); less/less.js#556
• import external url @import external URLs less/less.js#113
• Change the default behavior of "import" to only import once and add import-multiple Change the default behavior of "@import" to only import once. less/less.js#1010

CSS files import issues

• #less suffix which tricks import Incorrect @import order less/less.js#484
• import order - import must be at the top Incorrect @import order less/less.js#484
• troubles with suffixes @import adds .less onto parameters and can cause import loops less/less.js#784

Potential test case:

• Unable to use imported mixin in namespace when another import uses another mixin less/less.js#1105
• @import with relative paths not resolving correctly less/less.js#1083
• @import css bug less/less.js#465
• Duplicated nested mixin rule when @importing multiple times  less/less.js#884
• test for relative urls in import (node less does not adjust relative paths) less/less.js#331

Related issues:

• variable inside url Unable to use a variable in a url() with dynamic stylesheet loading less/less.js#657
• import inside media queries import css inside media queries less/less.js#566
• @include .css file contents @include .css file contents less/less.js#560

Irrelevant:

• @import stacks, doesn't overwrite less/less.js#840
• [Feature request] - Import directory less/less.js#580
• @import bypasses namespacing less/less.js#611
• passing Parser import errors less/less.js#1052 (error handling)
• Allow for error-free @import less/less.js#644
• Import Each Less File Only Once less/less.js#212
• @import_once 'filename.less'; leafo/lessphp#305
• imports without inclusion ( for multiple css files ) less/less.js#102
• @import only substitutes with the file contents if loading in a .less file (needs .css files too) less/less.js#213
• Allow version numbering of @imported less files so as to enabled browser cache busting when versions change. less/less.js#1060

---

To Analyze:

• import a file but override and merge the selectors and properties less/less.js#772
• Fix the differences between client-side and server-side handling of relative urls and imports less/less.js#961

[SomMeri]

Other related questions:

• URL rewriting is done only for import or anywhere?
• URLs are relative to what place?

[alexo]

Here is how the wro4j handles the css @import directive. It is important to notice that when using less4j with wro4j, the css imports are processed properly and everything works out of the box. However, if you want to handle @import directives internally in less4j you have to implement a similar approach....

[SomMeri]

@alexo Thank you, it is good to know - I will start by modifying less4j to print @import statement as is instead of throwing an exception.

From what I understood, less.js can import also .less files. Less files are included before compilation, so all included mixins and variables are available in the main file. Less.js treatment of @import statement seems to be quite rich.

[DanielSvanstrom]

Importing

You can import .less files, and all the variables and mixins in them will be made available to the main file. The .less extension is optional, so both of these are valid:

@import "lib.less";
@import "lib";

If a file already has an extension or parameters, it will not get “.less” added on the end. If you want to import a CSS file, and don’t want LESS to process it, just use the .css extension:

@import "lib.css";

The directive will just be left as is, and end up in the CSS output. This will occur for any import that ends in css, before url parameters.

If you want to import a file only if it has not been imported already, use @import-once

@import-once "lib.less";
@import-once "lib.less"; // will be ignored

@import-once will be the default behaviour of @import in 1.4.0

(taken from http://lesscss.org/#-importing)

[DanielSvanstrom]

Need more input?

[alexo]

I think that assuming the extension of imported resource by adding ".less" is a bit dangerous and adds no real value (just my opinion).

Also the @import should work exactly the same as @import-once. Adding this kind of new capabilities to less language add nothing but more confusion to users.

I'm mentioning these two points, just for sake of discussion. I'm wondering what do you think about it.

[DanielSvanstrom]

I have no strong opinion about assuming the .less extension, just posted what it said on the less site. The problem could be though since it is on the less web site, import statements that work in other compilers will then not work here. I can always work my way around it easily, but still.

I also added that "@import-once will be the default behaviour of @import in 1.4.0" does this mean ONLY in 1.4.0 or SINCE 1.4.0?

[SomMeri]

As I understand it, Less.js collects all backward incompatible changes for 1.4.0. @import now imports the same file multiple times, but 1.4.0 will handle it the same way as @import-once.

1.4.0 was not released yet so I can not test it. I'm not always sure what are bugs and what are features. Less.js has many open issues related to @import and also plan to do some related refactorings, so I can not rely entirely on current behavior. For example, this:

@import "import\imported-1.less" handheld and (max-width: 400px);
@import "import\imported-1.less" screen;
@import "import\imported-1.less";

#namespace {
  @import "import\imported-1.less";
}

compiles into:

@media handheld and (max-width: 400px) {
  // imported-1.less content
}
@media screen {
  // imported-1.less content
}
#namespace {
  // imported-1.less content
}

the same with @import-once compiles into:

@media handheld and (max-width: 400px) {
  // imported-1.less content
}

e.g. #namespace content is ignored and so is @media screen statement.

Is this a bug or a feature and I should not use @import-once this way in the first place?

[alexo]

Implementation of this kind of "features" should be postponed until there is a specification available.

[SomMeri]

My thoughts on the suffix issue: As a general strategy, I think that port should behave as close to original compiler as reasonably possible. People should be able to take their existing projects and switch compilers without having to rewrite them. It may differ on apparent bugs or insignificant things (formatting, comments handling).

So, I prefer to implement less.js way even if I would choose a different one in the same situation. Less.js is currently very responsive to suggestions and questions (they answered all mine within a day or two), so I do not think that there is a reason to fragment less language.

So basically, I agree with @alexo on the suffix issue, but less.js does it, so I think that less4j should too.

[SomMeri]

@alexo That sounds reasonable.

@DBarbarian If I implement a simple version of import first, would that be enough for you?

Import-once will import each file once regardless of ruleset it is in or media queries it has. The file will be considered CSS if its name ends with ".css" and less otherwise. CSS file import statement will be left as is and less file import will be compiled.

The next version then can already have something while the analysis of full less.js import functionality will continue. Everything described in your comment would work, but not much more.

Do you need urls with parametersfile.css?id=123.

[alexo]

@SomMeri I'm wondering how are you planning to implement the @import feature, since the less4j compiler is not aware of less resource location being compiled. Will you change the compiler interface?

[DanielSvanstrom]

A simple import does it for us. We have no need for any extra fancy stuff. We do not need any parameter functions.

[SomMeri]

@alexo I have not thought about the best solution yet. Obviously, I will have to change the API. The compile method can take a file instead of string as a parameter or file path as an additional parameter. Any preferences?

[alexo]

@SomMeri Ideally, you should leave the current method signature unchanged and expose a new method which takes the file as the argument. But you have to be aware about the limitation of this approach (ex: how to compile absolute referenced resources, when the File is unknown).

[SomMeri]

@alexo The string based method (current) can treat every import as an attempt to import css file e.g., output original import statement. If the imported file name does not end with .less, it can produce warning or error.

@DBarbarian OK, I will do simple import first. The other #83 issue then can be considered a request for simple import and be closed it when it will be done (to keep tracking of what was done and what was not done). Simple import seems to be simple enough to be planned for the next 0.0.10 milestone.

This one can stay open until imports are fully solved.

[alexo]

@SomMeri would it be possible to leave the @import statement unchanged when the location of the compiled resource is unknown?

[SomMeri]

@alexo Yes, it certainly will be possible. I can also produce warning on such case, so user will be able get that information if he is interested. Warnings can be ignored, so it should not bother him if he does not care.

[alexo]

@SomMeri related to this issue, I'm wondering how less4j would allow client code to provide a meaning for retrieving imported content? At the first glance, I couldn't figure this myself.

In case this is not possible yet, would you consider adding some sort of ImportedResourceLocator interface which could be implemented by client.
My use-case is this: using import handler provided by less4j in wro4j considering that processed resources are located at arbitrary location which is not always a File.

Thanks,
Alex

[SomMeri]

@alexo Less4j uses LessSource to fetch imported files. Less4j does not care what is behind the LessSource interface as long as its implementation returns data or throws appropriate exceptions.

Extend it and override three methods:

• relativeSource - get referenced source,
• String getContent - importing of css and less,
• byte[] getBytes() - used from data-uri function - it encodes file content into base64.

Then you just have to use CompilationResult compile(LessSource inputFile) method of LessCompiler interface to compile your sources.

[alexo]

Great, thanks!
On 3 Feb 2014 15:27, "Mária Jurčovičová" notifications@github.com wrote:

@alexo https://github.com/alexo Less4j uses LessSource to fetch
imported files. Less4j does not care what is behind the LessSourceinterface as long as its implementation returns data or throws appropriate
exceptions.

Extend it and override three methods:

• relativeSource - get referenced source,
• String getContent - importing of css and less,
• byte[] getBytes() - used from data-uri function - it encodes file
  content into base64.

Then you just have to use CompilationResult compile(LessSource inputFile)method of
LessCompiler interface to compile your sources.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-33953767
.

[SomMeri]

@alexo If you want the import-once to work properly, then you have to implement hashCode and equals methods of LessSource. They are used to determined whether the file was already imported or not.

[SomMeri]

Closing since new way of importing was already implemented. All unfinished import related things should have their own issue.