I just sent this to Alexis Sellier <self#cloudhead.net> but it bounced back, prompting me to seek answers here:
Hi Alexis,
First and foremost, thanks for a great Java support for the lesscss library!
I am and have been for a while on version 1.7.0.1.1.
I was attempting to use the extend feature which worked when used as:
.button-a {
&:extend(.button-base);
.rounded-corners-top(7px);
}
but not when used as
.button-a:extend(.button-base) {
.rounded-corners-top(7px);
}
further more, the first case does not work if button-base well looks like this:
.button-base {
...
&:hover {
background-color: white;
color: #ff3c1f;
}
}
The hover stuff never gets active from extended contexts. Does this work in the JS version?
I tried to peek into the java package and it seems you have merged
what I believe to be the JS library with some other Rhino JS code,
making it hard to upgdrade to the latest JS version.
It is not clear from the Java library what version is being used either.
I have myself written another js library and successfully used Rhino,
EnvJS and my JS library, and I choose to approach it a bit
differently, namely that the JS can be supplied separately, as an
argument to my java class which takes care of merging it all.
Is that something you think is possible? If not, how up to date with
the JS code is the current Java version?
What limitations do you see in going the approach I've mentioned above.
Related
Going off the documentation here are Modules and other Geb DSL not expected to be recognized within a Spock Spec with IntelliJ? This makes using Geb with IntelliJ a bit cumbersome with no DSL reference. I noticed from this question that the asker did some custom work to get IntelliJ to wrap and notice the Geb DSL.
My questions is am I doing something wrong or is this expected and has there been any progress on getting the Geb DSL recognized by IntelliJ?
If not does anyone have a workaround for this issue/limitation and or another IDE that does recognized the Geb DSL?
IntelliJ has support for Geb DSL, I've been using it for years and there are even tests in IntelliJ's codebase that confirm it's there.
If you could share how your code looks like and what exactly does not work for you then maybe we can find a problem with your setup or expectations. It would also be good to know whether you are using community edition or professional edition.
Please note that the issue discussed in the question you linked to has been fixed by me in this PR and is no longer present since IntelliJ 2018.2.
EDIT:
After reading your comments under my response I now understand what the problem is. Your expectation is that IntelliJ will be able to figure out what the page type at runtime is and provide you with autocompletion. I'm afraid that is simply not possible - you need to track current page instance in your code for IntelliJ to be able to infer types.
Note that tests in geb-example-gradle are written in the very concise, yet dynamic style which means that IntelliJ is not able to infer types. What you need to do is to use the strongly typed style as described in the documentation. That section of the docs could do with a bit of improvement because it's not precise - I've created a Github issue to track that.
Essentially, if you tweak GebishOrgSpec from geb-example-gradle to:
class GebishOrgSpec extends GebSpec {
def "can get to the current Book of Geb"() {
when:
def homePage = to GebishOrgHomePage
and:
homePage.manualsMenu.open()
then:
homePage.manualsMenu.links[0].text().startsWith("current")
when:
homePage.manualsMenu.links[0].click()
then:
at TheBookOfGebPage
}
}
then IntelliJ will provide you with autocompletion.
I am working on a firefox fork and would like to duplicate -moz-apperance as appearance. I have tried duplicating it as a shorthand property but this throws errors at the compile stage using ./mach build The documentation seems cryptic.
There's documentation about implementing new CSS properties, which might be hard to follow, but browsers are complex pieces of software.
(Currently this question is too broad to provide an answer that's not link-only.)
update: an actual answer from dbaron (via mozilla.dev.platform):
by adding entries to:
https://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSPropAliasList.h
I'm new to hapi.js and I would try test it out. Is it possible to develop with Hapi.js and coffeescript? Could you supply some example on how to setup hapi.js with coffeescript.
I thought the same approach would be useful. From CoffeeScript.org:
The golden rule of CoffeeScript is: "It's just JavaScript". The code compiles one-to-one into the equivalent JS, and there is no interpretation at runtime. You can use any existing JavaScript library seamlessly from CoffeeScript (and vice-versa). The compiled output is readable and pretty-printed, will work in every JavaScript runtime, and tends to run as fast or faster than the equivalent handwritten JavaScript.
If you know CoffeeScript, then you should be able to translate all examples into CoffeeScript by yourself. Else, you should learn CoffeeScript.
Copy and paste any example code into http://js2.coffee and it will show you how it may look like in coffeescript.
And yes you could easily use coffeescript also with hapi like:
Hapi = require 'hapi'
server = new Hapi.Server()
server.connection
port: 3000
server.start ->
console.log 'Server running at:', server.info.uri
Can I specify a LESS compiler version, that is required to compile the file? E.g. in a comment at the beginning of the file:
// use 1.5.0
I've searched the docs, but it seems like there are no such option.
Basically no, there's no such option. And even if it's added in future LESS versions, an older versions still won't have it so this does not help too much soon. Besides older less.js versions, there're a few LESS ports which are also a bit behind the official implementation so you never know what happens with your LESS sources when you give it away.
(Not mentioning that each LESS compiler also usually has several options that affect CSS output, e.g.: --strict-math).
Well, there's possibility to put a sort of version guard into your code, for example once I tried something like this:
.version-guard__() when not(length(-) = 1) {
-:##-;#-:': requires LESS version 1.5.0 or higher';
} .version-guard__();
But it works in less.js only, and it's not so easy to craft an universal trick that will work with other LESS implementations since each one handles errors in slightly different ways (though, to be honest, I did not bother with that too much since my main goal was to get a reasonable error message).
P.S. Alternative version guard method:
.version-guard__ {
-+: requires LESS version 1.5.0 or higher;
}
This one works in less.js and lessphp (at least) but generates dummy CSS output (unlike the first one).
The .less library calls itself a port of ruby LESS library. Can I take away from that that they both are compilers for the same LESS file format or do they expect subtly different less code? Asked another way, am I locking myself in to the dotless library or can use dotless and the less javascript lib on the less files?
Dotlesscss is a straight (almost 1:1 port) of the JavaScript project less.js (a JavaScript implementation of LessCSS by Cloudhead the original author of LessCss for Ruby)
In 99% of the cases the same code that runs on dotlesscss will run on less.js and vice versa. If something works on less.js and doesn't on dotlesscss we consider that a bug and try to fix it if possible.
There are very subtle differences though as it is very hard to keep three different projects 100% synced up.
For one that would be different function names.
Examples would be the color manipulation functions that we implemented before the LessCss project, as we named these after their SASS equivalents..
But in general: the language though is 100% compatible.
You are not limiting yourself to one language. You should be able to move between different implementations fairly easily.
Also dotless runs on Mono so you are not locked to a specific OS either.
If you encounter any problems feel free to raise an Issue on our GitHub Page or through the Mailing List
They're supposed to be equivalent implemnentations however there is a hudge difference between
the server side implementations (ruby, .net, php ...)
the client side javascript implementation
The big difference is that with the client side implementation, you'll be able to use all the dom of the browser in your less files and this would never work with server side implementations :
#height: `document.body.clientHeight`;
More over, in the current version of dotless (1.2.4.0), javascript evaluation is not implemented and is rendered as [script unsupported] in the css output.