http://lesscss.org/
Yeah the language syntax looks cool, but are there any significant advantages?
Because from what I see there you actually write more CSS, and since the less stylesheet gets compiled by javascript you get a un-styled site for a few seconds...
That is if you use lesscss for client side sheet generation.
You can also use lesscss on the server side or even compile your sheets before hand.
For example, if you are using node.js you can generate your sheets on the server.
Additionally, if you want, you can use it as a way to write more manageable templates and then "compile" your sheets to generate a formed style sheet for when you are reading for production.
I think it makes perferct sense, because it means that while you are in development, you can change a collection of colors in a single hex color change. When you are ready to deploy, you can compile before hand and then distribute that style sheet with your project.
Think about manageability and using the command line compiler.
Command Line
http://lesscss.org/
Less comes with a binary, which lets you invoke the compiler from the
command-line, as such:
$ lessc styles.less
This will output the compiled CSS to stdout, you may then redirect it to a file of your choice:
$ lessc styles.less > styles.css
To output minified CSS, simply pass the -x option.
Why would you write more CSS using LESS? In the contrary, you write less. And the code that you write is way more verbose than normal css. You can create groups better, use inheritance... You just have a way better overview over your styling than you do with CSS.
My CSS-file for a project currently has over 800 lines... in LESS, it's just around 150.
And to the javascript-compiling: I generally use an offline compiler and upload just the compiled CSS, so I don't have to fuss with the JS client.
You can use a precompiler (ruby's got a cool one, got it running under win).
Try writing a site in less and you'll never want to get back to normal css again :) my own experience...
There is actually a LESS PHP compiler, which I use all the time. I think the best way to work out why it's better than CSS is to use it yourself, but I'll summarise some things:
If you have theme colours used all over the place, for example, and want to change them, it's very easy with LESS's variable system.
You actually write less markup than vanilla CSS, due to not having to retype long selector strings.
If you want to, say, use cross-browser rounded corners, the mixins reduce repetition to almost nothing; all you do is create a class with style definitions in it, and then simply "mix it in". Essentially it's a re-usable function. If you need to change something specific to all rounded corners elements, you just change the single function.
Yeah the language syntax looks cool Personally I think this is rather dismissive and ignorant; if you have a look around the LESS examples, you will see it is miles ahead of normal CSS in terms of usability and speed of development.
There are more reasons, but these should be enough to get you started.
Related
I've made a simple programming language and compiler using Flex and Yacc, and I want to be able to convert my code for use in the browser.
I've already taken a look at projects like Jison, but I don't think that would work for me as I'd then have to maintain two different codebases.
Looking around some more, I'm pretty sure compiling my compiler to WebAssembly and running that in the browser would be the solution. Only problem is that I'm not sure how to go about doing that. Can the Flex library that I pass when linking the lexer and the parser together (-lfl) also be compiled along with my compiler?
I really have no experience with WASM and I'm pretty new to Flex/Yacc too, so there may be some very obvious solution, but I can't seem to find anything.
If you want to take a look at my code: https://github.com/inobulles/aqua-compiler/tree/master/langs/amber
Thanks alot for your time!
There is nothing of much use in -lfl; you shouldn't need it in any real application.
If you don't define yywrap() in your flex file, then add
%option noyywrap
to your flex prologue, so that flex doesn't put a reference to yywrap into the generated code. If you do define yywrap then you already don't need -lfl, but you still might think about %option noyywrap so that you don't need the definition.
I don't know how WASM deals with stdio.h functions; presumably, your intent is to use some other mechanism to feed text into your lexer, but the generated code will still contain references to standard library I/O functions (as does the code generated by Bison).
I have a css class:
.footer-react-btn{
color:#ddd;
}
But if I change .footer-react-btn to .a or .b, then I might save some bytes of text from being loaded.
I want it to happen in my production. I will be writing the code in an understandable manner during my development.
So, Is there any way I can do it in?
I am new here. I need an explanation step by step.
Typically, one simply maintains two files -- a-stylesheet.css and a-stylesheet.min.css. And it's usually limited to removing whitespace, not changing names. Imagine if you were using two different stylesheets and applied this same name-changing mechanism to both... You could suddenly have collisions that otherwise wouldn't exist. Plainly, just not a good idea.
At any rate, the closest thing to what you're looking for is django-compressor which combines and minifies your static JS/CSS, but it has many behaviors you may or may not want.
Frankly, it's my opinion that worrying about those few bytes is a waste of time. Simply minifying the CSS is a simpler and safer way to reduce the size of your CSS components. I wouldn't even consider more complex solutions until you really encounter scaling problems.
If you wants to see the fully expanded code in text editor and wants to send the minified css code to clients, use PHP comments.
First of all, make a file with extension php. Eg:- styles.php then add below code into it:
<?php header("Content-type: text/css"); ?>
Then add the minified code. For removing the read-hardness issue, you could add PHP comments like
You just add as many short codes as you wish but don't forget to enter the expanded information inside a PHP comment. The reason I suggested PHP comment instead css comments, is that PHP codes won't be executed by the web server. You can read both minified code and the expanded code(in comments) in the text editor but client browsers will only get the minified code loaded. So, you can decrease that data transferred....
I think that this will be helpful....
I need help on setting up ctags, jsctags, and tagbar so I can have a workable Javascript editing envrionment. I got everything installed but couldn't get an idea how ctags and jsctags work together so I don't know how to configure properly. I have done quite a bit Google around but the information is pretty broken and lacks consistency. I got an error similar to this post, ctags and tagbar configuration are out of sync. I'm on OS X mountain lion and iterm2.
Any help would be greatly appreciated. A step by step instructions would be excellent.
Thx.
First, you have to understand that jsctags and ctags will probably never be in sync. Even if you have only a simple function, both programs may output slightly different informations. Thus it is advised to use one or the other but not both.
Second, AFAIK, TagBar doesn't need to be configured to use jsctags instead of ctags. If you are doing JavaScript it will simply default to jsctags if it's available. TagBar shouldn't complain if you have a working jsctags.
Third, for its own tag-related functionalities (:tag, :tselect, <C-]>, etc.), Vim only relies on the presence of one or more physical tags files. Whether those files are generated by ctags, jsctags or whatevertags is not a concern as long as they are generated correctly.
And now we arrive at the fourth point which is where the pain really is: neither Tagbar nor its older cousin TagList actually use a physical tags file. They tap ctags or jsctags directly without even trying to use or update any existing tags file. Because of that, and the fact that TagBar only deals with the current buffer, your own physical tags file (and thus Vim's tag-related functionalities) and TagBar are almost guaranteed to be out of sync. Even if you use the same indexer.
So… I'd advise you to use either ctags or jsctags and forget anything about syncing TagBar's and Vim's tags-related stuff as both things are completely separate:
Use TagBar to understand/navigate in your current buffer.
Use Vim's tag-related functionalities to move around your project.
Random thoughts…
For Vim to locate your tags file(s) easily, you should put this line in your ~/.vimrc:
set tags=./tags,tags;/
./tags means "look for a tags file in the directory of the current file", tags means "look for a tags file in the working directory", ;/ means "keep looking up and up until you reach /".
The TagBar wiki talks about a bug in jsctags, make sure that you are not concerned by it.
jsctags is better than ctags when you write crazy "modern" JavaScript with lots of callbacks and self-executing functions. If your JavaScript is more traditional, ctags may be enough.
Let's say I saved some .ai file as .svg. Now I want to move all the vectors from this file to Raphael to manipulate them using JavaScript.
How can I do it? What are possible ways to achieve this goal? Please also write any pros and cons, so users will be able to choose best in their opinion way.
I had to do exactly the same thing a few months ago. I used rappar
I used node from the command line to do the conversion and save it to a file
node rappar.js test.svg >test.js
test.js now contains the vectors. The only thing I did find though is that line 537 of rappar
var files = process.ARGV.slice(0);
should be
var files = process.argv.slice(0);
Other than that it worked a treat.
You could loop through the nodes of the SVG and write them to the Raphaël object one by one, but unless you are dealing with nonstandard element types/attributes you are better off using one of the Raphaël plugins that make importing SVGs a one-line command. Such as:
https://github.com/crccheck/raphael-svg-import-classic
https://github.com/wout/raphael-svg-import
I found some simple converter here.
Pros:
It's really simple and straightforward - you upload the file, and get generated code. You can even see a preview of it. When you load really simple .svg it's working perfectly, and you can easily edit the code, but...
Cons:
But the biggest problem of it is that the code is a little bit messy. So if you load bigger file (100+ vectors, or even more; I loaded sth around 1000 for testing purposes). Also names and structure of it doesn't respond to layer's division. Sometimes some of the layers (you can see it in preview) are not in correct order, so if you want to see exactly the same 'image', you need to browse the code, looking which path correspond to which object in .svg file.
Anyway it's the only one I found, and in the end (after some work) you can achieve what you want. Best way to work with it is when you upload your .svg portion by portion, to avoid flood of messy code.
This one worked really well for me http://roomandboard.github.com/vectron/
When installing the rappar dependency at https://github.com/DmitryBaranovskiy/rappar you need to remove the Node.js code to get it to work.
Pros:
Not much code required.
Cons:
It can be a little slow on larger SVGs. You might want to consider saving it to JSON with another Raphael plugin to make the load faster the next time.
All of the vectors are in the file, so you could put those paths to a variable string and Raphael wil use that.
I have a blue-ish colour that I want to use in many places in my app and at the moment I am copying and pasting it between styles in my CSS. Is there a way of defining a constant like the standard colours, 'blue', 'red' etc. that I could share between my CSS, my HTML and my JS?
I'd like to be able to say (somewhere, preferably CSS)
myblue = #33CC99
in CSS say...
background-color:myblue;
in HTML say...
<td color="myblue"/>
and in JavaScript
tag.style.backgroundColor = myblue;
I'm guessing this is impossible and google turned nothing up, so has anyone got any ideas? I doubt I am the only person to come across this.
A very promising product that "compiles" higher-level expressions like variables into CSS is LESS. It needs Ruby. I haven't used it yet but it's definitely worth a look.
A more primitive way to do this would be using a server-side scripting language like PHP.
You would define constants in PHP like so:
define ("MYBLUE", "#33CC99");
and then outputting the value where needed using <?=MYBLUE;?>
Big downside: To do this in external css and js files, you would obviously have to have them parsed by the PHP interpreter, which is not good performance wise if you have a lot of visitors. For a low-traffic site, it probably doesn't matter.
Yes, this is impossible. You could, however, write your own CSS preprocessor (or use one of the existing ones out there), for instance with PHP. The big downside is that you would have to output the colorcode on your whole site with PHP and your scripts would look like
tag.style.backgroundColor = <? echo $myblue; ?>
and likewise in CSS
.someClass {
background-color: <? echo $myblue ?>
}
or something similar. And that isn't really nice either. Of course you could use any server sided script language of your choice. As far as I can judge, this is the only possibility to use a color-constant throughout a whole website.
You could have a look at some processors:
http://cssp.codeplex.com/
http://www.shauninman.com/archive/2007/06/27/css_server_side_pre_processor
http://icant.co.uk/articles/cssconstants/
You may look at HAML+SASS. Though you cannot define variables for all three languages at once, these two can make writing HTML+CSS much easier.
How I would approach this is to make a class in my CSS.
.color_class {color: #33CC99;}
Then call it in my HTML
<td class="color_class" />
You can assign multiple classes to an HTML element.
In the JS, just name the class
document.getElementById('id').className = 'color_class';
Of course you can play with how you want to select your element. A JS library probably has even easier methods for assigning CSS classes.
To achieve this with out using any dynamic CSS (e.g. serving a PHP file with content-type text/css), your best bet is to separate out the places where you define the 'theme'.
<script type="text/javascript">
var theme = '#003366';
</script>
Then you can use a JavaScript file to write out styles based on the themes.
However, if you are able to use a CSS pre-processor, go with that. You'll have much more flexibility and the code will be easier to maintain. I almost always use a PHP or JSP page for CSS.
As other users have noted you can't do this in straight HTML, JS or CSS unless you pass all HTML, JS and CSS content via a CGI/PHP/ASP script - which isn't actually a bad approach as it's easy to maintain.
If you use a query string in the reference to included CSS / JS files - e.g. '/css/stylesheet.php?timestamp=2010-01-01+00:00:00', then almost all clients will aggressively cache your CSS/JS files, negating any impact on load parsing them in a scripting language may have (though unless the site is likely to be particularly busy I wouldn't be too connected about that).
If you are using Apache (which is likely), an alternative approach would be do use something like mod_set to re-write all HTML, JS and CSS files on the fly for you. This may be more difficult to support if you are not familiar with configuring Apache (or are using another web server).
With regard to tag naming:
With either approach I strong suggest using a clear tagging system to denote your dynamic variables (e.g. %MyBlue%) and to consider having variables names be representative (e.g. %HeadingBackgroundColor%, %FontColor%, even if both are set to %MyBlue%), as that can prevent things getting hairy later on (when you discover that changing one value has intended consequences).
Using more representative names may seem unnecessarily verbose at first glance, but it causes problems in many cases because colours end up clash in unintended ways when they are significantly different from the original scheme (this is true of a lot of mainstream software which is skinnable - because the author made the assumption that %value1% and %value2% would always go together and so would %value1% and %value3% - meaning in effect the options for themeing are severely limited by an unintended dependancy).
I do this at build time by running my CSS files through Freemarker.
I am not sure of your end goal. If it is to allow selection of one of several themes for a web page, you could simply have multiple CSS files, and a cookie/session variable/database store of the user's prefered style sheet. Then you could just do
<link rel=<? echo stylepref; ?> type='text/css'>
or something along those lines
If you want to be able to completely customize the site, then one of the above answers would be needed.
There's no concept of 'variables' in CSS, but I'd strongly recommend not doing what you're doing. there's no good reason that you can't define all your style information in your CSS sheet as CSS classes. If you do that, and then just apply said classes in html and javascript, that's one major load off in terms of copying and pasting.
Second, remember that you can define more than one CSS class for an element, e.g.
<div class='blue-text white-background'>my content</div>
You can then define those independantly in CSS, a la:
.blue-text { color : Blue; }
.white-background { background-color: white;}
and you can even create rules that only take effect when both are applyed:
.blue-text.white-background { color : AliceBlue; }
If you want to have the color choices dynamically generated, the only real way to do that is as others have suggested, which is either preprocess your files before deployment, or have the CSS dynamically generated and served by your language of choice.
In pure client side CSS grouping selectors allows you to put the same color on many different elements:
p, .red, #sub, div a:link { color: #f00; }