New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-mixins] Proposal: @like
rule for repurposing page default styles
#10222
Comments
Some potentially related past discussions... At least linking them incase folks who were watching them are interested. #2296 |
See also: #10094 (not exactly the same thing, but has some overlap and is similarly interesting for shadow dom) |
Thanks @bkardell and @mayank99 for the effort to spot related discussions! Comments:
|
Just double-checking my understanding here - it seems that this isn't similar to |
Possibly? I’m not sure what are the specifics of how
|
Sure, those are all important open questions for anything like this. Besides those, tho, I was just checking my understanding that it's otherwise identical, and not subtly different in a way that I was missing in my first read. |
Background & Problem statement
One of the most common issues with web components is that they need to adopt the page’s existing generic styles, but can't. E.g.
<foo-button>
cannot adopt button styling unless the author duplicates button styling explicitly for it, making it hard to experiment with different components and making authors gravitate towards monolithic component libraries where they only need to define styles once.Even outside of web components, it’s common to want to cross-reference or extend styles, e.g.
<a class="button">
is a very common pattern withbutton
being in the top 5 of most common class names on the Web.Even in terms of architecture, defining default styles and then styling other structures by being able to reference these default styles would be a big win.
Mixins somewhat mitigate but do not completely solve this problem, as they require a shared contract between the page author and the author pulling in those styles (which may be separate entities). E.g. components cannot trust that a certain mixin has been defined on the page, and even if they could, it's tedious for the page author to define new mixins every time they want to try out a new component (not to mention that as mixins are currently envisioned this would require a lot of code duplication).
@like
is a way to target and "adopt" a set of existing CSS rules, without requiring a two-way contract. It can work with any existing stylesheet. The concept is not new, and is very similar to Sass'@extend
. Past proposals include:In this proposal I've tried to define something more concrete, and cut scope enough to avoid some of the hairiest issues while still satisfying the most prominent use cases.
The
@like
ruleI’m envisioning a rule that would match certain rules (excluding the current rule) based on its argument and pull in their styles after applying the cascade. The target rule (the rule that contains the
@like
) would be excluded from the matching.This may seem like too much magic, but below I discuss ways to scope it down, and make it more concrete and more implementable. However, no amount of scoping will make this a low-effort feature, the argument is just that it's also a high reward feature: done well this has the potential to solve a multitude of very prominent author pain points.
Meta-selectors
The argument to
@like
is not a selector, but a meta-selector: a way to describe a family of selectors. Meta-selectors match any selector that consists of the same criteria regardless of specificity (and in some cases looser criteria, see below). For example, abutton
meta-selector does not just matchbutton
, but also:is(button)
,:where(button)
and so on.For implementation complexity to be manageable, meta-selectors need to start from a very restricted set of criteria. The MVP could perhaps be a single compound selector, including:
:hover
etc)input[type=number]
). (substring matching makes it harder to determine equivalence and most use cases don't need it):not()
with a list of compound selectors matching the above (e.g.input:not([type])
)::placeholder
?It will probably take a fair bit of work to define which selectors a meta-selector corresponds to, but some initial thoughts are:
.foo.bar
=.bar.foo
).foo.foo
=.foo
):is()
and:where()
is ignored (except for grouping), e.g.:is(foo)
=:where(foo)
=foo
:not()
is ignored, e.g.:not(:not(foo))
=foo
What exactly is imported?
Narrower selectors?
As currently defined, adopting button styles by
my-button
is still fairly intensive:And even after all this, we may end up with subtly different styles if we happened to use a different order of pseudo-classes than the page author.
An alternative design would be to also identify more narrow selectors that match the meta-selector and pull them in automatically.
This means that this:
Would also automatically style
my-button:hover
likebutton:hover
, but alsomy-button.success
likebutton.success
.For certain things it may not even make sense, e.g.
my-input { @like input; }
would also adoptinput[type=number]
asmy-input[type=number]
, butmy-input
may not even have atype
attribute (or it may have one with different semantics.Overall, this means less control for the component author, but more robust styles in the general case.
A hybrid approach could only port action pseudo-classes, which seem to always be desirable, and anything else needs to be adopted manually. Or for the author to explicitly declare which states to adopt, and then they are automatically adopted in the right order.
Broader selectors?
It gets worse when we add multiple criteria:
For author intent to work, we want to adopt both
input
andinput[type-text]
, but we also want to preserve their relative specificity. Which brings us to…Relationship to the cascade
There are two conflicting goals here:
Also, given that a single rule can have multiple
@like
rules, it becomes especially important that conflicts are resolved in a predictable way.One realization is that specificity in the adopted rules is useful to resolve conflicts between the adopted rules, but is not relevant in resolving conflicts between our
@like
-using rule and the rules it’s adopting from. E.g. in the example above, it would be a mistake ifinput[type=text]
had higher specificity than the declarations withinmy-input
.Some ideas:
button:hover
should probably still have higher specificity than the basemy-button
rule (but lower thanmy-button:hover
). In the manual model where all pseudos are adopted separately and@like
basically adopts a computed list of declarations this is addressed by natural specificity.&
, i.e. assuming this page style:this rule:
becomes:
Scoping
It is important that scoping is preserved: if the page includes special styles for e.g.
.foo button
then we want our.button
to behave the same within.foo
. Perhaps it would make sense if any selectors containing a compound selector that matches our meta-selector were also pulled in and rewritten accordingly:becomes:
@scope
too:becomes:
Cycles
Cycle detection would be necessary to avoid cycles like:
In this case,
@like
would get ignored in all affected rules.Behavior in Shadow DOM
It seems reasonable that by default the meta-selector would be tree-scoped.
However, a huge use case is shadow DOM elements adopting default styles from the light DOM, even elements of the same type (e.g. style a shadow DOM
<button>
the same as a light DOM<button>
in the same place).There is currently a lot of discussion around this in WICG/webcomponents#909 , but the concept of meta-selectors seems quite useful here too. Perhaps there could be a parameter of
@like
to basically say "adopt styles from the parent tree" or "adopt trees from all parent trees". This would allow the kind of granular filtering that use cases need, without the additional burden of wrapping rules in@sheet
that still requires the page author to do work to integrate a component.One tricky bit around this is that in regular
@like
, meta-selectors only need to match selectors with the same criteria. Looser criteria are already applying. E.g. in something like this:we don’t need to pull in the
*
rule, because it already matchesmy-textarea
. However, if adopting styles from an ancestor tree, the meta-selector needs to also match and pull in looser selectors.v2+: Additional criteria
Post-MVP, the syntax could be extended to introduce filters on what types of rules or declarations are pulled in.
This could be:
Despite its length, this is still extremely handwavy, but it should hopefully be enough to start the discussion and see if something like this could possibly be implementable in some way, shape, or form.
The text was updated successfully, but these errors were encountered: