paddingStart
overrides paddingHorizontal
except when paddingStart
is 0
#815
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
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?
Consider these two examples that set
paddingHorizontal
andpaddingStart
:{ paddingHorizontal: 10, paddingStart: 3 }
. Computed layout:paddingStart: 3
{ paddingHorizontal: 10, paddingStart: 0 }
. Computed layout:paddingStart: 10
As you can see,
paddingStart
overridespaddingHorizontal
whenpaddingStart
is3
but not when it's0
.It looks like this code is responsible for the special behavior when
paddingStart
is 0 since it checkspaddingEdgeStart.getValue() > 0.0f
.Here's an example C program which illustrates this behavior:
When running this program with a
paddingStart
of0
, you'll see that the node's width is20
(paddingStart + paddingEnd = 10 + 10 = 20
). WhenpaddingStart
is3
, the node's width is13
(paddingStart + paddingEnd = 3 + 10 = 13
).It looks like
3a82d2b1a8 (diff-07b4949bf42749fde386e769ff08a124)
changed it from>=
to>
ingetLeadingPadding
. I suspect it was a mistake.getTrailingPadding
still uses>=
.Adam Comella
Microsoft Corp.