Fix button group stacking context

[evansjohnson]

Fixes #7440

Checklist

• [n/a] Includes tests
• [n/a] Update documentation

Changes proposed in this pull request:

Reset stacking context of button group component

Reviewers should focus on:

Could this unintentionally override any consumer land styling?

Screenshot

This PR ended up using the translateZ(0) method to reset the stacking context like we do for control groups but anything that resets the stacking context should be valid.

[changelog-app]

Generate changelog in packages/core/changelog/@unreleased

What do the change types mean?

• feature: A new feature of the service.
• improvement: An incremental improvement in the functionality or operation of the service.
• fix: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way.
• break: Has the potential to break consumers of this service's API, inclusive of both Palantir services
  and external consumers of the service's API (e.g. customer-written software or integrations).
• deprecation: Advertises the intention to remove service functionality without any change to the
  operation of the service itself.
• manualTask: Requires the possibility of manual intervention (running a script, eyeballing configuration,
  performing database surgery, ...) at the time of upgrade for it to succeed.
• migration: A fully automatic upgrade migration task with no engineer input required.

Note: only one type should be chosen.

How are new versions calculated?

• ❗The break and manual task changelog types will result in a major release!
• 🐛 The fix changelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease.
• ✨ All others will result in a minor version release.

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

Fix button group stacking context

Check the box to generate changelog(s)

• Generate changelog entry

[svc-palantir-github]

apply same fix as control group

Build artifact links for this commit: documentation | landing | table | demo

This is an automated comment from the deploy-preview CircleCI job.

[evansjohnson]

an LLM response when asking I need to reset a z-index stacking context in CSS, are there any performance considerations between z-index: 0 and transform: translateZ(0)? which would be more performant?

seeing this I'm tempted to say we should at least avoid introducing more translateZ(0), specifically for button groups which there may be a lot of rendered at once

we could separately consider switching the implementation to reset the control group stacking context but that has been in place for awhile

[svc-palantir-github]

lint?

Build artifact links for this commit: documentation | landing | table | demo

This is an automated comment from the deploy-preview CircleCI job.

[ggdouglas]

The button group is positioned static by default, so should we also provide a position: relative here? Otherwise, in a vacuum, this z-index won't have an effect:

---

If the button group is a child element of a flexbox parent, however, it does apply. I'm a little fuzzy on the spec here, but I believe this has something to do with flex item z-ordering.

Here's a quick comparison: https://codesandbox.io/p/sandbox/q4v2ch

[evansjohnson]

oh great catch here!

is the assumption that this is safe to do because consumers that rely on the current static position should not have set something like left: 100px since it would not make any impact with the current static position unless they have already specified an explicit position?

also wondering if somehow BP classes are weaker selectors than user styles - ex could this wipe out a user defined position: absolute

---

I hadn't heard of it but from looking at the MDN stacking context docs isolation: isolate seems like exactly what we want - any thoughts on that?

[evansjohnson]

it appears to work from the docs test

[ggdouglas]

also wondering if somehow BP classes are weaker selectors than user styles - ex could this wipe out a user defined position: absolute

Hm, I'm not as worried about this since we're fixing an existing buggy behavior in the process, but it is a fair point.

I hadn't heard of it but from looking at the MDN stacking context docs isolation: isolate seems like exactly what we want - any thoughts on that?

I've only ever used isolation for purposes related to isolating elements from mix-blend-mode, but I don't see why we couldn't use it for z-index also. I suppose, as you've said, the benefit here is that there is much less chance of inadvertently overriding user styles. I'm on board with that! Suggest also adding an explainer comment to clarify intent.

[evansjohnson]

I suppose we already do it for control groups but any concerns about suddenly creating a new stacking context (which I believe creates a new render layer) suddenly introducing perf issues if many button groups are used?

I think isolating the stacking context is needed in some way unless BP takes a global approach to z-indexes, but it might be safer to do in a major version with an opt-out available to avoid creating a stacking context. I don't have a gauge on if it could become an issue at 100 or 10k or if this isn't a concern at all really.