[Bug]: Spacing for Radio Buttons

[elnelson575]

Component

UI (ui.*)

Severity

P2 - Medium (workaround exists)

Shiny Version

current

Python Version

current

Minimal Reproducible Example

see basic component

Behavior

This looks bad, we should fix that spacing.

Error Messages (if any)

Environment

all

[elnelson575]

Root Cause

In shiny.scss (vendored from shiny-r), there is a rule designed for Bootstrap 3/4 that pulls the options group closer to the label:

```css
.shiny-input-checkboxgroup label ~ .shiny-options-group,
.shiny-input-radiogroup label ~ .shiny-options-group {
margin-top: -10px;
}
```

In Bootstrap 3/4, each `.radio`/`.checkbox` div had `margin-top: 10px`, so `-10px` on the options group compensated for that gap. In Bootstrap 5, those margins are gone, so `-10px` causes the options to overlap the label (the `.control-label` only has `margin-bottom: 0.125rem = 2px` in the shiny preset, leaving a net -8px).

bslib already tried to fix this

`bslib`'s `inst/bs3compat/_shiny_input.scss` has a BS5-specific corrective rule:

```scss
@if $bootstrap-version == 5 {
.shiny-input-checkboxgroup,
.shiny-input-radiogroup {
label ~ .shiny-options-group {
margin-top: calc(#{-($line-height-base - $form-check-input-width) * .5} - #{$input-btn-border-width});
}
}
}
```

But this rule has specificity `(0,2,1)` — the same as the `shiny.scss` rule. In py-shiny's compiled preset CSS, `shiny.scss` loads after bslib, so `-10px` overrides the `calc()` value.

Correct fix: bump specificity in bslib

If the bslib rule added `.shiny-input-container` (which is always present on these elements), its specificity would be `(0,3,1)` and it would win regardless of load order:

```scss
@if $bootstrap-version == 5 {
.shiny-input-container.shiny-input-checkboxgroup,
.shiny-input-container.shiny-input-radiogroup {
label ~ .shiny-options-group {
margin-top: calc(#{-($line-height-base - $form-check-input-width) * .5} - #{$input-btn-border-width});
}
}
}
```

This fix belongs in rstudio/bslib (inst/bs3compat/_shiny_input.scss). It would fix the issue for all bslib consumers. Note: it's unclear whether R's Shiny has the same visual bug depending on its HTML dependency load order — the specificity fix would resolve it definitively either way.

In the meantime, py-shiny can carry a local patch to the vendored `shiny.scss` until bslib is updated and pulled in via `make upgrade-html-deps`.