having place-self: flex-start; on buttons.css means it ignores align-items of a flex parent
andystevenson opened this issue · comments
I tried lining up a few buttons in a flex wrapper but the place-self: flex-start overrides a parent align-items. Perhaps the default would better be place-self: inherit; ?
yay, this is a great topic. are you able to share a small demo example? i'm pretttty sure i know what you mean, could i see it though?
the reasoning was so buttons were "shrink wrapped" by default, but you could stretch them into block items. you're saying tho it's unintuitive to directly target a child for alignment when the parent can supply it right? somethin like that? 🙂
Hi Adam,
I forked your Open Props Buttons on codepen and added a big circle SVG as the first item in the article.fluid-flex container. Even though the fluid-flex has place-content: center; the buttons don't line up with the center of the circle. I had to add a .fluid-flex > * { align-self: center; } to center the buttons. (I commented the align-self out in the CSS so you could see the issue straight away.)
https://codepen.io/andystevenson/pen/oNoYyOa
Not exactly sure what the fix is though.
I stuck an icon in a nav and had to dig to find out why align-items: center; had no effect on my buttons! Tripped me up for a while till I dug in and found the place-self: flex-start; in the buttons.css code.
yep this is tough, the default for a button in a flex container shouldnt be stretch.. but by undoing that i've made you have to reach onto a childs self alignment to get the job done. tldr; its supposed to be helpful but ends up getting in the way and you would have corrected it anyway.
Understood. Bit of a dilemma really, the default behaviour being stretch makes it a tricky balance. Maybe make the button internal layout a grid?
i tried all sorts of stuff, the closest to me thinking was ok was also a bizarre hack, and i just overall dont want these buttons to bring a style that has to be undone most the time. thanks! i think this is a nice refinement.
fixed in v1.3.4
Thanks Adam, the fix looks like a great compromise to me.