Problem compiling into sass

[stratboy]

I get this when importing and compiling into sass/scss:

Libsass: Error: "env(safe-area-inset-right)" is not a number for `max' on line 485

And above all, when a sass version of the styles?

[fancyapps]

Duplicate of #2153

[NgatiaFrankline]

Having the same problem.

Here is the error message:

`

F:\UoEDev\build>gulp
[01:57:07] Using gulpfile F:\UoEDev\build\gulpfile.js
[01:57:07] Starting 'default'...
[01:57:07] Starting 'cssFrontEnd'...
DEPRECATION WARNING on line 4, column 8 of F:/UoEDev/build/frontend/scss/styles.css:
Including .css files with @import is non-standard behaviour which will be removed in future versions of LibSass.
Use a custom importer to maintain this behaviour. Check your implementations documentation on how to create a custom importer.

DEPRECATION WARNING on line 4, column 8 of F:/UoEDev/build/frontend/scss/styles.min.css:
Including .css files with @import is non-standard behaviour which will be removed in future versions of LibSass.
Use a custom importer to maintain this behaviour. Check your implementations documentation on how to create a custom importer.

[01:57:08] 'cssFrontEnd' errored after 614 ms
[01:57:08] Error in plugin "gulp-sass"
Message:
frontend\scss\fancyapp\jquery.fancybox.css
Error: "env(safe-area-inset-right)" is not a number for 'max'
on line 485 of frontend/scss/fancyapp/jquery.fancybox.css, in function 'max'
from line 485 of frontend/scss/fancyapp/jquery.fancybox.css
from line 4 of frontend/scss/styles.css

    padding: 75px max(44px, env(safe-area-inset-right)) max(25px, env(sa

----------------------^

Details:
status: 1
file: F:/UoEDev/build/frontend/scss/fancyapp/jquery.fancybox.css
line: 485
column: 23
formatted: Error: "env(safe-area-inset-right)" is not a number for 'max'
on line 485 of frontend/scss/fancyapp/jquery.fancybox.css, in function 'max'
from line 485 of frontend/scss/fancyapp/jquery.fancybox.css
from line 4 of frontend/scss/styles.css

    padding: 75px max(44px, env(safe-area-inset-right)) max(25px, env(sa

----------------------^

messageFormatted: frontend\scss\fancyapp\jquery.fancybox.css

Error: "env(safe-area-inset-right)" is not a number for 'max'
on line 485 of frontend/scss/fancyapp/jquery.fancybox.css, in function 'max'
from line 485 of frontend/scss/fancyapp/jquery.fancybox.css
from line 4 of frontend/scss/styles.css

    padding: 75px max(44px, env(safe-area-inset-right)) max(25px, env(sa

----------------------^

messageOriginal: "env(safe-area-inset-right)" is not a number for 'max'
relativePath: frontend\scss\fancyapp\jquery.fancybox.css
domainEmitter: [object Object]
domain: [object Object]
domainThrown: false

[01:57:08] 'default' errored after 623 ms

F:\UoEDev\build>`

[stratboy]

@NgatiaFrankline see the other post. Anyway, @fancyapps time to fix it.

[fancyapps]

@stratboy This is a saas issue due to fact that webkit recently introduced new CSS functions min()/max() sass/libsass#2521 but saas has their own implementation.

One workaround could be to redefine these functions -

@function max($numbers...)
  @return m#{a}x(#{$numbers})

@function min($numbers...)
  @return m#{i}n(#{$numbers})

[stratboy]

@fancyapps, with all the respect, please do not hide under the sass implementations. You're right it's that, and you're right, we can fix that way, as well as using the 'unquote' way, and it's all quite simple. Yes.

But in practice, I'm sure you already implemented a bunch of other workarounds to circumvent other css or js compatibility problems here and there, and this is only just another one. We devs have to deal with those kind of things all the time when writing code, nothing new here. So, you could just implement the unquote fix right in your code for now.

In my opition, is plain your responsibility to fix the inconsistencies and bugs. Never saw a software that asks users to fix its own issues by themselves.

[fancyapps]

Anyway, I still do not get why you compile CSS into SASS, you should do the opposite :)

[stratboy]

:) It's for code organization and for optimization purposes. I usually merge serveral css/sass files in a way it's ok for my projects. Generally I end up with 2 css files, sometimes max 3, it depends on how I build my websites. Then compress/minify and zip.
Note that sass syntax lets you @import-compile regular css files into scss by using the @import statement AND not writing the .css extention in path (ex. @import "../css/jquery.fancybox") <<< that way the css will compiled just like plain sass.

Finally, I use codekit app to perform the compiling tasks (https://codekitapp.com/).

[abombelli]

@fancyapps Where do we define this workaround functions?

[fancyapps]

@abombelli The best solution would be to avoid parsing existing CSS files, this way you would just avoid any trouble, see sample here on how to use gulp to merge streams - https://stackoverflow.com/questions/35632894/how-can-i-add-css-file-in-the-middle-of-gulp-js-task/35634097

But, if you really have to, then (I guess) you can put these methods into separate file and include before fancybox.css file.

[light-flight]

Anyway, I still do not get why you compile CSS into SASS, you should do the opposite :)

I bundle all the dependencies in one SCSS file which contains only @import directives

[letstestcode]

Anyway, I still do not get why you compile CSS into SASS, you should do the opposite :)

I bundle all the dependencies in one SCSS file which contains only @import directives

I do the same. Have you found the solution?

[light-flight]

Anyway, I still do not get why you compile CSS into SASS, you should do the opposite :)

I bundle all the dependencies in one SCSS file which contains only @import directives

I do the same. Have you found the solution?

No. I decided to use an old version of fancybox.
I've made a pull request with unquote wrapper as described in this issue. But it looks messy after running Gulp build. So I'm confused about my corrections.
Anyway, I've tried to use my fork via Yarn (using yarn add git+ssh://git@github.com:light-flight/fancybox.git#unquote-max-css-function or yarn add @fancyapps/fancybox#refs/pull/2252/head), but in production it bundles code from NPM package, not mine fork. Didn't find any solutions on this problem (stackoverflow question)

[sjclark]

Hmmmmm yea this is a bit of a pain - I can't import Fancybox into my gulp/sass workflow either.

[fancyapps]

@sjclark But why? What makes it difficult? You do not know how to use gulp or what?

[sjclark]

No it just fails on import every time. For a lot of my projects it's just easiest to import css directly into the main include. I Import Fancybox (I have an Extended Commercial License), Mmenu etc. It's always imported fine and now has issues with processing the new units.

In the end I've just reverted back to 3.5.2 (as @light-flight also did); just easier than adjusting everything around just for one dependency.

Merging streams will mean I'll have to go through and update a bunch of older build processes if I want to have updated dependencies - so it's easier for me to just use the legacy version at this stage. I guess I'll wait for libsass to sort themselves / things to become a bit more standardised.

Although I'm buying an iPhone XR next week so maybe I'll suddenly care a lot more 😄

[fancyapps]

Hmmm...

gulp makes things simple like never before.

and yet users have difficulties performing this simple task:

1. Compile .scss files into .css file
2. Merge output from first step with currently existing .css files

I am just ... shocked that fancybox has to include ugly hack or to switch to .scss just because of this.

[sjclark]

I actually just change the .css to .scss (theoretically they've backwards compatible in any case). Am I wrong in thinking it's essentially just because Apple added min and max functions that work differently to the existing min and max functions in sass. As far as I can tell this is a problem in both Libsass & Rubysass. Seems to be a bunch of hacky solutions - but nothing ideal.

Actually now that I think about it I don't think I've had this issue with my Webpack (Laravel Mix) builds - I'll have to have a look over things tomorrow and double-check (and investigate why it's working if it is)..... although could just be that I'm not using Fancybox for those projects.

[fancyapps]

@sjclark That is the point of this problem, CSS and various processors are no longer compatible, CSS is (slowly) evolving - https://twitter.com/bdc/status/1100921258839953408 Sure, Saas homepage states that

Sass is completely compatible with all versions of CSS

but that is just not true, at least without hacks, see sass/sass#2378

And, if you think about it, fancybox would need to have hacks for every single CSS processor...

[stratboy]

css can safely be imported and compiled into scss by importing the file WITHOUT .css extension. I do it all the time in my own framework.

Anyway, I think there are really no excuses, nowadays a plugin must be fully compatible with scss, because scss has too much market to let it alone. You're creating issues to a very large portion of your users when not doing it. That's enough to throw in some little rows of code and solve the thing once and for all.

Also, to be true, in fact we developers do hacks all the time, only we do not always call them 'hacks'. So nothing new or scary here.

[brendon]

So, as far as Ruby on Rails goes, this error occurs not because it's parsing the css file as if it were a sass file, but rather because Rails has set SASS as the compression mechanism for css by default. I guess the options are to disable compression, hack a fix in your own copy of the file, or wait until the SASS team finally fix the problem.

[alexeyff]

Since fancybox uses simple css instead of SASS, the solution is to use
@import url("~@fancyapps/fancybox/dist/jquery.fancybox.css");

instead of
@import "~@fancyapps/fancybox/dist/jquery.fancybox";

And it also helps to avoid this warning

Including .css files with @import is non-standard behaviour which will be removed in future versions of LibSass

see this issue sass/node-sass#2362

[stratboy]

@alexeyff that's not a solution, because if you import with .css extension you're creating a standard import statement (not a real merge), which in turn will end up producing one more http request, which in optimization terms, is usually not desiderable, expecially for just a plugin.

[alexeyff]

@stratboy I don't think so, my current webpack build inline it to 1 file and I don't have any additional request.

You can also check this comment sass/node-sass#2362 (comment) (I use another library in my case)

If you wish to inline the contents of foo.css into the output CSS file then we recommending using a CSS minification step in you build process.

All popular CSS minification libraries will inline @imports see

https://github.com/css/csso
https://github.com/jakubpawlowicz/clean-css
https://github.com/matthiasmullie/minify

[stratboy]

@alexeyff I don't think so, this is not my experience with this kind of import, nor it's what official docs say about importing without extension:

https://sass-lang.com/documentation/at-rules/import#importing-css

[iamkeir]

This is a problem with Sass, not Fancybox. The Sass team are on the case but here is a short-term fix in the meantime: sass/sass#2378 (comment)

Essentially, use unquote('max(44px, env(safe-area-inset-right))') around the declarations.

[fayazrehmani]

Why you have to make life so complicated kindly can some one share sass compatible css file please.. need help

[moorl]

reopen pls

[jpwynn]

agreed, pls reopen. shoudn't be too hard to simply post a revised css.

[jpwynn]

Here's a css file (.txt appended to allow uploading) for fancybox3 with iamkeir's unquote suggestion.

This allows my Rails 5.0.1 specs to pass, Rspec 3.9.0 was barfing on any page visit with "Error: "env(safe-area-inset-left)" is not a number for `max'" but now passes with the changes

jquery.fancybox.css.txt

[stratboy]

This is the only js plugin I've ever seen having such a long thread for such a little thing. C'mon dev, fix it, don't you see that's time to?

[fancyapps]

@stratboy Please, see the number of feature requests - https://github.com/fancyapps/fancybox/issues?q=is%3Aopen+is%3Aissue+label%3A%22Feature+request%22 I bet there is a number of people behind each of them that thinks that it is "such a little thing". But there are too many of them and some of them require complete rewrite. Please, be patient, next big update is coming soon and you can preview it here - https://fancyapps.com/next/

[stratboy]

Great, thank you. I took a look. I know it's still a beta, anyway a suggestion > about the 'close with wheel' fancybox feature > often it opens and gets immediately closed by very little movements on the mouse. So I would suggest to 1. do not allow wheel events until the image is fully opened and 2. do not allow wheel movements smaller than a certain 'secure' amount. If not, probably a lot of times the user will end up closing it even if not intended.

[fancyapps]

Hmm, yes, I agree. Thanks for the feedback.

[techgique]

Just want to try to save other Rails devs a headache in the future. My co-dev tried fixing this by renaming the CSS file with a .scss extension and fiddling with the asset precompile list. She couldn't get it working and handed things off to me. I read the thread here and tried the unquote fix. I applied it one instance of max(...env()) at a time and saw the error message point correctly at the next instance by filename, line number, and column number. But once I had applied it to all of the places in the file and re-ran precompilation, it was showing the error again for the first instance but with no filename or column/line number and STDIN instead.

I didn't understand what was going on and eventually reverted the filename back to .css and updated the asset precompile list accordingly. I tried the m#{a}x trick to no avail. Then I started looking for ways to include the asset without having it be processed by the Sass engine. I don't believe that's possible after poking around a bit.

Then re-reading the messages here I noticed #2182 (comment) mentioning that Rails runs things through the Sass engine for the compressor. So I thought this was why I was seeing the error even after applying the unquote fix across the file and wondered if I could double it up to fix things.

So I went back in and applied the unquote fix again to all the places in the file. Then I clobbered my assets and tried precompiling again. To my surprise the precompilation succeeded. I restarted the app and checked the page and viola, everything was working.

I realize now that my co-dev's renaming of the file to have a .scss extension was causing the asset pipeline to try to compile the file once because of the extension and a second time when the Sass engine was running its compression on all of the CSS. That's why it was saying STDIN rather than giving me a line number for the errors after the unquote fix had been applied throughout the first time. The compression step was choking on the output of the first Sass processing step once the unquote had been applied.

I hope this saves someone else the time it took me to figure this out 😅

[curtp]

Thanks @techgique. Your point about double processing got us on the right path. In our case the fancybox css was included in a .scss file which was being included in a .css file. After implementing the unquote fix I received the STDIN error. I moved the include for fancybox from the .scss file to the .css file and everything works now.

[mykt0ngc0]

Try this:

General Workaround

To deal with CSS-Sass naming conflicts you can use uppercasing to bypass Sass functions.

.class {
  padding-right: Max(15px, env(safe-area-inset-right));
}

The example above will be ignored by Sass as there is no uppercased Max function (only max). CSS is not case-sensitive why Max will work just as well as max.

↗ sass/sass#2378 (comment)