I think it could also be useful to have utilities for having a specific margin value that also takes into account the safe area. I've decided to leave those out of this MR though because of the additional complexity.

For example, you ml-4-safe could produce three different CSS outputs depending on the approach you wanted.

In order of what I think makes sense:

.ml-4-safe {
     margin-left: calc(env(safe-area-inset-left) + 1rem)
}

or

.ml-4-safe {
     margin-left: max(env(safe-area-inset-left), 1rem)
}

or (can't personally see a use case for this one but I might be missing something)

.ml-4-safe {
     margin-left: min(env(safe-area-inset-left), 1rem)
}

If this is wanted to be added, it's potentially worth having a utility like ml-4-safe be adding them, and ml-max-4-safe be max of the two values?

Hey thanks for this! I am not totally sure on the absolute best way to handle this — I don't think creating all new core plugins for just these values is the way to go though.

It's tricky though as I suspect you discovered because we don't really have a mechanism for allowing a single key (like safe) to mean a different thing for ml-* as it does for mr-* — every key has to mean the same thing for the whole plugin.

My gut is that a more powerful/flexible solution here is to create four new values that would be part of the config. In user-land it would look like this:

module.exports = {
  theme: {
    extend: {
      margin: {
        'safe-top': 'env(safe-area-inset-top)',
        'safe-right': 'env(safe-area-inset-right)',
        'safe-bottom': 'env(safe-area-inset-bottom)',
        'safe-left': 'env(safe-area-inset-left)',
      }
    }
  }
}

It's not quite as short or clean since you'd need to say ml-safe-left mr-safe-right instead of just mx-safe, but would give you more power since if you ever wanted to create an element with a width that matched the safe area to absolute position it in some way for example you could do w-safe-left or w-safe-bottom and have full control.

I'm still not 100% sure that's the absolute best approach either so even if we explore a new PR for that I think we will still have to think it through, but I'm going to close this PR as I don't think this is the approach I would like to use in core.

Totally feel free to open another PR based on my comments here if you like though 👍 And thanks as always for the contribution, appreciate it even if it's not being merged in ❤️