I'm a full stack developer that uses sass (.scss) for styling. However, my backend crew, when they have to make front end changes, use css because they are comfortable with it.
I have to convert the css to scss every time manually or else I will overwrite their changes. Is there a way to update my scss file to pull in css changes automatically?
My IDE is PhpStorm (if that helps anybody)
SASS version 3.4.24
I don't see a plugin for PHPStorm to do that; you might have to make one yourself. But even if you do, the SCSS it'd produce probably wouldn't be much better than the CSS you already have. It's silly to convert to SCSS only to compile back to CSS. The whole point of SCSS is so that you don't have to write CSS.
You could convert the CSS to SCSS with sites like this one. Again, results will probably not be much better than if you just kept it CSS.
My solution would be to split the CSS file. One part would be for the stubborn devs, while the other one is the CSS compiled from the SCSS you like to use. So, they can work in CSS, and you can work in SCSS.
You probably need a workplace solution before a technical one.
Related
I very frequently use the CSS line numbers in Inspect Element to find where a rule is in a particular CSS file. When Sass outputs a CSS file, it imposes its own style rules on it which really don't line up 1:1 with how my SCSS is formatted. This makes it hard to find CSS rules in my code because none of the line numbers match. It's completely disturbing my workflow and is a major barrier to my further adoption of Sass.
I've already looked at sass --style=expanded and sass --style=compressed but neither of them come anywhere close to matching the whitespace style I want.
What I really need is a way to make Dart leave all my whitespace and line breaks exactly as they are, and minify mixins down to a single line each. Something you might call --style=preserve-line-numbers Is it possible?
No. That is not possible by SASS itself.
If you like you may have a look to the avaiable styles:
https://sass-lang.com/documentation/js-api#outputstyle
But to be honest: if you use SASS in the intended way with nested styles, mixins, using modules ... the compiled CSS will considerably differ from the SASS code anyway. That even applys to the line numbers. So your problem is a common challenge in the coding process.
As fast debugging is important SASS offers mapping technique:
If activated you are able to see the source code in the browser on the fly. That's really easy and should meet your demands. Maybe you like to have a look on it. Here is a good overview to it: https://thesassway.com/using-source-maps-with-sass-3-3/
Or however if not that way there is another little trick/workarround which may help:
Most SASS projects organize/structures code in partial files (which doesn't make it possible to keep line numbers). That's for different reasons and speeds up working as well. If you do so you just start every file with a CSS comment which notes the file name only. As comments are shown in the browser tools you are able to find the relevant SASS source file without mapping ... and as partial files are almost not as long finding the relevant code (which differs from the CSS) should not longer be the problem.
// ### examples partial filename in a CSS comment
/* base-typography */
...
/* base-forms */
...
/* section-hero */
...
That is not as fast as mapping technique I would really recommend. But finding the code that way is faster than try to keep line numbers exactly the same and missing that way a lot of other advantages of SASS which speeds up my work (like nestings, setting SASS only comments, using mixins and modules ...).
So I am having this Ghost theme (liebling) that I'd like to modify to my needs. E.g. I'd like to change the font-size of the post title and content.
As the theme is quite complex (at least for me) I am having a hard time to figure out which setting has been made in which SCSS file.
When I start Google Chrome and inspect elements it points me to the CSS file that makes the setting. However it doesn't point me straight to the SCSS file it got created from. Of course it doesn't, as this would require some form of debug-database so chrome is able to deduce/know which SCSS files where involed creating that specific CSS.
So long story short: How can I find out which SCSS file lead to which CSS setting?
I have a task to add rtl support to the site by using some kind of a library to modify css which will swap left to right and vice versa and append [dir=rlt] [dir=ltr] to all selectors accordingly.
What I have done so far:
called ng eject
added rtlcss processor as postcss plugin, but it does not fit my requirements. I need it to append [dir=*] to selectors.
tried other plugins but they did not work.
Possible solutions:
make two css files and dynamically load them. (but then you need to add ViewEncapsulation.None to all components) BAD, not so much work, but can break layout
make two css files and run as two different applications. One for rtl, one for ltr. BAD, no resources for that
make rtl by hand. BAD, too much work
forget about rtl processors and make sass mixins. BAD, too much work
make one css file with correct prefixes generated, [dir=ltr] and [dir=rtl] which will result in a doubly sized css but it will eventually work. GOOD but no idea how to do it
create custom library to do this, or fork existing to modify
find working processor
Currently, I am trying to find working processor with no luck.
Are there any ideas on how to accomplish this?
We currently use SASS to pre-compile CSS which consists of various SCSS files.
How does one remove the implementation of SASS so that CSS files are managed directly?
As a side question, is using SASS just personal preference or is it best practice for smallish projects? Why would I want to work in several files when I can just work out of one in a syntax that I'm familiar with?
Cheers
Just remove the sourceMappingURL in your main css will do.
You can also, should you wish, reconstruct traditional CSS by looking at what was being accomplished in the SASS files and rebuilding from scratch. This is cleaner than beginning with the compiled CSS ... but it is not for the faint-hearted: it's kind of like picking out stitches. But if the number of SASS files is few, you'll be better off.
CSS preprocessors (sass/less) were always a solution in search of a problem, in my opinion. They were likely designed by developers who were given sloppy CSS from designers who may not have had good coding practices - but in general, there is very little reason for them, and they add one more bit of unnecessary tooling. I've used them, don't like them, and will never use them again. Totally unnecessary. Good structure in one's CSS will always win.
Using sass helps you organize your code in a better way. And ease the development by using nested selectors and using mixins,variables and much more which you code once and re-use many times.
One will simply go to concerned file and change the contents easily if it divided to multiple meaningful files.
And coming to your question, you can move away from sass very simply. Generate a css file once and from next time onwards start coding in your css local copy rather than extending your sass files again . :)
If you just want to move away from SASS to return to the pure CSS, you have to use the compiled stylesheet. If you compile it via command line, then you would have got the compiled CSS. Anyway, you can use an online tool to compile it, such as this.
Once a time you have the compiled CSS, you just have to import that rather than the SASS stylesheet you've been including in the HTML previously. Just insert this in your <head>.
<link rel="stylesheet" type="text/css" href="Your pure CSS stylesheet URL">
I have a preprocessor import problem. I have vendor css that i would like to copy functionality. Unfortunately, i don't control the html for this situation either.. so essentially i have vendor css & different vendor html, and i am trying to extend functionality of one css rule into another.
Now, the basic concept in many css preprocessors is to extend the rule.
// Vendor
.foo { font-weight: bold; }
.bar { text-color: red; }
// Mine
.bar { .foo }
In the above example, you don't have access to .foo or .bar, but with preprocessors, you can extend functionality from .foo into .bar, which works great for less/stylus/etc. The problem, is when the vendor rules are only defined in raw css.
So with that said, the most obvious solution is to have Stylus/Less import the raw css as stylus/less. However, neither seem to be able to actually do this.. that i've found at least. Less doesn't seem able to (#import "foo.css" directives are ignored) and while Stylus has an option to actually include the imported raw CSS, it did not seem to actually be processing it. That is to say, it would include the css, but #extend directives failed (perhaps i am wrong?).
The other option i could think of is simply renaming the .css files to the preprocessor language extension. Since we want to keep the vendor stuff out of our hands, allowing for proper versioning/etc, This involves a build process which copies the target css files and renames them into the target language extension, but this is error prone. Stylus ran into syntax errors immediately, and Less could just as easily (as not all CSS is valid Less. most is, but not all).
So.. any additional thoughts on this front? Hopefully there is an option i may be missing? Perhaps SCSS handles this better?
Currently, with what i have found is/isn't possible.. i feel the only stable way is to simply copy the raw css bits into my css code. If the vendor code changes, i'll have to update manually, but at least i don't run the risk of vendor stuff changing and all of a sudden the build process fails, because vendor introduced some CSS syntax not supported by less/etc. It is far from good.. but the worst that can happen is my css looks funny, and i need to update.
edit:
I'm going to try SCSS next.. we'll see how it goes. On the site, they claim all CSS(3 only?) syntax is valid SCSS
edit2: For clarity. My question is, give the above scenario, what would you do? Importing the .css files is not possible (See note below!), and renaming .css files to .less/.stylus can in turn be error prone, since less is not a perfect superset of CSS(namely due to proprietary features).
!Note!: I have since been digging around the less source to see what could be done to fix this problem, rather than work around it, and ran into a dozen support tickets on the matter. The main discussion of which seems to be taking place on #issue 1185, and more importantly, check out the changelog which *(i believe) addresses this issue! CHANGELOG 1.4.0 Beta
So with that said, the #import (less) "file.css" is likely the winning scenario here, even if it may have a few bugs due to the beta status. Yay :)
Your best bet is either what #Lee Olayvar said, or use the new ":extend()" feature in LESS. It sounds like you might have tried the extend feature, but you used the "SASS directive" syntax (which IMO is improper use of an at-rule), whereas LESS uses the CSS-like pseudo-selector syntax:
.foo:extend(.bar) {}
And if you are patient (in the coming days/weeks), you will see a new feature that is perfect for what you want to do, and it's unique to LESS. It will allow you to extend or mixin external "silent" styles. Meaning you will be able to "#import" and external stylesheet but the styles won't show up in your compiled code unless you extend them or use them as a mixin.
I'm on the core team for Less.js btw, so let me know if you have any other questions or if I can be of further help.
It looks like all imported .css files won't be prepocessed by less but will just be added with an #import at the top.
You can import both CSS and LESS files. Only LESS files import statements are processed, CSS file import statements are kept as they are. If you want to import a CSS file, and don’t want LESS to process it, just use the .css extension
Source: http://lesscss.org/
The best thing you could do would be the renaming I believe.
While still in beta, the newly added #import (less) "file.css" syntax should properly handle all CSS files. Due to the "official" support, it can also be expected/assumed that any proprietary syntax that breaks LESS would be fixed (though possibly not "supported").
So in theory this is the best option! Barring SCSS, which i have not tried yet in this scenario. Stylus still has issues though, in my tests.
For more information, check out this issue or this changelog.