One Off the Slack: A Space By Any Other Name...

Nelson Glauber asked what might have been thought of as a simple question:

Why margin is not a modifier like padding is?

My personal interpretation of the question is: why do we have Modifier.padding(), but we do not have Modifier.margin()?

However, as Google’s Leland Richardson quickly pointed out:

the names “margin” and “padding” have alot of historical context influenced by other toolkits

Strictly speaking, Modifier.padding() might better have been called Modifier.spacing(), but they were concerned that nobody would be looking for “spacing” as a term.

Part of the difficulty is that “padding” and “margin”, as they are used, are properties of something (I’ll use the term “widget” here). Modifiers are not properties. Or, as Leland put it:

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

Google’s Adam Powell elaborated later in the thread:

The model is: composable UI elements are responsible for their own content and that content may not be inspected or manipulated by a parent unless that element’s author exposes an explicit API to do so. Modifiers of an element decorate the element they modify in the same opaque way. Modifiers are encapsulated; a layout modifier that comes before another measures and places the element and all of its later modifiers as one unit, unaware of the specifics. The “box model” is defined by how you choose to order the relevant modifiers.

The concern of some is transference of knowledge. Or, as Henrique Horbovyi put it:

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.

Adam offered a counterpoint:

we’ve definitely made a lot of design decisions to keep things as familiar as we can, but we have to balance that with not carrying forward the deeply troublesome bits (or trappings that necessarily imply deeply troublesome bits) about android view layout and xml just for the sake of familiarity too.

Google specifically did not think in terms of the padding-vs.-margins distinctions used in other UI toolkits. Instead, the Modifier system relies on the order how things get applied, so whether any given Modifier.padding() visually represents padding or margin (or neither) depends entirely on when and how it is used.

That led to Daniel Gom to argue that if Modifier.padding() really is not padding, then it should not be named as such:

I believe that we should use the term “spacing” alone or preserve the concept of “padding” & “margin” together and make it work accordingly. …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.

I cannot argue with Daniel’s point, and I would probably lean towards spacing() as the name. However, even if Compose goes with the current padding() name, it is a matter of education to explain how that relates to similar concepts in Android’s View system or other UI toolkits. There will need to be lot of that sort of education, so needing it for yet one more topic does not worry me very much.

---

Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!