Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
In Less and Sass we make use of lots of mixins, how does the browser compile or converts those mixins to regular CSS and apply those styles?
The browser DOES NOT convert pre-processed (LESS, SCSS, Compass) CSS rules.
You need to use a build script/compiler BEFORE linking a normal CSS file to your HTML. This process converts SCSS/LESS -> CSS for your browser to render.
You can use Webpack, Grunt, Gulp, or even desktop/GUI tools to do this.
You can also use a javascript parser to inject the final CSS into the page onLoad but this has performance implications and IS NOT recommended.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 months ago.
Improve this question
I've an angular app which uses SASS.I want to style a certain class of buttons in specific way. This class of button is used throughout my app in certain components. I want to know which would be better way to write the common style for them. I know using #import and #extend will copy my common styles into each component's scss right after compilation? So will it affect the size of my application as well it's performance?
Another idea I have is to go for global stylesheet, styles.scss.
I want to know which would be better in terms of maintenance and performance.
indeed, #import and #include will copy the code into your component style, so your bundle size will grow.
Using #extend only copy the CSS selector of your class (instead of its content), so your bundle will also grow, but less than using #include. A downside of #extend is you can't use a #media queries with an #extend.
The lightest solution is using styles.scss, which can obviously be splitted into multiple files, which would be imported into your styles.scss. That is how I personnaly use a Design System in all my angular apps.
I only import variables and mixins in my components. All global stuff is handled in styles.scss
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
There are so many ways to use style inside react js that it confuses me.
for example :
Normal CSS
CSS in JS
Styled Components
Sass & SCSS
Are the above methods influencing website load speed?
What is the difference between these methods?
Try using SCSS when ever you can. It helps to organize your stylings and will be processed to css any way. So there is literally no mentionable downside.
For simple styling i would recommend normal css classes (in .scss files).
For complex animation or styling logic use javascript in conjuction with existing animation libraries like framer-motion. That way you have more control over what is happening and also more possibilities to make your site outstanding and unique.
Performance is all the same, all of them are translated into plain CSS when you run : npm run build.
CSS has its benefits, because of designer-friendly but you may get some problems by accidentally making 2 classes with the same name(this is when you have CSS split into many files) if this happens it will make debugging a nightmare (been there myself).
Sass has the same problem as css, but it's a way more cooler css :)
Styled-component, CSS in js, may fit a little better on react component-based world, because for every "class" that you style a UNIQE className is generated + it gives you more power by having props/state modifying the styles of classes, not like others where for a backgroundColor change you will need 2 classes.
There are a lot of ways to do this, best-comparing article that it served me well in my beginning is in here: https://www.sitepoint.com/react-components-styling-options/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Currently following a sass guide but, in the guide, it auto translates the code into a CSS file. Does this do this by itself or do you have to do it manually? Or (even better) can you just use sass (scss) instead of css files?
Sass is interpreted into CSS. There are several implementations of the interpreter, the "official" one being in Ruby. But until browsers start to naitively support Sass, we're stuck with CSS "under the hood".
From the Sass documentation:
Sass is an extension of CSS that adds power and elegance to the basic language. It allows you to use variables, nested rules, mixins, inline imports, and more, all with a fully CSS-compatible syntax.
I am using it a lot because it allows me to write modular, reusable code. Especially variables and mixins are things that I appreciate.
Just like Coffeescript and Typescript are sitting on top of javascript, Sass is sitting on top of CSS.
And you need a preprocessing engine before the browser is able to use it.
So, to answer your question:
Yes, you can use Sass instead of CSS, provided that you run it through the Sass compiler before using it in the browser.
You can run the compiler manually, or set it up so that it watches for changes and auto-compiles it when needed.
SASS won't ever replace CSS. CSS is the standard developed by the W3C,
and the one browser makers follow (and sometimes advance) when
building their browsers' rendering engines. However, SASS and other
CSS pre-compilers like LESS and Stylus are making an impact on how
people view the evolution of CSS.
source
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm using Bootstrap 3. Ok no problem so far, but, there's a but...I don't know what is the right approach when it comes to alter bootstraps's core css code. So for instance I want to design a new theme, let's say for my own site, and I want to do that using Bootstrap 3, but when it comes to prettiness bootstrap it's like a 3-4 out of 10.
Should I tweak bootstrap files with my own css styling OR Should I build on top of bootstrap and, well, having unused css properties in bootstrap file that I overwrite in my own "style.css".
And I'm not talking about Bootstrap Customize option on site. There are not so many things I could change.
Definitely build on top of Bootstrap, create a new css file. It is better not to touch bootstrap at all, and have it act as it is intended when you need it to.
You can use Customize to add/remove components desired and customize Less variables to define colors, sizes and more inside your custom CSS stylesheets. Bootstrap's customizer finally will generate your csutom javascript & style files with desired components.
If you use css preprocessors like LESS or Sass you can do it by changing variables' values in your editor. Bootstrap's default preprocessor is LESS, but there is also available Sass version.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
The autoprefixer tool is a CSS post-processor that adds the correct vendor prefixes to otherwise 'naive' style declarations.
How does this compare (in terms of effectiveness and developer experience) to mixins provided by LESS and Sass for this same goal of generating vendor-specific styles?
LESS and Sass both have various frameworks and libraries you can integrate into your workflow, most of which include some kind of prefixing mixin, so you will very likely get the same results from either method, and if that's the only thing you use it for, then it probably won't matter which one you use.
Where LESS and Sass get their power is in all the other things they can do, including things like declaration nesting, variables, loops, and other mixins, which may or may not be what you need for a given project.
With this power, of course, comes differences in syntax - you start moving away from native CSS, including the syntax for handling prefixes. In LESS and Sass, if you want to have vendor prefixes on something, you generally go through the #mixin syntax. This is the main difference in "developer experience" that you're going to see, but again, LESS and Sass are larger tools than autoprefixer, so you're probably going to be taking the mixin syntax in part and parcel with the other syntax changes.
In other words - use tools like autoprefixer or prefixr if all you're using is the prefixing, and use LESS or Sass if you want to use the other features.