but 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 where page_fillable() appears to be always filling on mobile with dev bslib (we started including the component CSS in bs_theme_dependency() in https://github.com/rstudio/bslib/pull/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 for fill.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 or layout, 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.
This PR wraps the
fill.cssrules in a@layer htmltools.In bslib we have the following CSS rule using the
.bslib-flow-mobileclass:This rule is intended to undo the
fill.cssrulebut 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-mobileis 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 https://github.com/rstudio/bslib/pull/810).One obvious fix is to increase the specificity of the
.bslib-flow-mobilerule (and we may still want to do this to avoid version coordination between bslib and htmltools).But we generally intend for
fill.cssto 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.csswithout 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.utilitiesorlayout, 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.