I have been using SASS for a while now, and one thing I really like is how I can use it for my FlashBuilder projects also, namely that is supports custom CSS attributes, like 'embedAsCFF' and 'unicodeRange'.
I'm trying out LESS for the first time, and it will not let me compile to CSS while using these two custom attributes:
embedAsCFF: true;
unicodeRange: U+0021, U+0023-U+0026, U+0028-U+002a, U+002c, U+002e-U+0039, U+0040-U+005d, U+0061-U+007d;
I receive a 'Less Compilation Error: Syntax Error...'
Any LESS users know how I need to add in support for these custom attributes? Thanks in advance.
Update: This issue will be resolved in the release of LESS 1.4.2
Not a Custom Name but a Format Issue
It appears on my experimenting that the issue is really the fact that you are using capital letters in the property names (not that they are custom attributes themselves). Capital letters are apparently not supported by LESS. In other words, these work:
embedascff: true;
embed-as-cff: true;
unicoderange: U+0021; //etc.
unicode-range: U+0021; //etc.
But this does not:
Color: red;
I have not for certain isolated where in the actual LESS code itself this might be fixed (if it can be fixed for the way LESS handles the property rules). I suspect the cause is in the parser.js file lines 1578-1584 (as of this writing), which are:
property: function () {
var name;
if (name = $(/^(\*?-?[_a-z0-9-]+)\s*:/)) {
return name[1];
}
}
This seems to be filtering out allowing for capital letters. I don't know what the consequences would be if that regular expression was changed to allow for them.
Related
Actually I have several LESS variables defined in the following way:
#toolbar-first-level-item-color-background: #transparent-black-80;
#toolbar-first-level-item-color-background_hover: #black;
#toolbar-second-level-item-color-background: lighten(#toolbar-entry-color-background,30%);
#toolbar-second-level-item-color-background_hover: lighten(#toolbar-entry-color-background_hover,30%);
#toolbar-third-level-item-color-background: lighten(#toolbar-entry-color-background,40%);
#toolbar-third-level-item-color-background_hover: lighten(#toolbar-entry-color-background_hover,40%);
#toolbar-fourth-level-item-color-background: lighten(#toolbar-entry-color-background,45%);
#toolbar-fourth-level-item-color-background_hover: lighten(#toolbar-entry-color-background_hover,45%);
As you can see, there are several repetitions in it, so I wonder if could be possible to use something like namespaces or maps to create a more compact and less repetitive declaration.
The idea is starting by structure of nested rules, that create a very clear hierarchy with few repetitions.
I think, you can use a map. It is a new feature in Less lang that allows you to get values using keys.
You can write something like that:
#toolbar: {
#first-level-item: {
color-background: #fff;
};
}
text {
color: #toolbar[#first-level-item][color-background];
}
How can I check if a riot tag has already been loaded and compiled (in-browser with script tag), in order to avoid doing it again, programmatically.
In other words, what should I use instead of doesTagExist function in my simplified code, below?
if (!doesTagExist('my-tag')) {
riot.compile('/path/to/my-tag', function() {
riot.mount('dom-node', 'my-tag');
});
} else {
riot.mount('dom-node', 'my-tag');
}
had same problem. After bit of research I think you can't get it directly. Implementation is stored inside __TAG_IMPL which is not accessible from outside. You can however access selector for all implemented tags via riot.util.tags.selectTags(), which returns comma separated list of selectors i.e. datepicker,[data-is="datepicker"].
Oneliner for convenience
riot.util.tags.selectTags().search(/(^|,)my-tag($|,)/g) >= 0
or depending on your purity inclination
riot.util.tags.selectTags().search('"my-tag"')
Note, that first version is future-proof, if riot decides to start using single commas in selector.
This is how I wrote it, but I get
Parse Error: Unrecognised Input
How can I circumvent this?
I do not want to declare individual mixin for focus, active and disabled states.
I am using WinLess for compiling on Windows 7.
WinLess version:1.9.1
Less.js version:2.1.2
Here is my code
.state(#state,#property,#colour){
&:#{state}{
#{property}:#colour;
}
}
Any help is appreciated.
The best solution to is to update your Less.js compiler to the latest version (v 2.5.3) because it compiles the code provided in the question as-is without the need for any modifications.
However, if you can't upgrade the compiler for whatever reasons then you would need an intermediate variable to form the pseudo-class selectors and then use them like in the below snippet:
.state(#state,#property,#colour){
#sel: ~":#{state}";
&#{sel}{
#{property}:#colour;
}
}
#demo{
.state(hover,color,red);
}
I'm using this with BundleTransformer from nuget and System.Web.Optimisation in an ASP.Net app. According to various docs this minifier is supposed to "remove unreachable code". I know it's not as aggressive as google closure (which I can't use presently) but I can't get even the simplest cases to work, eg;
function foo() {
}
where foo isn't called from anywhere. I can appreciate the argument that says this might be an exported function but I can't see a way to differentiate that. All my JS code is concatenated so it would be able to say for sure whether that function was needed or not if I can find the right switches.
The only way I've found to omit unnecessary code is to use the debugLookupList property in the web.config for BundleTransformer but that seems like a sledgehammer to crack a nut. It's not very granular.
Does anyone have an example of how to write so-called 'unreachable code' that this minifier will recognise?
Here's a place to test online
I doubt the minifier has any way of knowing if a globally defined function can be removed safely (as it doesn't know the full scope). On the other hand it might not remove any unused functions and might only be interested in unreachable code (i.e. code after a return).
Using the JavaScript Module Pattern, your unused private functions would most likely get hoovered up correctly (although I've not tested this). In the example below, the minifier should only be confident about removing the function called privateFunction. Whether it considers unused functions as unreachable code is another matter.
var AmazingModule = (function() {
var module = {};
function privateFunction() {
// ..
}
module.otherFunction = function() {
// ..
};
return module;
}());
function anotherFunction() {
// ..
}
I'm getting a Syntax Error for this mix-in:
.vendors(#statement){
#statement;
-moz-#statement;
-webkit-#statement;
}
Any way to do this, or do mixin variables have to be on the right side of a :?
Since Less v2 you can use the autoprefix plugin to prefix your properties, which seems to be a better alternative. The autoprefix plugin add browser prefixes leveraging the autoprefixer postprocessor. For client side compiling (in the browser) you can use -prefixfree.
As already mentioned by #ScottS here you can use variable interpolation in selectors since Less v1.6, which enables you to do:
.prefix(#property, #value)
{
-webkit-#{property}:#value;
#{property}:#value;
}
selector {
.prefix(property,value);
}
outputs:
selector {
-webkit-property: value;
property: value;
}
You should also read: Am I overcomplicating my LESS for vendor prefixes?
That's a lame answer, but I don't think it's possible.
There's no way to do that, but there are workarounds. If it worked, I think it would be something like this:
.vendors(#prop, #val){
~"-webkit-#{prop}:#{val}";
}
Note: this doesn't work.
Here's a very long discussion on the topic: https://github.com/cloudhead/less.js/pull/698
You might be able to make use of this library: less-properties