bug#45620: 28.0.50; Child frames should have their own border width and colour

[Alexander Miller]

> Isn't the situation even worse than how you describe it here? When I
> customize 'internal-border' face, that affects all frames, including
> those for which I have set it already via 'set-face-background'. Which
> means that whatever a package does to set that face for a specific
> (child) frame, that setting is undone by a later customization. IIUC
> the discussion you refer to above arrived at the same conclusion.

What customisations are you referring to? I cannot think of any
scenario, other than changing and reloading your theme, that could
change the settings of already present child frames.

> If I'm not mistaken we use that face for our tooltip frames too which
> means one more conflict.

Partially. On my system the internal-border colour and width only
applied to the top and left sides of the tooltip frame.

> "clearly" is clearly too strong here. Ultimately, the package must have
> the choice and its choice should prevail (it currently doesn't).

Packages do have the choice, they just have to make sure to override the
frame-local faces whenever they show something. The problem, as I see
it, is that they *have to* create a face to override the local
internal-border, instead of just having the option to do it, because
themes cannot offer a general setting, like an easily visible dark
border on a bright foreground, because they run into the frame margin
colour conflict like modus did in the linked issue. So if a package
doesn't overwrite the local internal-border your default look-and-feel
is a badly visible same-colour-on-same-colour popup.

> So what should we do? Provide a separate 'child-frame-internal-border'
> face and then probably also a 'tooltip-internal-border-face'?

That would be perfectly good enough for themes like modus, yes.