I have this css piece of code (which is generated from a less file, but I don't know anything about less and this code is a piece of a global css file which include all generated code from all less file).
I'm looking for the less equivalent to this piece of css code to find which file I need to modify.
input[type="checkbox"] {
display: none;
}
Thanks for your assistance.
You can't really reverse engineer Less, but this style rule could show up in a number of ways. For example:
Using the & operator:
input{
&[type="checkbox"] {
display: none;
}
}
A selector var:
#my-selector: input[type="checkbox"];
#{my-selector}{
display: none
}
A mix-in:
.dn() {
display: none;
}
input[type="checkbox"] {
.dn();
}
Related
I'm a beginner using SCSS and I'm not sure how to rewrite my old CSS into something new using SCSS for a TypeScript project, right now I picked a few examples below to ask this question, if somebody could show the right way, I guess I can figure the rest of the code I have to rewrite.
The samples below summarize everything that I need to learn:
.sb-slider li > a {
outline: none;
}
.sb-slider li > a img {
border: none;
}
.sb-perspective > div {
position: absolute;
}
.sb-slider li.sb-current .sb-description {
-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=80)";
opacity: 1;
}
There are online conversion tools that are effective, but to learn it by hand, there's one simple rule to keep in mind - any time you see repetition, you know that you can create a nested block out of it. Otherwise, you should just write regular CSS.
For instance, you have 3 declarations in there that start with .sb-slider, so that can become a block. From there you're targeting li > a underneath .sb-slider twice, as well as something underneath that. This lends to SCSS's natural nesting structure, which works exactly how you think it would.
For the .sb-perspective > div declaration, you are only using that once and not repeating it, so there is no reason to make a block out of it. Putting all of that together, you get this:
.sb-slider {
li > a {
outline: none;
img {
border: none;
}
}
li.sb-current .sb-description {
-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=80)";
opacity: 1;
}
}
.sb-perspective > div {
position: absolute;
}
Learning SCSS from old CSS code - how to rewrite this?
SCSS is a superset of CSS. So you can just copy paste that into a SCSS file and it will just work 👍
I have converted the CSS code you mentioned to SCSS code for better understanding on how easily you can convert your code:
.sb-slider {
li {
& > a {
outline: none;
img {
border: none;
}
}
&.sb-current {
.sb-description {
-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=80)";
opacity: 1;
}
}
}
}
.sb-perspective {
& > div {
position: absolute;
}
}
If you notice, it follows the pattern that you have to create parent child relationship in the tags or classes which you are using. Keyword "&" represents that you are using the parent naming.
In the documentation, there is an example that looks like this:
Nav with a separator between header actions.
But I can't for the life of me figure out how the separator gets added and none of the code examples on the page show an example of it.
Any help would be appreciated, thank you.
I'm not sure which demo that is from (would be helpful to provide a link to make sure I can see what it is). However, some elements automatically add it instead of it being explicitly defined as a standalone element, such as the first .header .header-nav .nav-link element will use the ::before CSS selector to place that line. If you need to put something explicitly, then you'll have to add it yourself.
I hade the same problem upon seeing the provided examples. When reading the sources a divider is only defined for .header-nav elements (https://github.com/vmware/clarity/blob/master/src/clr-angular/layout/nav/_header.clarity.scss) and not for .header-actions.
However you could customize .header-actions .nav-link in the following way:
#import "../node_modules/#clr/ui/src/utils/components.clarity";
#import 'node_modules/#clr/ui/src/layout/nav/header.clarity';
.header-actions {
&:last-child {
& > .nav-link:last-child::after {
content: none;
}
}
.nav-link {
&:last-of-type {
position: relative;
}
&::after {
#include header-section-divider();
left:auto;
right:0;
}
&:last-of-type::after {
left: 0;
}
&.active:last-of-type::after {
content: none;
}
}
}
Are there any tools to compile CSS custom properties declared at not :root rule? I want following code with custom properties
.dark {
--bg-color: black;
--fg-color: white;
}
.light {
--bg-color: white;
--fg-color: black;
}
.foo {
background: var(--bg-color);
display: block;
}
.bar {
color: var(--fg-color);
display: inline;
}
be compiled to their non-custom-prop equivalents like that
.light .foo, .light.foo {
background: white;
}
.dark .foo, .dark.foo {
background: black;
}
.light .bar, .light.bar {
color: black;
}
.dark .bar, .dark.bar {
color: white;
}
.foo {
display: block;
}
.bar {
display: inline;
}
The goal is to
switch color schemes by switching dark/light class on root DOM element
use valid css syntax (no sass less)
keep rules code compact
It's actually not safe to do that. I can tell you because I tried so hard to make a safe transformation.
But I failed.
https://github.com/postcss/postcss-custom-properties/issues/1
Ideal solution. Your example is valid CSS and can be used in many browsers (not in IE, Edge (but is in development) and Opera Mini as of writing this answer, 2017-03-27, other major browsers are fine).
Suboptimal solution. Some CSS can be transpiled to achieve better browser support. The solution I found does not support variables on non-:root elements, however. There are also other objections against transpiling of 'future' CSS into 'current' CSS. To the best of my knowledge, you will have to implement your own transpiler (or postcss plugin) if you want to transpile custom properties not on the :root element, but be warned that that is hard in general. Now you don't need the general part, so it is possible. Just does, to the best of my knowledge, not exist yet.
Preprocessing solution. Of course, you don't need a general implementation of custom properties. You have different themes that have their own values for the same set of properties and that's it. Thus, a separate stylesheet can be created as a preprocessing step using any CSS preprocessor.
Now you say the following,
use valid css syntax (no sass less)
but I am going to show this anyway, because I believe that it is a valid solution to your problem. It is definitely the only one I know that actually works if you want to/need to support IE, Edge and/or older versions of other major browsers (Firefox < 31, Chrome < 49, Safari < 9.1, Opera < 36)
You could do this using SASS for example, to do the transpiling on the server side.
// define styles, use variables throughout them
// your entire style definition goes into this mixin
#mixin myStyles($fg-color, $bg-color) {
.foo {
display: block;
background: $bg-color;
}
.bar {
display: inline;
color: $fg-color;
}
}
// define themes, that set variables for the above styles
// use named arguments for clarity
.dark {
#include myStyles(
$fg-color: white,
$bg-color: black
);
}
.light {
#include myStyles(
$fg-color: black,
$bg-color: white
);
}
This compiles to the following.
.dark .foo {
display: block;
background: black;
}
.dark .bar {
display: inline;
color: white;
}
.light .foo {
display: block;
background: white;
}
.light .bar {
display: inline;
color: black;
}
This is not exactly what you want to obtain, but very close. Realistically, I think this is the closest you will get to obtaining your desired output. I know you want to
keep rules code compact
but what you are saying there (I think) is that you want to split out custom properties from their rules to save on number of rules, which is not something any preprocessor I know supports.
You can organize your source SASS in separate files to keep an overview easily. You can even set up a build system that generates a separate stylesheet for every theme you have. It is then possible to have your users select an alternative stylesheet. Browsers have some support for this, but switching using JavaScript is also definitely possible in the latter case. Simply set all stylesheets to be disabled except for the selected one. Here is an example.
This question already has answers here:
Succinct way of specifying two or more values for an attribute in css selector
(2 answers)
Closed 6 years ago.
Is it possible to simplify comma separated CSS selectors with common prefix/suffix?
My current style looks like this (much longer though):
html:lang(qw) div[data-domain*='abc.com'], html:lang(qw) div[data-domain*='def.com'], html:lang(qw) div[data-domain*='ghi.com'], html:lang(qw) div[data-domain*='jkl.com'] {
display: none!important;
}
I'm wondering if something like the following would be possible:
html:lang(qw) div[data-domain*=('abc.com', 'def.com', 'ghi.com', 'jkl.com')] {
display: none!important;
}
As per the comments, this is simply not possible with plain CSS right now. Your only option to shorten the selector is to use a pre-processor, like SASS (Syntactically Awesome StyleSheets). SASS allows you to write more readable, shorter code. You can compile a SASS (*.scss) file to plain CSS on your own computer, so by the time it's on the server, it's the plain old CSS you are used to, understood by all browsers. No extra requirement from your users.
For this particular case, you could use a for-each loop.
#each $domain in 'abc.com', 'def.com', 'ghi.com', 'jkl.com' {
html:lang(qw) div[data-domain*='#{$domain}'] {
display: none !important;
}
}
This would result in the following CSS:
html:lang(qw) div[data-domain*='abc.com'] {
display: none !important;
}
html:lang(qw) div[data-domain*='def.com'] {
display: none !important;
}
html:lang(qw) div[data-domain*='ghi.com'] {
display: none !important;
}
html:lang(qw) div[data-domain*='jkl.com'] {
display: none !important;
}
How can we know if any website is using Sass and Compass for CSS?
That's a though one, but I would take a look at the CSS files, IF the developers forgot about changing the output, you'll be able to spot the file names and line numbers of the source files.
If not, look for uncommon patterns in the CSS output, for instance SASS makes nesting very easy to do, so a selector could look like this in the CSS (you would never hand-write this long selectors)
div#wrapper div#container ul#myId li a { color: blue; }
div#wrapper div#container ul#myId li.sass a { color: red; }
But would be look like this in SASS source file (no repetition, easy to getaway with)
div#wrapper {
div#container {
ul#myId {
li {
a { color: blue; }
&.sass {
a { color: red; }
}
}
}
}
}
Also, look for lengthy class combinations, those come from using the #extend directive, that would look like this:
.button, .button1, .button-submit, .button-add-to-cart, .button-signup, .button-register {
display: inline-block;
}
Another good idea is to look in the source of CSS3 generated buttons, usually developers only care for Firefox, Safari, Chrome and IE, but a SASS generated output will be REALLY verbose with a lot of vendor prefixes, including ones for Opera.
Good luck!
if the developer forgot to compile for production or minify the .css, than you should still be able to see the automatically inserted comments that point back to the original source, like:
/* line 22, ../../../../../Ruby193/lib/ruby/gems/1.9.1/gems/compass-0.12.2/frameworks/compass/stylesheets/compass/reset/_utilities.scss */
.selector {
bla: 123;
}
or
/* line 5, sass/large/_common.scss */
.selector {
bla: 123;
}