Skip to content

/ lost

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

lost-column calculated incorrectly #443

Closed
0x54321 opened this issue Sep 24, 2019 · 4 comments
Closed

lost-column calculated incorrectly #443

0x54321 opened this issue Sep 24, 2019 · 4 comments
Assignees
@peterramsing
Labels
component: build process resolution: Answered status: Support type: Question

Comments

@0x54321
Copy link

@0x54321 0x54321 commented Sep 24, 2019

Is this a feature request or a bug report?

bug report

What is the current behavior?

In my Next.js app, the values generated from "lost-column" are not correct in production, though strangely enough, everything is okay in dev environment.

For example, when using lost-column: 5/12, the values in dev are:

flex-basis: calc(99.9% * 5/12 - (var(--gutter) - var(--gutter) * 5/12));
max-width: calc(99.9% * 5/12 - (var(--gutter) - var(--gutter) * 5/12));
width: calc(99.9% * 5/12 - (var(--gutter) - var(--gutter) * 5/12));

But in production it looks like this:

flex-basis: calc(41.625% - var(--gutter) - var(--gutter)*5/12);
max-width: calc(41.625% - var(--gutter) - var(--gutter)*5/12);
width: calc(41.625% - var(--gutter) - var(--gutter)*5/12);

If it's a bug please provide the steps to reproduce it and maybe some code samples.

I don't know what the issue is, so I can't provide a way to reproduce it. Apparently, the website I'm maintaining has had this problem for a long time, and it would be a nightmare to rewrite all the css to fix it.

What version of LostGrid, browser and browser version are affected by this issue? Did this happen in previous versions?

8.3.0.

Anything else?

Thanks for your help!
@TommySorensen
Copy link

@TommySorensen TommySorensen commented Mar 25, 2020

@0x54321 Was this ever fixed?
@peterramsing peterramsing self-assigned this Nov 1, 2020
@peterramsing
Copy link
Owner

@peterramsing peterramsing commented Nov 1, 2020 •
edited

@0x54321 sorry it's been a year... twins and new job will do that.

--
Okay, so what I'm suspecting is happening is in your dev environment you're not running (or maybe w/ a different config) a CSS optimizer/compressor/linter that is trying to "pre-compile" the code removing the parens 'cause it thinks it knows better. I don't think this is an issue w/ Lost but instead the build.

--
Could you put your build steps here or link the repo (or an example repo) and I'll see if I can help.

--
cc: @TommySorensen
@0x54321
Copy link
Author

@0x54321 0x54321 commented Nov 2, 2020

Hey, thanks for following up. (Better late than never!)

I ended up solving the problem back then by replacing the --gutter variable with a hardcoded value. Apparently there was some other postcss plugin that was removing the parens (maybe postcss-calc?). No clue why it only affected variables, and why only in prod.
@peterramsing
Copy link
Owner

@peterramsing peterramsing commented Nov 3, 2020

That's a good callout. Glad you got it sorted.

My guess is that the prod version is bit more strict and compressed harder. I've had many a "go-live" day slapping me in the face with that realization.

Closing as "ok" but I'll do some pondering on it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@peterramsing peterramsing

Labels
component: build process resolution: Answered status: Support type: Question
Projects
None yet
Milestone
No milestone
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
@peterramsing @TommySorensen @0x54321
You can’t perform that action at this time.