-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Shady styling increases selector specificity #1279
Comments
I'm disinclined to try to address this since we're not really planning to If there's something simple we can do here, it's definitely on the table. On Tue, Mar 10, 2015 at 11:37 AM, Ross Allen [email protected]
|
That's fine, but in the meantime what do we do? |
In the meantime, I propose we do what we can in the short-term, e.g. the On Tue, Mar 10, 2015 at 11:52 AM, Ross Allen [email protected]
|
Just to be clear, cross-scope styling this should only be done via ::content, ::shadow, or /deep/, otherwise it won't function correctly under ShadowDOM. |
Ordering the styles as I suggested above obviously doesn't help for this particular case. I'm going to do it anyway as it's more correct. We could auto-adjust the styling to do this:
That would solve the problem for ::shadow and /deep/, but for ::content, it would fail to cover elements not inside a scope, which leads to something like this:
Need to consider if it is reasonable to do this or not. In the meantime, you can manually adjust the style as above. It would be helpful to know how often this is coming up and/or if there are worse cases. Thanks! |
Closing this since the cross-scope selectors |
When inspecting an element's styles to alter externally, the selectors are less specific than they will actually be in the browser. It's not obvious this will happen, and it makes styles more difficult to override. In
core-header-panel
for example:Specificity 110:
becomes specificity 121:
When looking at the file it seems reasonable to override the first style with a selector of matching specificity like:
Specificity 111:
but that will not override the generated selector regardless of placement of the styles because the generated selector is more specific. The dev has to add unexpected specificity to his or her selector in order to override the generated one.
The text was updated successfully, but these errors were encountered: