Skip to content
This repository has been archived by the owner on Sep 14, 2021. It is now read-only.

Support for :host-context()? #74

Closed
darrylyeo opened this issue Mar 16, 2017 · 5 comments
Closed

Support for :host-context()? #74

darrylyeo opened this issue Mar 16, 2017 · 5 comments
Assignees
Projects

Comments

@darrylyeo
Copy link

darrylyeo commented Mar 16, 2017

Right now :host-context() is left untouched. Supporting this is crucial if we want our elements to be context-aware.

I think for most cases, it's as simple as replacing it with the contents of the parentheses and appending x-element.

So:
:host-context(.foo).foo x-element
:host-context(.foo):hover .bar.foo x-element:hover .bar

@darrylyeo
Copy link
Author

Upon closer look it seems to be much more complicated than that. We'd run into specificity issues pretty fast.

Nonetheless, I'd love if someone could figure this out and have the functionality added soon.

@dfreedm
Copy link
Contributor

dfreedm commented Apr 4, 2017

This selector is not going to be implemented by Apple, so I'm not really inclined to support it in the transformer.

@turboki
Copy link

turboki commented Dec 22, 2017

So, ShadowDOM and context styling are still totally up in the air across the browsers, so I get not wanting to support Chromes pseudo selector, however today we still have a great need to be able to style internal elements based of external context.

for a contrived example

<el-modal class="modal">
    <el-header class="header">
         <el-title class="title">
            <span class="important">Title</span>
        </el-title>
    </el-header>
</el-modal>
// el-title style
.important {
    color:red;
}

// works in chrome
.important:host-context(.modal) {
    background: red;   
    color: white;
}

in that example, my title element has one style defined for generic use and another style defined when its used inside of a modal, but because :host-context is not supported by shady, I have to rely on other ways of passing in this context.

In normal DOM, it wouldn't be the title element dictating this, but its parent, so .modal el-title .important however this kind of selector can't be written today because ShadyCSS will append the element name as class name to all selectors.

So if I did this:

// el-title style
.important {...}

// works in chrome
.important:host-context(.modal) {...}

.modal .important {...}

I will end up with

// el-title style
.el-title.important {...}

// works in chrome
.el-title.important:host-context(.modal) {...}

// scoping screws up the .modal selector
.el-title.modal .el-title.important {...}

I can't move those styles to the parent either, because that scoping then screws up the child selector:

// scoping screws up the .important selector
.el-modal.modal .el-modal.important {...}

What if we add a way in ShadyCSS to prevent scoping any parent above a manually defined element selector?

// I write a selector like inside of el-title
.modal el-title .important {...}

// ShadyCSS transpiles only the right side of the selector:
.modal .el-title.important {...}

If we could do that, we would have the ability to pierce the fake shadowDom and still style the inner components, while still defining those rules within the shadowDom of the custom element.

@azakus what do you think?

@brianchung808
Copy link

@azakus any update on this issue? Running into the same problems and #74 (comment) would be interesting to take a look at.

@dfreedm
Copy link
Contributor

dfreedm commented Jun 7, 2019

At this stage, I'm not going to add support for :host-context() unless Apple supports it. There is no point to forcing users to use polyfill'd selectors on Safari.

@dfreedm dfreedm closed this as completed Jun 7, 2019
Polyfills automation moved this from Inbox to Done Jun 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
Polyfills
  
Done
Development

No branches or pull requests

4 participants