fix: Reorder bundle so bslib wins cascade ties against shiny.scss

[elnelson575]

Summary

Reorder layers in bs_full_theme() so R-shiny's shiny.scss emits before bslib in the compiled bootstrap.min.css. This matches the cascade order an R-shiny + bslib app sees (where shiny.css is added as its own <link> before bslib's bundle), and lets bslib andbs3compat rules win same-specificity ties against shiny.scss.

Solution

bs_bundle() requires theme first (its first argument is asserted to be a bs_theme), so drop down to sass::sass_bundle() directly and reapply the bs_theme class — exactly mirroring bs_bundle()'s implementation, just without the required order.

Shiny & bslib versions were pinned to their last vendored version for the purpose of making sure this diff is just changes from the order change, not any of the other bs5 changes that will be covered in later PRs or the shiny changes that will be covered in later PRs.

Visible effect

NOTE: These effects are intended!

Element	Before	After
Vertical ui.input_radio_buttons() / ui.input_checkbox_group() label-to-options gap	-10px (shiny.scss base)	calc(-.15em - var(--bs-border-width)) (bslib bs3compat, ~ -3.4px)
Inline radio/checkbox label-to-options gap	-1px (shiny.scss inline)	-1px (shiny.scss inline) — unchanged; bslib's bs3compat rule is at 0-2-1 specificity and still loses to shiny's 0-3-1 inline rule. Will flip too once rstudio/bslib#1308 (which lifts bslib's rule to 0-3-1 with a doubled-class compound) merges.

Why this works: cascade-order analysis

Click to expand

The bug

bslib bs3compat is meant to override R-shiny's shiny.scss for several Bootstrap 5 backward-compatibility cases. In py-shiny those overrides were losing same-specificity ties because the vendored bootstrap.min.css placed bslib's bs3compat before shiny.scss in the file — the opposite of an R-shiny + bslib app's head order.

Where the order came from

bs_full_theme() in scripts/_functions_sass.R called bs_bundle(theme, bslib = ..., shiny = ..., ...). bslib's bs3compat is baked into the theme argument, and bs_bundle() always stacks named layers on top of theme. So bs3compat's rules emitted first, shiny.scss later. Same-specificity ties went to shiny.scss by source order.

Byte-level confirmation

In the regenerated shiny/www/shared/bootstrap/bootstrap.min.css:

Rule	Before	After
shiny.scss -10px (.shiny-input-radiogroup label ~ .shiny-options-group)	byte 360,395	byte 5,138
shiny.scss -1px inline (.shiny-input-radiogroup.shiny-input-container-inline label ~ .shiny-options-group)	byte 360,546	byte 5,289
bslib bs3compat calc (.shiny-input-radiogroup label ~ .shiny-options-group)	byte 278,779	byte 286,617
File size	399,349 B	399,547 B (~200 B drift)

shiny.scss now sits before bslib in the file; bslib wins all same-specificity ties.

Collateral-damage audit

Only one selector pair has same-specificity + same-element overlap between bs3compat and shiny.scss in BS5 mode:

.shiny-input-{checkboxgroup,radiogroup} label ~ .shiny-options-group (0-2-1 in both).

• bs3compat sets margin-top: calc(-.15em - var(--bs-border-width)).
• shiny.scss base sets margin-top: -10px.
• Previously bslib emitted first → shiny won the tie → -10px.
• With the reorder, bslib emits last → bslib wins → calc.
• This is the only winner-flip.

Other classes that look shared but don't actually collide:

Class	shiny.scss usage	Conflict?
.checkbox, .radio	always under .qt5 or .qtmac (Qt browser scopes)	no — different selector
.well	only as .well .shiny-input-container (descendant)	no — different element
.active, .show, .in, .nav	substring matches only (e.g. &-active, comments)	no — false positives
.shiny-options-group	only as descendant of .shiny-input-{kind}	covered by the rule above

shiny.scss's .radio/.checkbox usages are all prefixed with .qt5/.qtmac (Shiny Server browser scopes — different element scope). bs3compat's .radio/.checkbox styling is wrapped in @if $bootstrap-version == 4 and doesn't compile for BS5.

Net effect: only the vertical radio/checkbox label-margin changes (and to the value bs3compat intended); no other styles are affected.

Relationship to other PRs

• Independent of chore: Upgrade bslib to 0.11.0 and Bootstrap to 5.3.8, add brite theme #2246 (the bslib 0.11 + Bootstrap 5.3.8 upgrade); both can land in either order. If this lands first, chore: Upgrade bslib to 0.11.0 and Bootstrap to 5.3.8, add brite theme #2246 should re-run make upgrade-html-deps to inherit the layer order.
• Inline radio/checkbox gap is unchanged in this PR. Once fix: elevate CSS specificity for BS5 radio/checkbox group label margin rstudio/bslib#1308 (doubled-class compound) merges and is pulled in by a subsequent make upgrade-html-deps, inline will also flip to the calc value. This will fix the original radio button spacing issue in [Bug]: Spacing for Radio Buttons #2236

Test plan

• Visual: vertical ui.input_radio_buttons() / ui.input_checkbox_group() use the calc gap (slightly tighter than the previous -10px)
• Visual: inline variants render unchanged
• No unrelated style regressions across themes (the collateral audit predicts none)

[gadenbuie]

LGTM! Thanks for digging so deeply into this one!