-
-
Notifications
You must be signed in to change notification settings - Fork 14
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
Problems with overwriting popover styling for Firefox #147
Comments
@keithamus or @mirisuzanne I'm curious if you have suggestions for how to approach this? Seems like from an API perspective we could expose an option to omit the polyfill styles, but maybe there's a better CSS approach to allow overrides. |
There are CSS-first approaches. The most relevant and simplest would be Cascade Layers. They're fairly new, but have good support for the last couple years. I'm not sure what our support matrix looks like here? The other CSS option is wrapping all provided styles in In either case, if there are overrides that should not be allowed, those properties can be marked as |
I’ll try a solution using As a workaround for now, @anna-lach, you could increase specificity by, for example, using |
Thank you @keithamus. I tried with |
@anna-lach This is released in v0.3.4. |
I'm working with Anna on this. I think this has something to do with the shadow DOM: no matter what selectors I add to the scoped styling within the custom element, I cannot get it to "overwrite" the @jgerigmeyer the So afaics the only way to work around this is to use To clarify, we are doing something like this: // Doesn't matter if how many selectors you add here, the polyfill styles will always have a higher specificity
:host([popover]) {
border: var(--_border);
} |
@jpzwarte are you using constructable stylesheets? If so, does your stylesheet appear before or after the popover stylesheet in the shadow root's |
@keithamus We use Lit, so yes. Afaics the polyfill stylesheet appears before the component stylesheet. |
Do all browsers behave the same? Is the variable for sure correct? If you add |
I think I know the issue. The popover style sheet is appended to the document, so that light DOM popovers work, but If you open this codepen you'll see a pink border. If you comment out line 19 ( I'm not sure what the resolution here is... |
I guess |
Yes, author styles in the light dom always override author styles in the shadow dom. The only way to override that is with |
I’m not sure we could do that as the styles are required for popover to work. The only other option I can think of is inline styles but then they’ll take precedence over stylesheets anyway 🤷♂️ |
That makes sense. It's too bad there's no way for polyfills to inject styles at the 'presentational hints' level of the cascade (between browser and author styles)… It would be a difficult pitch to the working group if that's the only use-case, but might have other use-cases, the more authors are relying on shadow DOM. Should a site should be able to apply global defaults that underly custom element defaults? Seems like people would put their resets into a layer like that. |
I have the same problem with Firefox 123, even without shadow dom. The only thing that worked was using !important. The :where() or @layer did not help. |
I’m currently working on a popover component and I’d like to overwrite some styling for the
[popover]
likeoverflow
to visible etc., but in the Firefox it doesn’t work. Since there are styles added in thepopover.ts
file in the polyfill it looks like I cannot overwrite those styles in my app. It seems those styles from polyfill'spopover.ts
file have the highest specificity.The text was updated successfully, but these errors were encountered: