Open mildred opened 3 years ago
Unfortunately, using pseudo-classes is not an option, they are resolved at a totally different stage and changing that would be very problematic architecturally. @tabatkins or @emilio can elaborate.
(as a reminder, *-needs-resolution use is reserved for horizontal groups): [[ The Accessibility Group (APA) has raised, or is following this issue, and expects it to be resolved to their satisfaction before a transition. This label is added/applied only by the APA Group, and should only be removed by them. It may replace an a11y-tracker label. ]] https://w3c.github.io/issue-metadata.html
I have been searching through issues to get an idea in how css mixins could be implemented in a future CSS specification. The goal is to avoid having to add class names to elements from CSS frameworks, but instead use semantic selectors and assign a style for each element.
In short, replace a
danger
class that puts the element in red with a CSS mixin (whatever the syntax) that can pull the red color property from elsewhere. I have been looking in particular at the@apply
rule and I still have open questions about it in https://github.com/w3c/csswg-drafts/issues/532#issuecomment-744442925 and ideas in https://github.com/w3c/csswg-drafts/issues/5624#issuecomment-744469507If the idea is to keep the way CSS is structured right now, conditionals at the top level with
@supports
and@media
, selectors below and then properties, mixin matching could be done at the selector level using a pseudo-class. For example:This is pretty self-explaining, the mixin CSS property defines a list of words that can be then matched by the :mixin() pseudo-class.
I first imagined that any property could be matched and using custom properties to achieve similar result:
A problem with that is that the custom property is inherited by default and it would be logical for
:defines(--mixin-danger: on)
to match#my-error-message
and its descendants. For mixins to be usable we need to avoid matching descendants.