I apologize for the excessive qty of commits, I accidentally started of a branch that had not been merged and I wanted to ensure those were not part of this commit.

This looks amazing! That screenshot really sells this PR :)

It looks like there are some tests that will need to be fixed up: https://app.circleci.com/pipelines/github/streamlit/streamlit/6698/workflows/165d4473-3b5b-447e-9057-9f6bbd615928/jobs/19160

st.multiselect.spec.js looks like a flake, and st_columns.spec.js probably just needs tweaking to look for the new flex values. st.image.spec will probably need to regenerate the image snapshot, though. Please let us know if you're having issues with any of those!

@akrolsmir I am having some problems with running tests locally. I am working through it, but I did adjust the column_spec so it will hopefully pass.

pretty sure st.multiselect.spec.js is a flake since it failed on my other pull request.

After, removing all global pip packages, clean installing pyenv and python, then running/fixing brew doctor. Everything is installing correctly now and all tests run. I should be able to work through and fix everything now.

Something unrelated, I believe, I keep getting failure on the data-frame demo locally...

@akrolsmir All checks have now passed!

Hi @RedFrez Sorry for the delay! I took a look. Overall, this is positive addition, but I was concerned by the following:

• The column percentage lends to more opportunity for a rounding error. Testing it but if the calculation is 0.001 percentage off, it could break the flow of elements. I think that number is reasonable considering I am not imagining large numbers of columns and advanced calculations and general precision of decimals.
• Two different technologies using gap and padding-left seems complex. Left padding seems a little weird here already (I wish we could remove it), but I don't think it's a major concern, especially because of gap support.

Separately is use of gap property all together does not work in Safari for Flex Layouts. This should be addressed, but it would not change from the original implementation. I think an overall ideal solution in the future is to use CSS grid because it is much better supported than some grid features in flexbox. That being said, this may require a little retooling on how column information is sent down, which is an unnecessarily complex challenge.

I think overall it's still worth merging given above. Let me know if you have any thoughts.

Ah, great investigation, @kmcgrady ! Just some quick thoughts:

• I hadn't considered the rounding error issue before! It feels like floating point precision in Python shouldn't generally result in errors that large (ie this kind of error), so I'm tentatively not that worried, but I'm glad you brought it up.
• I do agree that the complexity is unfortunate. I believe @RedFrez did a great job of documenting the decisions behind this change on Github; could we also bring this context in the code, as a comment? I'd recommend either like a two-sentence summary of how the spacing is set, or linking back to this Github PR/issue

And the fact that gap is unsupported in Safari is actually quite annoying, and agreed that CSS grid may be a future ideal improvement. When I was first implementing this, I didn't have a particular principled reason behind choosing Flexbox over CSS Grid, and I'm happy to have that decision revisited!

Totally agreed that it's out of scope for this PR; and it's very much worth merging this improvement :)

This solution was what I determined would be the least change for accomplishing the current goal.

@kmcgrady I think it definitely would be better to have only gap or padding, but it would require for more information to be available for calculations. The potential break in flow could be accommodated by reducing the overall percentage a little bit which would have a little extra space available to grow into.

I wonder if Safari will end up following the path of IE… I did verify and the gap does not show up for flex.

From the aspect of use case, I do think Grid fits better since the content will never flow or wrap from one column to another. Grid could also provide opportunities for the future of adding rows to the columns that are aligned, versus having the create new columns.

The main downfall with Grid that I see, is that it requires extra work to make it flexible when the columns aren’t equal width. Also, it seems like the gap drives offsets with Grid regardless of if percentages or the fractional unit is used.

For either Grid or Flex, I think it would be helpful if the total qty of columns were passed to the styled component, as it would allow for calculation of padding that is needing to be adjusted for. I was trying to play with it some, but unfortunately I have limited Proto experience to be able to make any successful changes.

@akrolsmir I added a short comment for documentation to the Horizontal Block.

For this comment under StyledColumn:

    // The minimal viewport width used to determine the minimal
    // fixed column width while accounting for column proportions.
    // Randomly selected based on visual experimentation.

is it from old styling? Does it still apply or should it be removed?

Also, I don’t think the width property actually does anything with the current setup, and might be worth removing (after I re-verify it doesn’t actually affect anything if gone).

@RedFrez that comment for StyledColumn is based on the theme.breakpoints.columns. Essentially we change how columns work based on an arbitrary viewport (less ideal, but it works for now). Maybe the placement is unfortunate, but it's still applies.

Looking at this. I'm going to merge it in. Thank you for your help in this!