import silent option

[lukeapage]

import takes the contents of the less file and puts it inline, as if the files were joined together. Silent continue to do this, but marks the contents as silent, so they can be referenced but not output. e.g.

//file.less
.a { color: black; }
.b .c.d { color: white; }

//main.less
@import "file.less";
.e { .a; }
.f:extend(.b .c.d) {}

current output...

.a { color: black; }
.b .c.d,
.f { color: white; }
.e { color: black; }

output with silent (@import (silent) "file.less";)

.f { color: white; }
.e { color: black; }

I see this as every selector in file.less is silenced, but if it is referenced it doesn't stop the use of it from being silent. I imagine this like a silent boolean property on root level selectors and directives - if a new selector is added to a ruleset then it still gets output.

usecase - powerful refactoring/ use of libraries.

only valid with a less file

[lukeapage]

from
#1185

[jonschlinkert]

I keep forgetting to ask about a few things with this feature:

1. how are the silent styles referenced? Are you thinking of using extend for that?
2. it sounds like what you're saying is that an external style will only show up in the compiled code if it is referenced/used, is this correct? if so this is consistent with my understanding.
3. When silent styles are used, where will they show up in the resulting CSS? At the top of the file where the silent file was @imported, or would the styles be copied over to the declaration block where they were used?

[lukeapage]

1. Extend and mixins
2. Yes
3. Imagine silent marks every directive and selector with a silent flag in
   the imported file, but imports as normal. When a selector is extended, just
   the new selector is marked as not silent. when a mixin is used, the pulled
   in rules are marked not silent (only in the pulled in place). When the css
   is generated, silent selectors / media queries containing only silent
   selectors are not output.

To answer your question, extends appear in the position of the silent
import statement, mixins are mixed in and appear in the referenced place as
normal.

This allows you to pull in a subset of a library.. e.g.

.navbar:extend(.navbar all) {}

I have just pulled only navbar related styles from bootstrap.

[jonschlinkert]

@lukeapage thanks for the clarification on this.

Extend and mixins

That's awesome! I didn't realize it would be as flexible (and powerful) as you're planning it to be. Very much looking forward to this.

[jonschlinkert]

What if we either renamed this mute, or renamed the command line option -s, --silent to -q, --quiet for suppressing the output of error messages?

If there is potential for a command line option for this eventually we should consider changing one of the two above, especially since we're already getting some confusion on a couple of other import terms, "less" and "inline" in particular.

[lukeapage]

Hadn't thought about that conflict.. good point. I don't think it will ever be a command line option but it is potentially confusing to have the same name. mute is smaller than silent and I think I prefer it.

[Soviut]

While mute makes sense, I'd say that silent or quiet are more common terms for command line flags.

[jonschlinkert]

👍

[Soviut]

For instance, in MSI installers, the comment way to silence all output is with /quiet:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa372024(v=vs.85).aspx

And a search for "command line flag silent" certainly show a commonality as well.

[lukeapage]

@Soviut we are saying to keep the command line as silent but use mute as the option name inside the less @import (mute) "file.less";

[Soviut]

Wouldn't the disparity make it a bit confusing? An extra character for consistency's sake seems well worth it.

[lukeapage]

@Soviut We want them to be different because they are completely different things!

[Soviut]

Oh! Sorry, in reading back through the original proposal, mute makes a lot of sense now. Coming from an animation background, the concept of "muting channels" in Maya was very common. It seems to fit the paradigm.

[lukeapage]

implemented on the 1.4.1 branch

[jonschlinkert]

I don't think it will ever be a command line option

That makes sense, but I have a related idea that I'd like to get your thoughts though. And I'm not sure if I should create another issue or feature request for this yet... I'd like your feedback on it and your help in clarifying what the actual request is and if you think I should create a request then I will.

Okay, the "mute" feature is clearly for importing external files, but it's particularly well-suited for importing 3rd-party libraries that you don't want to have to "touch". This makes life super easy, it's extremely powerful. IMO it gets orders of magnitude more powerful if we can leverage this feature to make it even easier to import arbitrary external libraries and without having to directly add the import statements inside any .less files. In other words, I would love to be able to expand this feature (or a new one?) to allow referencing external LESS files programmatically without actually touching an import statement.

I came up with a few different non-less.js hacks/workarounds to do this (using assemble-less in particular), but I'm wondering if there is a better, native Less.js solution that could work similarly to the paths option, or leverage it. Maybe silentPaths? Hope this makes sense, I think it could be a big feature for 3rd party compilers to leverage.

[jonschlinkert]

oh I meant muted not silent

[lukeapage]

I like it.

[jonschlinkert]

👍

[jonschlinkert]

Okay, I initially liked "mute", but after having third person tell me they hate it and that they don't see how it explains what the feature does, I think we should change it. All three people (including @cowboy), said they think the name should imply mixins or extends. That was my initial suggestion when we discussed this early on, and I still it makes a lot of sense.

Even though this feature can be used via mixins or extends, when "muted" styles are extended, the behavior is virtually identical to how I described "extending mixins". Point being that, even though one might be using :extend(), on the imported files, the behavior of the external file itself - or rather the styles within the external files - is still exactly like mixins.

I'm of the opinion that we should change the keyword to mixin or mixins: @import (mixins) "any-file.less";. Whether or not this is technically true from a purist standpoint doesn't matter one iota.

From a documentation, education, feature description, and usability standpoint though, how easy and f'ing cool is it to say: "This feature enables you to turn any external library into a set of implicit mixins". Sign me up!

[lukeapage]

okay.. that makes sense.. people like to think in terms of what it gives them, not what it is taking away - and I guess mute just tells you basically what it is doing, not why the hell you would want to do it. along those lines how about "reference" "library" "mixtend" (!?) "use"?

my favourites in order: reference, library, mixins, use, mute, mixtend, mixin

[lukeapage]

disclaimer: I'm more interested in the feature than the exact syntax - words aren't my strongest suit so happy to go with consensus

[jonschlinkert]

I like the terms you proposed, and almost the same order as well. I'll focus on the first three though:

• reference: I like this term because it does a good job of implying that the styles are not actually "used", but rather "consulted". However, this is the downside of the term as well, as a noun "reference" doesn't imply a potential action since it's also synonymous with "dictionary", as in "Use the imported file as a reference". And as a verb, reference doesn't imply the action we want it to. It only implies consultation, as in, "The imported files are referenced.".
• library: I really like this one a lot, because it implies the power of this feature. "The ability to import a library of styles". But it doesn't tell you what's happening (or not happening).
• mixins: Probably not surprising, but this makes the most sense to me because it does the best job of setting expectations and clarifying the intended use to the user. Mixin, as a term, speaks to re-use of code and is already a familiar concept in programming in general. Today we have: "implicit mixins" and "parametric mixins", and we would be adding "imported mixins" or "import mixins".

Another thought, each of the new import options kind of imply the word "as" before them:

@import (as mixins) "bootstrap.less";
@import (as less) "bootstrap.less";
@import (as css) "bootstrap.less";
...

I'd be okay with "as" being added to the actual options, but I'm not sure they're necessary because we could just explain it that way in the documentation.

[jonschlinkert]

I've tried using the terms proposed by @lukeapage, as well as my own, in real code, and I also asked more people who were not familiar with the concept what made the most sense to them, and pretty unanimously everyone has liked Luke's first choice, reference. I'm sold on that now after getting feedback, seeing it in code and mulling over it. I was missing the point in my last comment, reference just makes sense.

What bothers me about "mute" (even though I proposed it) is that it implies that the CSS is somehow being "suppressed" or prevented from doing it's job.

Btw Luke, I've spent quite a bit of time testing the code you implemented for this with Bootstrap and other libraries, and it works impressively well. Really beautiful work. I'd love to see it pushed up into a feature branch so that the early adopters can use it and provide feedback.

[lukeapage]

I might get a break from putting up shelves in my new house in the next couple of weeks to be able to finish 1.4.0 and release it. Then I can release 1.4.1 as an alpha on npm..

[jonschlinkert]

@lukeapage are you good with "reference" then? Let's please get rid of mute. I regret suggesting it lol

[lukeapage]

Yes.. codebase is already changed.. though maybe I need to generate a new
alpha if that's the reason you are asking..

[matthew-dean]

Yeah, mute is bad. Sounds like it's related to audio. Of course silent is similar but often has a wider application than "mute". Silent is better than mute. "Reference" is... okay, I guess. "Library" starts to make more semantic logical sense (between reference and library). "Mixins" is probably the most misleading, since it suggests to me that only mixins are imported. I actually kinda like library. It's less verbose and obscure than reference. And it implies that they can be consumed (but in a different way) as opposed to "silent", which may imply to some that nothing happens.

Still, not opposed to "silent", but of the other options suggested, "library" is best to me. But "reference" is also alright for the same reasons. I'd be okay with reference as well. Library COULD semantically apply that the feature is only for LESS libraries, when it really just means: "Don't produce any CSS output as a result of importing." i.e. "Silence" this output. ;-)

So, my faves in order: silent, library, reference.

[jonschlinkert]

@lukeapage I was just asking about the name, no other intentions, I don't have any opinion on the alpha. thanks!

[maniqui]

I've arrived to this thread while looking for support of silent classes in Less. By "silent class" (or "placeholder selectors"), I will refer you to Sass implementation of them (also).

As I've read the conversation on this thread and didn't see them mentioned, I wonder if "silent classes" went under the radar.
If "silent classes" are to be supported in Less, then, the "import silent option" suggested by OP would be unnecessary, as a .less file could be just imported as usual. Only those classes that are marked as "silent classes" won't be on the final CSS output.

So, question is: does Less support (or is planning to support) silent classes?

Sorry if I'm missing something obvious (n00b here)

[jonschlinkert]

@maniqui this is one feature being proposed instead of placeholder selectors: #1177

And the other is @import (reference) directive, which allows you to "reference" external stylesheets, but only import the styles that are actually extended or mixed in. These features together accomplish the same thing as placeholder selectors, but with far more flexibility and power.

[mgcrea]

Did @import (mute/silent/reference) made it into 1.4.1 / 1.4.2 at the end (looks like it did not as I can't find the related tests)?

[lukeapage]

We are now following semver so its planned for 1.5.0, due to beta soon.

And we settled on reference.