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
but we do not have
However, as Google’s Leland Richardson quickly pointed out:
the names “margin” and “padding” have alot of historical context influenced by other toolkits
Modifier.padding() might better have been called
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.dpmore 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
represents padding or margin (or neither) depends entirely on when and how it
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
as the name. However, even if Compose goes with the current
it is a matter of education to explain how that relates to similar concepts in
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.