I'm trying to multiply the sum of a calculation performed in a function but I get the following error:
"Undefined operation: "pxToRem(4) times 3"
Whilst I could use rems directly it's a lot easier for me to work in pixels. Can anyone tell me why I'm getting this error and if there's a way to solve it? I'm not trying to multiply a string and I'm not multiplying a unit by a unit so I don't understand where the problem is.
// Declare px to rem function
$browser-context: 16;
#function pxToRem($pixels, $context: $browser-context) {
#return ($pixels / $context) * 1rem;
}
// Call the px to rem function
$column-unit: pxToRem(4);
// Multiply sum of px to rem function
$column-span: $column-unit * 3;
Thanks for any help.
If you want a convenient to think in rem, use body {font-size:62.5%;}. The rem will be as quick easily associated with px. E.g. 1.4rem=14px. It's an easier and more elegant method I feel.
https://www.sitepoint.com/understanding-and-using-rem-units-in-css/
As indicated in the comments #disinfor solved the problem. The code I posted was working but on my development server I was importing the function from another file that wasn't being referenced correctly. The lesson I learnt is to import all your files into one main.scss as normal and don't try to cross import them.
Related
We know the advantages of using CSS4 variables but what if we need to get these values from a SASS function like so?:
:root {
--gap-l: toRem(10);
}
toRem is a Sass function that I call to get the sizes dynamically:
$fontSize: 16;
#function toRem($val) {
#return $val / $fontSize * 1.6 + 0rem;
}
This won't fail but won't work either. To have this working we can just have the value directly on --gap-l or keep using SASS vars.
If I try something like --gap-l: #{toRem(10)}; this is the error I get:
It doesn't call the SASS function
You can definitely do that: what you're missing is simply using string interpolation, i.e.:
:root {
--gap-l: #{toRem(10)};
}
The reason is highlighted in their "breaking changes" documentation with regards to CSS variables:
To provide maximum compatibility with plain CSS, more recent versions of Sass require SassScript expressions in custom property values to be written within interpolation. Interpolation will also work for older Sass versions, and so is recommended for all stylesheets.
Try this --gap-l: #{toRem(10)};, the #{} syntax is called interpolation. In the experience of heading bugs myself, when you want to use a SASS expression's raw value along with normal CSS, if you can't use the concise syntax like just toRem(10), try adding interpolation to see if it works.
Another example:
$padding: 5px;
.element {
width: calc(100% - $padding); // will not work, it must be:
width: calc(100% - #{$padding});
}
Here is the code with the updated question: https://jsfiddle.net/bcw763en/.
Notice that if you put :root above the #function, it'll not work.
I am trying to learn media query in css and I have few questions about some of the examples that I have come across. The queries are mentioned below:
I have seen a variable was declared in the following format in a .scss file which is used in a react component:
$screen-xs-max: ($screen-sm-min - 1);
Why is -1 used here?
The second question that I have is about this:
$large-screens-up: "(min-width: #{$screen-lg-min})";
I have 2 questions about these lines of code:
Why is the variable declared within the " ", doesn't that make the variable a string?
Why is # used here? I guess it is to find the variable $screen-lg-min in the path from where it is imported, but I am not sure if its correct. I just want to confirm if that's the correct thing or correct me if I am wrong.
Can anyone please help me with these doubts? I am sorry if this is too simple. I tried getting the answers myself, but couldn't find it.
In SCSS
Consider $screen-sm-min:546px; which will be declared in scss variables file in your project or the node modules folder.
$screen-xs-max: ($screen-sm-min - 1); means that the value of $screen-xs-max will be 1 less than $screen-sm-min that is 545px.
$large-screens-up: "(min-width: #{$screen-lg-min})";
Varible in scss can be used directly using $varible-name ,
But when you want to use the same variable inside a string in scss u will have to follow this
#{$variable-name} method
Why -1
Consider extra small devices width to be 0 to 545px(maxvalue).
Consider small devices width to be 546px(minvalue) to 768px(maxvalue)
Therefore the max width of the extra small devices will be
(min value of small devices) - 1
This method is used to avoid harcoded values in scss file,
For example if you decide to change the values of the width, you can change it in only one place and let the formulae handle the remaining calculation of the widths
I have been going through the Stylus docs and looking at examples, but I can't seem to get a simple calculation to work when using a variable. For example:
Works
margin-right: (1200 / 2)px;
Doesn't work
$siteWidth = 1200;
margin-right: ($siteWidth / 2)px;
I've seen many examples about using variables inside calc and using % before the variable name, or {..} around the variable, but I've tried both and neither works. Am I missing something obvious here?
Update
I failed to mention that I am storing my variables in a separate stylus file. If I create the variable in the same file as I am using it within the calculation, it works fine, however if I try to call the variable when it is imported from another file, it doesn't work. The variables file is the FIRST thing that is included in my main styles.styl file, and I can use the variables site wide without issue - just not when using it in a division calculation for some reason.
Codepen
UPDATE:
Try this instead of parenthesis:
#{$site-width / 2}px;
http://sass-lang.com/documentation/file.SASS_REFERENCE.html#interpolation_
This was a bit of a tricky one, but I solved my problem using the below:
margin-right: 'calc(-%s / 2)' % $sitewidth;
I have actually changed my code a bit to include a new variable to get half the width of the site, as I might use it again:
$halfsitewidth = $sitewidth / 2;
margin-right: '-%s' % $halfsitewidth;
I'm having a strange issue I haven't seen occur. I am trying to do some basic addition to some variables like this:
#screen-break-sm: 768px;
#screen-break-md: 992px;
#screen-max-mobile: #screen-break-sm;
#screen-min-desktop: #screen-break-sm + 1;
Then, those values are being used in some media queries. When it is compiled using gulp-less (version ~3.0.0 in package.json) via Gulp, the output ends up being something like:
#media (min-width:768px + 1) {
// CSS
}
I'm expecting:
#media (min-width:769px) {
// CSS
}
I have tried doing the addition as both #screen-break-sm + 1 and also screen-break-sm + 1px. I've also tried removing the px part of the original values and doing the add and appending the px afterwards, but that doesn't add either.
In case it is relevant, this is one of the gulp scripts that builds a section where I first ran into this issue:
module.exports = function (build) {
return function () {
var pagesPath = build.options.styles.buildPath + '/pages/';
return build.gulp.src('./resources/assets/less/pages/**/*')
.pipe(build.plugins.less({
paths: [ build.plugins.path.join(__dirname, 'less', 'vendor', 'theme', 'bootstrap') ]
})).on('error', build.errorHandler)
.pipe(build.plugins.minifyCss()).on('error', build.errorHandler)
.pipe(build.plugins.extReplace('.min.css')).on('error', build.errorHandler)
.pipe(build.gulp.dest(pagesPath));
};
};
Any ideas why LESS is concatenating/appending instead of performing addition?
[EDIT]
While the solution is the same as the other question that was identified as a possible duplicate, that question does not discuss the problem that users will encounter directly, and therefore I think this question is much better suited for searching purposes. I never found that solution after an hour of Googling and only after getting the answer and the "strict math" verbiage did that other question show up.
Look at strict math option which default value is OFF. Are you sure that for some reason you don't have it set to ON?
lessc -sm=on
lessc --strict-math=on
In an effort to better understand RSA I've been fooling around with the source code for GunPG 1.4, specifically the RSA implementation in the rsa.c file. As the title says, I can't figure out where the padding is happening.
So typically in RSA, padding is done right before the encryption and is taken off during the decryption. Encryption first starts around line 409 where we see
int
rsa_encrypt( int algo, MPI *resarr, MPI data, MPI *pkey )
{
RSA_public_key pk;
if( algo != 1 && algo != 2 )
return G10ERR_PUBKEY_ALGO;
pk.n = pkey[0];
pk.e = pkey[1];
resarr[0] = mpi_alloc( mpi_get_nlimbs( pk.n ) );
public( resarr[0], data, &pk );
return 0;
}
That seems easy, it's giving data to "public" function higher up on line 220. Public is responsible for calculating the important (c = m^e mod n) process. That all looks like:
static void
public(MPI output, MPI input, RSA_public_key *pkey )
{
if( output == input ) { /* powm doesn't like output and input the same */
MPI x = mpi_alloc( mpi_get_nlimbs(input)*2 );
mpi_powm( x, input, pkey->e, pkey->n );
mpi_set(output, x);
mpi_free(x);
}
else
mpi_powm( output, input, pkey->e, pkey->n );
}
Wait a second...now it looks like public is passing the job of that calculation off to mpi_powm() located in the mpi-pow.c file. I'll spare you the details but that function gets really long.
Somewhere in all of this some sort of PKCS#1 padding and unpadding (or something similar) is happening but I can't figure out where for the life of me. Can anyone help me see where the padding happens?
In an effort to better understand RSA I've been fooling around with the source code for GnuPG 1.4, specifically the RSA implementation in the rsa.c file.
Since you’re looking at the older (< 2.0) stuff anyway, and since it’s only for learning purposes, I would rather advise you to check out “ye olde rsaref.c from gnupg.org” where the padding is implemented in a pretty obvious way.
… some sort of PKCS#1…
To be exact, GnuPG uses PKCS #1 v1.5 (specified in RFC 4880).
Can anyone help me see where the padding happens?
Hmmm, let’s see if I can wrap that up somewhat logically. GnuGP pads according to PKCS #1 v1.5, so it just adds random pad to satisfy length requirements.
If you take a look at the cipher/pubkey.c file (which includes the rsa.h file in its head), you’ll notice a pubkey_table_s struct which defines a list of elements that define the key. For padding reasons, random bytes are appended to that list (better: after that struct). It’s done that way because those random bytes can easily be stripped by looking for the end of the list. Keeping a long story short, that’s where random.c probably starts to make a bit more sense to you. Now, all that stuff (and a whole lot more) is compiled into a lib called libcipher… which in itself is compiled to be used by functions that add the padding and handle the RSA stuff the way you expected it. In the end, the compiled executables use the functions libcipher provides to take care of the padding – depending on the individual need for padding.
So what you currently expect to find in 1 or 2, maybe 3 files is actually spread out across more than half a dozen files… which I regard not to be the best base for your learning efforts. As said, for reference purposes, I’ld go for the old rsaref.c they once started out with.
Not sure if this actually provides all the details you wanted to get, but it should give you a first good heads-up… hope it helps.
GPG 1.4 doesn't use any padding at all. It encrypts the raw session key.