-
Notifications
You must be signed in to change notification settings - Fork 65
breaking(layout_column_wrap): Make width an optional argument
#799
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
Conversation
avoid overflowing the parent container
Co-authored-by: Carson Sievert <[email protected]>
|
I'm on board with these changes, but I'd like to see this PR split into 2: one for the Also, feel free to use your own examples, but here is one that's fairly simple, but demonstrates the change in behavior for the 1st change: # Open me on a medium sized screen (i.e., between about 800-500px)
# and notice how the cards "bleed outside" of their containing column
my_card <- card(lorem::ipsum(2), max_height = 100)
page_fixed(
layout_column_wrap(
width = "800px",
class = "border border-danger",
!!!replicate(3, my_card, simplify = F)
)
) |
|
@cpsievert I spun out the initial, non-breaking change into #851 and I'll rebase and re-word this PR after we merge that PR. |
width an optional argument
|
Closing this PR in favor of a smaller, more targeted PR. |
Avoids items overflowing the parent layout container. With this rule,
widthbecomes the point at which a new column is created, i.e. ifwidth = "400px"then new columns are added to a row if there is at least 400px of space.Breaking: This PR also makes
widthan optional argument and moves it to after the.... A code search shows that most people name thewidthargument, but in case they haven't we'll test to see if the first argument tolayout_column_wrap()looks like a validwidthvalue (a single numeric value or a valid CSS unit) and we'll emit a deprecation warning and use that first value aswidth.Note: in the deprecation warning I'm assuming this breaking change will cause our next version to be v0.6.0 (in any case, we should review our deprecation warnings before the next release to make sure we have the right version in them).
Some code to try out this feature: