[v4] Why are all col classes 'position: relative'?

[liquidvisual]

Is there a reason for making all columns relative?

Typically I wrap my rows and cols inside 'sections' which have their own padding top and bottom. I sometimes choose to make elements inside those columns stick absolutely to the edges of the section. With cols as relative now, it's less trivial to do so.

Applying an override of..

[class*='col'] {
    position: static;
}

does the trick, and I can't seem to find any drawbacks. Although I'm wondering if there's a good reason for relative in the first place? Please correct me if I'm wrong or missing something.

Cheers!

[mdo]

Do you have a demo of the problem you're facing?

[liquidvisual]

It's not really a problem, it's just a question for the reasoning behind it. If it's to accompany a z-index elsewhere or squash some browser bug somewhere, I can understand why that would be relevant - but I'm trying to find why it's there and not static by default.

[liquidvisual]

I've put together a quick pen to show a use case. I generally expect my parent blocks and wrappers to have priority for positioning.

https://codepen.io/liquidvisual/pen/OzQYXe

[mdo]

Honestly can't recall—was hoping your live example would jog my memory :). Looking at v4's and v3's source code, it's there in both, but I'm unsure if I can track it fully in our history.

[mdo]

Welp, found it, but no answers: 0f17f9b. I imagine it's safe to remove? Dunno how many folks have built with it in mind already...

[liquidvisual]

Cheers for looking into that. Assuming it's safe, I'll apply the override in my own codebase then.

I'm trying to think of a scenario where someone might have used relative columns for something. Maybe in a case where they hacked a set of columns to have a certain height so they could do the same as my demo. Or they're doing something tricky with z-indexes..

That's all I can think of right now.

If it's not serving any purpose, having a blank positioning context for the columns would be beneficial I reckon.

[mdo]

If it's not serving any purpose, having a blank positioning context for the columns would be beneficial I reckon.

Agreed. I'll open a PR and start to get some feedback. Thanks for asking and for the example!

[mdo]

PR opened: #25255.

[asyncdesign]

If I'm not mistaken, position: relative was added to grid columns to facilitate absolute positioning of elements within columns. If the relative positioning is removed, then users would need a nested container with relative positioning to wrap elements using top, left, bottom, right, etc. and absolute positioning.

[mdo]

@asyncdesign Yup, I know how it could be used with that, but there's nothing in the history that shows this was intentional on my part.

If the relative positioning is removed, then users would need a nested container with relative positioning to wrap elements using top, left, bottom, right, etc. and absolute positioning.

It wouldn't require a nested container—it'd require folks to add it manually with custom CSS or our .position-relative utility. Not removing it means folks have to override our code.

[liquidvisual]

Any update on this?

[TeqGreg]

I too am having to override this, another use case we are experiencing is the use of a calendar picker within a column- in a form.
When these columns have overflow added, the absolute positioned calendar picker gets 'stuck' in the column since it moves to the closest relative parent, that of the column, rather than my intention within the form wrapper (so you don't have to scroll to fill out a popup modal within a column)

[perpetual-hydrofoil]

Somewhat related -- you can absolutely position to the bottom of a bootstrap column, but the column itself doesn't fill 100% vertical space; could probably resolve it with .flex-fill or .flex-grow-1 but you'd have to probably move away from .container / .row.

(see positioning of the two red divs):
https://codepen.io/anon/pen/NLdxeq

[mdo]

Checking in on this, the one holdup I have for it is that this breaks our custom form validation styles when using tooltips: http://getbootstrap.com/docs/4.1/components/forms/#tooltips. I think this might have to wait until v5 to avoid breaking things.

Thoughts @andresgalante?

[rmacklin]

Just discovered an ugly UI issue from this because positioned elements affect the stacking of elements. A recent change added a couple of col- elements which, when the page content was long enough, unintentionally stacked on top of another element that was supposed to be stacked above it. Glad to know there wasn't a specific reason for these to be position: relative so that we can safely override it in our application.

[gavin310]

Setting a column to relative positioning should be at the discretion of the developer. Having every column set to position: relative is counter to the purpose of relative positioning.

[mdo]

Yup, agreed.

We'll be dropping the relative from columns in v5, just need to make sure we're considering the change to other components as mentioned in my last comment. <3

[gavin310]

Yup, agreed.

We'll be dropping the relative from columns in v5, just need to make sure we're considering the change to other components as mentioned in my last comment. <3

Awesome! Good to hear.

[zebapy]

FWIW I figured the position: relative was set so the push/pull classes in v3 worked correctly.

[ffoodd]

@mdo Be aware that the .stretched-link utility documentation was mentionning that card component was using position: relative (at least in v4) so there is probably something to update if this is getting merged.

[tjbulick]

thank you all guys for this thread, i'm a happy user of v4 from 2022, and anyway overriding yours position: relative with my own the same one, knowing that yours was made on an intent of solving several local problems

p.s. looking forward to use v5