Feature auto margin #357
Reference in New Issue
Block a user
No description provided.
Delete Branch "feature-auto-margin"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Even so I know there are some opinions against
margin: 0 auto
it's still part of the spec: https://www.w3.org/TR/css-flexbox-1/#auto-margins and pretty usefull if you have to position viajustify-content
.This PR adds an implementation for that.
It adds an additonal
YGUnitAuto
and margins gotYGNodeStyleSetMarginAuto
functions as well.@woehrl01 We don't aim to implement the full css spec. Could you add some examples of layouts which are made significantly easier / possible with margin auto support compared to implementing those layouts today?
@emilsjolander I didn't came across any layout yet, which wasn't able to implement with yoga today. But I had to add spacer views. I want to get rid of spacer views as much as I can and the last "thing" can be only solved with auto margins.
I'm totally aware that there is no need for the full css spec, but as auto margins are explicitly mentioned and described in flex-box I would still account it to the flex-box model layouting logic.
I would count needing spacer views as a limitation. Could you give some examples of where margin auto would remove the need for spacer views?
@emilsjolander Sure, see this simple JSFiddle.
It's pretty much any layout were you want to have elements on one side and some additonal on the other side e.g for menus.
I also use this e.g. for centered notification messages where I have additional text at the bottom (can be boiled down to the layout above but in column direction)
Thanks, that helps!
This should be a fix in a seperate pull request.
@@ -13,8 +13,10 @@ function toValueCpp(value) {
}
function toFunctionName(value) {
space before
else
space before
(
and after)
space before and after
else
We currently use
YGUndefined
to meanauto
forwidth
,height
, andflex-basis
. I'm concerned with this being confusing after this PR introduced an explicitauto
value for margin. If we introduce a specificauto
value then I think this should be respected for other properties as well.@emilsjolander I thought about this too, should I add/change those? I would handle undefined the same like auto would on those values, so this wouldn't brake existing users.
@woehrl01 I'm not sure about the best way to handle it, feel free to experiment. But yes, whatever we do we should not break existing usages.
@emilsjolander I changed
width
,height
andflex-basis
to haveauto
as default value. undefined on the setter is silently converted toauto
.@woehrl01 looks pretty good. I'll get back to you later this week regarding this.
I'm missing tests for auto margins with align stretch. The code seems to show that auto margins should override alignItems/alignself = stretch. We should test this.
For all your tests please
;
, even the last one.Also could you add language bindings for the new auto setters?
@@ -39,3 +39,70 @@
<div style="margin-bottom: 10px; flex-grow: 1;"></div>
add a similar test for row direction. Also please change name to something like
margin_auto_multiple_children
for a_row
and_column
suffix.I added most of the language bindings except objc and javascript. As I don't know objc good enough and for javascript I think it would be good to extend
entry-common
to also support"auto"
as an additional short cut (the tests are generated for this) but I'm not familiar enough with this change.Please have a look if I have missed something, as those language changes aren't tested. But most of the repetitive work should be done ;) which should get you started pretty quick.
@woehrl01 that's fine! I'll fix up javascript and objc when importing 👍 Thanks for this awesome addition 💯
@emilsjolander has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
@woehrl01 could you rebase this? Github says there are no conflicts but i'm having some issues importing it.
@emilsjolander merged the master for this and the other PR you didn't imported yet.
@emilsjolander has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
@woehrl01 Could you rebase this on top of master instead of merging master into this branch?
@emilsjolander I'll try my best, I'm more of a mercurial than a git user. 😊
@woehrl01 lol me to. Another option is to squash the commit and the push it, that should work as well when I import.
@emilsjolander has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
@emilsjolander let me know if it works, otherwise I'll squash them all. 💪
@woehrl01 it didn't work :/ can you try squashing?
@emilsjolander try this, please 🤘
@emilsjolander has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
@woehrl01 that worked! Thanks! sorry for the hassle.
@emilsjolander has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
@emilsjolander 👏 awesome! No worries, thanks to this I learned new things about git today 👍
I'm still working on this. It breaks some tests internally and I have a couple other things that are higher priority. hang tight 👍
@emilsjolander If there is anything were I can help you out. Let me know it! No rush 👍
@woehrl01 will do!
@emilsjolander I did a rebase and fixed the auto margin as some of the behaviour this implicitly used has changed, now its explicit.
@emilsjolander has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
Pull request closed