You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should add this to primer-base to better support custom elements, and potentially increase the selector specificity to override our d-* utility classes. This will encourage custom elements and JS behaviors to toggle visibility with the hidden attribute rather than toggling the d-none utility class.
As more custom elements are extracted from github.com and designed to function separately from Primer, and as we consider other environments (such as React), we might even discuss deprecating d-none entirely. 😬
Another way we could tackle this would be to change our d-* utility classes to, for instance:
.d-flex:not([hidden]) { display: flex; }
The problem I foresee is that if we put [hidden] { display: none !important; } in primer-base, it won't work as-is because the selectors have the same specificity. So if we're going to do this, the [hidden] rule will have to come after.d-* in the resulting CSS.
This actually begs the question: should we deprecate d-none in favor of hidden? That might be the best way to encourage good practice, and make it easier to move forward with a refactor like https://github.com/github/github/pull/88496.
We should add this to
primer-base
to better support custom elements, and potentially increase the selector specificity to override ourd-*
utility classes. This will encourage custom elements and JS behaviors to toggle visibility with thehidden
attribute rather than toggling thed-none
utility class.As more custom elements are extracted from github.com and designed to function separately from Primer, and as we consider other environments (such as React), we might even discuss deprecating
d-none
entirely. 😬/cc @muan
The text was updated successfully, but these errors were encountered: