I don't know if anyone has ever had the same struggle as me : the time to compile your scss to css can become too long!
I'm working on a project over a theme/template. I need to override it but sometimes I still need it and I have to edit it.
So my question is pretty basic and I haven't found an answer yet; I don't want my compass watch to watch the whole file but only, let say, the first 5000 lines.
Is there a way of doing it?
Related
The question doesn't explain the whole situation. I'm aware of the Workspaces and of SASS source-maps. I'm already able- from the Styles panel- to track the line in the scss file where the specific rule is that I want to change.
That in itself is already a huge achievement, but what would improve a lot my workflow would be being able to visualize the changes as I'm making them live, and have DevTools save them automatically. That way I could instantly adjust elements.
That already can be done in plain CSS. In fact, DevTools is already changing the css file instantly even with SASS running. The problem is that as soon as you modify the scss file again, SASS will recompile and the change in the css file that DevTools made will be lost.
An image is worth more than 1000 words, so:
I'm changing the left property of the red div instantly with my arrow keys. I'm visualizing the changes also instantly. No need to make changes manually, press Ctrl+S, see how the element looks, readjust, save again, etc.
I know I want to change the left property so I click on the scss file and make the change in the Sources panel. Then I save the changes and see how they look. But I can't visualize them instantly as in plain CSS.
Is there any way to do what is already instantly done with css files in the Styles panel but with scss files?
It doesn't have to be done necessarily inside DevTools. Maybe there's an option for SASS to watch for changes in reverse (not only from scss to css).
I was looking for an answer in both directions but to no avail. Any help?
Unfortunately I don't think there's a good answer to your question. There are some ways to convert CSS to SCSS, but they're not intended to be an ongoing process, just a one time conversion.
It's best to only have the conversion one way, if it were bidirectional there'd be a lot of 'what if' situations with collisions that would get really hairy. It isn't a feature I'd want to try to figure out :P
In my workflow, I make small adjustments in the styles inspector (like you are above) and when I'm happy I copy those values to my SCSS file and recompile/reload the page. I think it's about as good as it gets without getting into really strange (probably) unexplored territory.
Small note: Chrome isn't actually editing the CSS file when you change it in the style inspector, it's just making adjustments to the DOM temporarily as if the changes were made where you made them. That's why it's lost on reload.
DevTools has an experimental feature called Live Sass
If you enable the "live sass" experiment, you can edit Sass code in the Sources Panel and see results instantly, I've made a gif of how this works here: https://umaar.com/dev-tips/103-live-sass/
The catch is: since it's experimental, it might not work as expected!
I'm done with googleing, I have to ask you folks...
I have a static web project (not JavaFX, thus no JavaFX toolkits!) in Eclipse Kepler. Now thats the messy road I went:
I created a .less file (for the first time)
Eclipse starts nagging with the "Do you want to add the LESS-project nature?"-popup
I clicked 'no' 10 times (pops up every time I start Eclipse)
then I clicked 'yes' to add the nature for making this stop (could not find ANY workaround for that #$%!+"* !)
Now I face this travesty:
The built in CSS-editor marks every trivial property as unknown. I have no clue how to fix this. I removed the less-nature and restored my old .project file too but the warnings (and even real errors) persist. I found out that rewriting the properties does not summon these warnings!
No, I won't rewrite ~6000 lines of css...
Please help. Please make it stop...
Sorry, found the solution (dumb as can be):
delete project (only!) in Eclipse
re-import project (which completely revalidates the project structure)
errors are gone...
Although this solved my problem, I feel uneasy about the fact that I could not find any possibility to do a complete re-validation without to delete and re-import my project. This is pretty nasty...
Right click project Configure->Remove LESS nature.
I'm so close to being able to actually start actually using less, but for one final roadblock: I can't get the less files to show up in Chrome Developer Tools. I gotta have my developer tools.
I'm using Codekit to compile the less to CSS and to generate the source map, both of which CK seems to be doing. Chrome is even auto-refreshing when I save less changes. But there is only one css file referenced in the inspector, and that is the master, compiled bootstrap.css file.
At one point I saw the less files in the inspector, but no longer. I have no idea when they stopped showing or why, but I can't seem to get them back. I tried turning on Experimental developer features in Chrome, no dice. I made sure Codekit was generating a source map file in the CSS folder, yes. I even opened the map file, but immediately closed it again. Basically a massive, single line of text that I can't make heads or tails of. No help there.
I saw there was a way of adding the less folder to the Chrome workspace, but from what I can tell this will require me to change my entire folder structure, moving the less folder into the root folder of the site, which will have the cascading effect of me having to remap the file source and destinations in Codekit (for starters), which I'd like to avoid (especially if it doesn't work).
I realize there is little in the way of specific info here, but I'm not sure what else I can provide. I'm hoping there is a key step I'm missing, but two hours of googling keep turning up the same results. Anyone have any suggestions?
Well, looks like I've solved the problem, but still no idea what caused it to begin with.
When Codekit generates the source map, it's also supposed to append a line at the bottom of the target CSS file:
/*# sourceMappingURL=bootstrap.css.map */
I found this missing line in a file I believe I'd mistakenly targeted earlier in this confusing process. I copied and pasted it to the bottom of bootstrap.css (where for some reason, it was not present), and bingo, less files in the dev tools. Now if only I knew what I did to make it go away in the first place... you know, so I don't do it again. Here's hopin'. If you or someone you know sees the error of my ways, I'd be very grateful for any edification on the subject.
I'm wondering what the best way would be to customize the less files in Bootstrap and, at the mean time, keep it easy to be updated to future Bootstrap versions.
It's straightforward to just modify the less files, but the problem is that when the next version of Bootstrap comes out, it might be painful to upgrade (because all the changes are already deeply mixed with the original sources.)
Another approach would be similar to the open closed principle, that is, keeping the original less files unchanged, and adding my customized less files to overwrite the CSS rules I need. When Bootstrap gets updated, (hopefully) I can simply replace the less files and everything would work magically. However, regardless of the correctness of my assumption, the same CSS rules would be scattered in even more places and hard to manage. Also, the more we overwrite the CSS (not for compatibility or other purposes), the more bandwidth we waste.
I know this highly depends on how the author of Bootstrap would handle the structure of the framework or even the naming of CSS rules, but I'd still like to hear everybody's opinions.
Thanks.
I worked on a few projects where I had to do pretty much the same thing. Obviously the better choice is, as you said, to write your own less files. Keeping things clean and organized is something that has to do with how you write your own CSS, right ?
My suggestion is to use your own Less files, and then reuse some of the Bootstrap classes to specify your properties.
Also, the bandwidth waste can be minimized, if you use CSS3 inheritance properly.
What are the best ways to use LESS for CSS.
Basically should the Devs write a Less File and then have it compile for production
Should I link the LESS code and the javascript file.
Or should I skip the LESS rout altogether and just remake the classes
I am trying to wrangle together some rather sloppy css and want to get control of it before making major improvements. I think it would be very good to have site wide variable so Less seems like a good thing with the variables and nesting.
I am replacing a lot of the background images with css gradients and box shadows so I am also trying to get rid of the vendor prefixes.
Sometimes I see what kindof looks like class overload but is it bad to append a lot of classes to an element such as
<div class="comment dark-shadow round-corners"></div>
Less is a great styling language. I use it extensively, and it really helps with code maintainability, as well as with speed of writing the styles.
I personally feel that your styles should not be dependent on javascript to render, so I use the less.app to compile all my LESS into CSS. I rest more peacefully knowing that all my CSS is there and that it works correctly before I put anything "live".
If you are interested I have also been compiling a LESS mixin library that can be very useful: https://github.com/jdmiller82/-lessins-
I agree with Jonathan, I don't think you should depend on the users browser to render the styles.
I came up with a solution that uses node.js on the server to intercept requests like styles.css and try to find the equivalent .less file (in this case styles.less) and parse it and return it as CSS.
So on your server you would just have styles.less but you could request the URL example.com/styles.css and get the parsed LESS file. That way the integration is seamless for the rest of your application and it doesn't require the user has JavaScript enabled either.
You don't have to be using node.js for the rest of your app either. I did this in a PHP application.
You can read my tutorial here: http://programming-perils.com/155/parse-less-files-on-the-fly-and-serve-them-as-css/
I realize this answer is about two years later than the above ones but I think the question is still relevant.
I think there are use cases where compiling some LESS client side is a good idea (provided you aren't supporting IE 8 or below) and you have a use case that validates it. For example, an application I've worked on recently has a customizable, theme-able interface where text colors, etc need to be modified based on whether the background color they're on is light or dark and may eventually need to support the ability for the user to change them and see those changes reflected on the site in realtime. This is a great use case for client side LESS I think. Note that only a small LESS stylesheet is compiled and the rest of the application LESS that's not related to theming is precompiled. I haven't seen much of a perceived difference in performance.
So when you see comments like "you don't seriously think any decent developer uses less clientside do you?", I'd take them with a grain of salt.
The way to use LESS for a production website is to compile LESS files into CSS files.
For local development you can have a file-watcher that rebuilds the CSS files for LESS files that were changed.
If you have multiple CSS files to produce from LESS, you should separate them out.
For example, if you have 30 less files and they produce two CSS files a.css and b.css, you will want to separate those two jobs so that you can compile faster. It's faster for developing because you will only compile a.css if you change any LESS files that affect it.