Skip to content
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

Closed
ssorallen opened this issue Mar 10, 2015 · 6 comments
Closed

Shady styling increases selector specificity #1279

ssorallen opened this issue Mar 10, 2015 · 6 comments
Assignees
Labels

Comments

@ssorallen
Copy link
Contributor

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:

:host([mode=cover]) #mainContainer { ... }

becomes specificity 121:

core-header-panel[mode=cover] #mainContainer[style-scope=core-header-panel] { ... }

When looking at the file it seems reasonable to override the first style with a selector of matching specificity like:

Specificity 111:

core-header-panel[mode=cover]::shadow #mainContainer { ... }

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.

@sorvell
Copy link
Contributor

sorvell commented Mar 10, 2015

I'm disinclined to try to address this since we're not really planning to
have first class support for ShadowDOM's scope-crossing selectors
::shadow and /deep/. Instead we'll have a x-scope styling solution that
is based on a shim of custom properties.

If there's something simple we can do here, it's definitely on the table.
We can relatively easily influence the order of shimmed stylesheets in the
document. Perhaps making element stylesheets apply in order of registration
would be helpful.

On Tue, Mar 10, 2015 at 11:37 AM, Ross Allen notifications@github.com
wrote:

Assigned #1279 #1279 to
@sorvell https://github.com/sorvell.


Reply to this email directly or view it on GitHub
#1279 (comment).

@ssorallen
Copy link
Contributor Author

That's fine, but in the meantime what do we do?

@sorvell
Copy link
Contributor

sorvell commented Mar 10, 2015

In the meantime, I propose we do what we can in the short-term, e.g. the
change proposed above, but if necessary we write the selectors as necessary
to make them work.

On Tue, Mar 10, 2015 at 11:52 AM, Ross Allen notifications@github.com
wrote:

That's fine, but in the meantime what do we do?


Reply to this email directly or view it on GitHub
#1279 (comment).

@sorvell
Copy link
Contributor

sorvell commented Mar 11, 2015

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.

@sorvell
Copy link
Contributor

sorvell commented Mar 11, 2015

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:

core-header-panel[mode=cover] #mainContainer[style-scope] { ... }

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:

core-header-panel[mode=cover] #mainContainer, core-header-panel[mode=cover] #mainContainer[style-scope] { ... }

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!

@sorvell
Copy link
Contributor

sorvell commented May 22, 2015

Closing this since the cross-scope selectors ::shadow and /deep/ are being removed from the ShadowDOM spec. In addition, Polymer's cross scope custom property inspired style support is available as of version 0.9

@sorvell sorvell closed this as completed May 22, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants