I don’t make questions here for a while, then sorry if this is a FAQ, but here it goes… Why margin is not a modifier like padding is? 🤔

realistically, “padding” is actually just “spacing”

goodness, is that an understatement 😅

for instance, margins often don’t add together when being layed out, and paddings do (ie, two boxes with margins next to each other have spacing between eachother of max(margin1, margin2) )

yeah we did call it spacing for a while, but the idea that spacing surrounds a thing on all sides was bizarre in practice, and it was confusing when placed next to the

Spacer

element

the 10.dp is closest to the web’s “margin”, and the 20.dp is closest to the web’s “padding”

well, android's margin anyway, since it doesn't collapse with adjacent element margins

right

padding is at least consistent with flutter's use of the term here as well, so there's that

thanks for the explanation… well… I’m not sure if it is because I’m working with Android since the beginning, but this is a clear concept to me: margin = it’s the outer space and does not change the component size padding = it’s the inner spacing and it changes the component size

yeah but with those definitions then none of these are correct 🙂

well, sort of. Padding is correct with that definition

depends what you think of as “component size”

Padding does change the component size as far as the containing layout or modifiers that come before it are concerned

the problem is “component size” is an ambiguous term

or at least document it. 😄 I feel like we do have solid definitions for these things that are very consistent throughout the system, but it's easy to bring assumptions in that do not match how the system works.

btw… Flutter uses both: margin and padding which is more clear (for me at least)

When i use: Modifier.padding(10.dp) I’m not really modifying the size of a thing that existed before, i’m creating a new layer/element of the tree of things that is broadcasting its size as 10.dp more than what was below it

@nglauber well, sort of 🙂 https://stackoverflow.com/questions/50162294/how-do-i-add-margins-to-my-widget-understanding-the-effect-of-edgeinsets - it's all

Padding

eventually over there

I feel like we do have solid definitions for these things

If we do, I have not seen them. I think most of us understand how the system works, but we haven’t solidifed names for what the conceptual “box” of a modifier in a modifier chain is, and what the thing to the “right” and “left” of it is referred to. Most of the terms we use end up having ambiguities but we sludge through it because we can glean just enough based on context of what the person is talking about

the most precise usage we have in implementation anyway is the

Measurable

that gets measured with given constraints, and the resulting

Placeable

, which has a defined width/height.

@Adam Powell thanks for the link. But as client of the library I’m not so interested on its internals and definitions (even it’s important to understand it). What I mean is that the terms margin and padding in Android are being used since the beginning, and these properties also exist in flutter. Looks strange to me don’t have them in Compose… 🤷‍♂️

so you want to have Modifier .margin(10.dp) .border(Color.Black) .padding(20.dp) ?

yep!

In designing the APIs of compose, building upon previous conventions and understandings of Android is of course something we want to consider. But we have to be careful about over-valuing this when we are talking about building something for the next 10+ years. If we preserve the padding/margin names, but they do nothing but provide space, even though the top example reads more familiar since the margin is on the outside, it allows for really confusing situations like the 2nd example where margin is on the inside. And the problem is that margin in this case would mean nothing more than “space, right here”. Thus, we would actually be adding 10.dp of what you previously considered “padding”. This is confusing. We ended up settling for a middle ground which is that padding is familiar, but margin doesn’t exist so there isn’t a conflict. That may or may not have been the right choice, but it seems better than having a margin API that is just an alias to padding

an alternative approach in this case would be if the containing layout scope included a

LayoutParams

-style

margin

paralleling how it works in android today

with Modifiers is that the order matters

but that adds an awful lot of complexity and expectation of features of layout composables for not a ton of benefit unless we also supported collapsing margins as a part of that

right

what about them, more specifically?

i’d rather not add more to these

after working with all of the issues of LayoutParams for years I've found it to be a pretty elegant solution to that particular shape of problem

(my dog is gonna eat me if i don’t walk him RIGHT NOW, so i am gonna be back in a bit)

This is a really interesting topic. But I think I got @nglauber's point. Would be much simpler a migration from a xml world to the compose. And I think this is important because if we want to decrease the learning curve and bring more developers to the "Compose way" and should give kinda more similarities with the classic.

(trying to put lunch together over here too) I agree, it is constraining in that you can only do some things in particular layouts, and it is "fragile" in that it implies additional dependencies if you refactor/extract some chunks of code that makes use of it. But it's also honest - it reflects the constraints and requirements accurately. No one is going to paste some code that applies

android:layout_weight

to a child into a parent context that doesn't support that without having some hints from the compiler that something is up. And supporting something like collapsing margins is something a parent layout really does need to be involved in.

Yeah, it makes total sense

I fully support @Leland Richardson [G]. The Compose is designed to give us developers a whole new experience in developing UIs. It should fix all the bad design decisions of the previous UI framework. And the

LayoutParams

is just one such examples. The similarity to the previous framework is an important thing, but not the main one. If we will pull the same bad architecture design decisions, then what's the point? More bold decisions need to be made. When you work with one technology for a long time, the eye is blurred. And it’s already difficult to understand a good design or not when you don’t see anything better. I am sure the Compose team will do everything in the best way and given us the community a chance to help in this.

To be fair though, I think margin as a concept is separate from layout params’ implementation and I don’t think that the concept of margin is a bad one. The problem is that there were a lot of other factors that led us to the modifiers design and the end result is that the only difference between margin and padding in the modifiers world is when you call it. I make no claims to this being better or good, just that it is that way. The question then becomes if we are in that world (and we are convinced that modifiers is a good design for other reasons, which we are), then do we do anything to help map developers notions of padding/margin onto the current paradigm. 1. Having neither and just having “spacing” would mean we aren’t helping at all, but we are also making it more clear that the concept is more general 2. Having “padding” is helping somewhat, but then makes it feel like “margin” is missing. 3. Having both “padding” and “margin” gives developers two APIs to map it to, but it leads them into a trap of thinking that they work differently and then they miss the fact that the order is the actual thing that matters.

I really appreciate your comments here. Now I understand that order of calls for the

Modifier

matters and just the

padding

function works for both purposes. Thanks @Leland Richardson [G] and @Adam Powell for you attention. 👍

@Leland Richardson [G] I believe that we should use the term "spacing" alone or preserve the concept of "padding" & "margin" together and make it work accordingly. In a different thread you said

"[...] I find that most people will just write the code that feels the most natural and its "good enough" most of the time. We want Compose to be the same way. [...]".

Even though with "good enough" you meant performance, I think that in general Compose is the way to make writing UI as much a natural process as it can be. And margins are ingrained in developers' minds, not only on Android, so when we have only padding, something will always be missing. I feel that it's easier to think about either just spacing or margins + padding.

What's the Compose equivalent of CSS' box model? If not, how would you describe it? https://www.w3.org/TR/CSS2/box.html https://en.m.wikipedia.org/wiki/CSS_box_model

You don't need to wrap it in a Box, just use the modifier on the element you want the padding around. 🙂

Thanks Adam for sharing this! I am now confident that I don't have to wrap content in a Box in order to apply margins. This is how I can emulate CSS box model now

@Composable
fun BoxModel() {
    Box(
        modifier = Modifier // applies from outside (left) to inside (right)
            .size(100.dp)
            .drawBackground(Color.Red).padding(4.dp)   // margin
            .drawBorder(1.dp, Color.Black)             // border
            .drawBackground(Color.Green).padding(8.dp) // padding
    ) {
        Box(modifier = Modifier.drawBackground(Color.Blue).fillMaxSize())
    }
}

Yep, you've got the idea. And you can probably see where you don't even need the outer

Box

there at all, you could just as easily stick this one modifier chain on a

Spacer

,

Text

,

Button

or any other content element itself rather than wrapping it in a container only meant to hold the modifiers

For the sake of consistency, I think ConstraintLayout api’s should also use padding instead of margin which they currently use https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:ui/ui-layout/src/androidMain/kotlin/androidx/ui/layout/ConstraintLayout.kt;l=692?q=linkTo&ss=androidx%2Fplatform%2Fframeworks%2Fsupport:ui%2F

I'm not so sure. ConstraintLayout's use of margin seems consistent with margin being a property of the parent configuration and padding being a property of the child independent of parent configuration

interesting…need to still wrap my head around what you just said. I did like the generalization of padding irrespective of how you use it in the chain. At the end of the day, it’s just space and so it should not matter if the parent is adding that space or the child, because the order of the padding would have the effect you desire. Feels like an implementation detail led to it being called margin but I’m going to think a bit more about this.