bug#46184: 28.0.50; child-frame-border-width of 0 falls back to internla-border-width

[martin rudalics <rudalics@gmx.at>]

 > I have tried the patch and the case for using 0 does work without
 > fallback now.
 >
 > I also tried setting an explicit `nil` value and got an error, but
 > judging by how `internal-border-width` shows the same behaviour I assume
 > that it's working as expected.

Indeed.  That's why I dislike frame parameters.  WOW users cannot set
'internal-border-width' back to its initial value once it changed.  For
scroll bars we use a two-tiers approach where users can tweak width and
type separately.  Doing something similar for the internal border seems
a bit excessive to me.

Though, I am currently investigating doing something similar for tooltip
frames.  IIRC it was you who also noticed that the border we currently
draw around them is only on top and the left.  I meanwhile found out
that this is due to us trying to use the 'border-width' of the frame (a
completely obscure X concept) for that purpose.  If I can't fix that
(and it would be an X-only fix anyway) I'll try to replace it with our
own internal border, but I'm not sure whether I succeed.

Currently, the internal border face, once customized, shows through in
our tooltips only after some delay which is quite irritating.  Also, I
still don't know whether we want the internal border of tooltip frames
as a means (1) to "set off" text from the rest of the screen by splicing
in some space in the background face, or (2) to "separate" text from the
rest of the screen by splicing in space in a face that differs from the
background.  Currently, we can't have both.  We'd have to brush up the
internal borders in way similar to window dividers.

Thanks for checking, martin