feat(fill): Use a @layer htmltools
#425
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR wraps the
fill.css
rules in a@layer htmltools
.In bslib we have the following CSS rule using the
.bslib-flow-mobile
class:This rule is intended to undo the
fill.css
rulebut it has a specificity problem where whether or not it is applied as expected depends on the order in which dependencies are loaded.
In fact, it appears that currently
.bslib-flow-mobile
is applied correctly in Shiny for Python and not in Shiny for R wherepage_fillable()
appears to be always filling on mobile with dev bslib (we started including the component CSS inbs_theme_dependency()
in rstudio/bslib#810).One obvious fix is to increase the specificity of the
.bslib-flow-mobile
rule (and we may still want to do this to avoid version coordination between bslib and htmltools).But we generally intend for
fill.css
to be applied at a lower level than other CSS rules. We've also talked about adopting CSS layers in our dependencies. Fortunately, we can start using a layer forfill.css
without having to completely work out how we'll use layers overall.I'm proposing we use the package name,
@layer htmltools
, for this layer, rather than trying to guess what functional-oriented name we might want in the long run (e.g.utilities
orlayout
, etc.). We also don't need to declare layer order elsewhere, simply using a layer is enough to at least reduce the importance of these rules. At some point we may decide to have bslib coordinate some of the layer ordering, but we don't need to do that now.