You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I made a PR regarding bug #33530, as I was writing the fix to change the order of the compiled css, I realized there was another underlying issue that could be "corrected" and better documented / supported - specifically some of the inconsistencies that remain when actually using row-cols-* as outlined below. Wanted to see if this is headed in a good direction or would be with modification, and is something you'd entertain a PR for.
Problem:
row-cols-* override .col (and .col-auto) because - well, it does and existing documentation shows .col being specified on children of row-cols - however row-cols-* automatically applies column css to the direct children of the row. In effect, .col (and .col-auto) when nested in a .row-cols* does NOT override like the .col-n classes do and are unneeded when used under .row-cols-*. The existing PR intentionally leaves it alone however.
Solution?
The way I (could) see it, if you specify .col or .col-auto (or col-n or col-brekapoint-n) under a .row-cols-n row, it should also act as an override but currently doesn't. It would be more consistent with the idea that .row-cols-* is a default, but has a higher potential of being more of a breaking change because of the existing examples. The documentation should also be updated to indicate that all direct children of a .row-cols-* row automatically become columns (this is currently the case, but not obvious because of the documentation showing .col or a variant being used on each column even though they're overridden...)
Possible Pros / Cons
Pros of Updating:
Makes .row-cols completely consistent when children "override" the (default) row value (including col and col-auto)
Doesn't require changing any of the CSS, just the order emitted so things get overridden correctly.
Less (class styling) for developers that use .row-cols-n
<divclass="row-cols-2"><div>I'm 50% wide!</div><div>Look Ma, I've got no class!</div><divclass="col-12">I'm full width!</div></div>
Cons:
Existing examples become broken because col would actually override row-cols-n - could cause breakage in the field from copy/paste coding.
I'd be happy to work on this if it's a direction you'd like to go and update the examples as well.
And, again, thanks for all the great work in this project!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I made a PR regarding bug #33530, as I was writing the fix to change the order of the compiled css, I realized there was another underlying issue that could be "corrected" and better documented / supported - specifically some of the inconsistencies that remain when actually using
row-cols-*
as outlined below. Wanted to see if this is headed in a good direction or would be with modification, and is something you'd entertain a PR for.Problem:
row-cols-*
override .col (and .col-auto) because - well, it does and existing documentation shows .col being specified on children ofrow-cols
- howeverrow-cols-*
automatically applies column css to the direct children of the row. In effect,.col
(and.col-auto
) when nested in a.row-cols*
does NOT override like the.col-n
classes do and are unneeded when used under.row-cols-*
. The existing PR intentionally leaves it alone however.Solution?
The way I (could) see it, if you specify
.col
or.col-auto
(orcol-n
orcol-brekapoint-n
) under a.row-cols-n
row, it should also act as an override but currently doesn't. It would be more consistent with the idea that.row-cols-*
is a default, but has a higher potential of being more of a breaking change because of the existing examples. The documentation should also be updated to indicate that all direct children of a.row-cols-*
row automatically become columns (this is currently the case, but not obvious because of the documentation showing.col
or a variant being used on each column even though they're overridden...)Possible Pros / Cons
Pros of Updating:
.row-cols
completely consistent when children "override" the (default) row value (includingcol
andcol-auto
).row-cols-n
Cons:
col
would actually overriderow-cols-n
- could cause breakage in the field from copy/paste coding.I'd be happy to work on this if it's a direction you'd like to go and update the examples as well.
And, again, thanks for all the great work in this project!
Existing Documentation on Row-Cols
Beta Was this translation helpful? Give feedback.
All reactions