Closed mikestopcontinues closed 6 years ago
Okay, that's weird... let me look into this. 🤔
Thanks for the bug report.
@mikestopcontinues Okay, I wrote a few tests and could you check something for me? Is there anything in your build pipeline that might be trying to solve your "calc" equation instead of letting the browser tackle it?
What you actually should be seeing is:
div {
width: calc(99.9% * 3/4 - (24px - 24px * 3/4));
}
My guess is you have something minifying it.
Let me know.
Thanks! P
Ahh! I had tried to avoid resolving calc early by putting lost after cssnext, but I didn't realize cssnano did it too.
But that turns out not to be the issue, as lost is still giving a margin of 6px, so it doesn't match with the 1/4 width column next to it and pushes it onto the next row.
I think the expected behavior would be for lost to create in a consistent margin of 24px, no matter what the width of the column. Basically...
div {
width: calc(99.9% * 3/4 - 24px);
}
Or does this get in the way of standard column widths?
@mikestopcontinues
Based on my tests LostGrid should be resolving to width: calc(99.9% * 3/4 - (24px - 24px * 3/4));
.
Could you verify that no other plugins are affecting the output?
🤔
Maybe a quick pairing session to see if we can sort it? Could you email me and we can figure out a time.
That's the resolution I'm getting (now that I disable cssnano
). I realized the issue was my config of my 1/4 column. In any case, thank you for the help!
@mikestopcontinues Glad to hear it. Thanks!
Is this a feature request or a bug report?
Bug report
What is the current behavior?
Given up-to-date everything, this input...
Results in...
But what I expect is...
I want to use lost to build a wide column/skinny column layout for a standard blog page. But I can't given this weird inconsistency with the library.
Happy holidays, by the way! :)