Login/Register
What's the substitute for ::shadow and /deep/?
Asked Answered
Solved webweb-componentshadow-dom
O

4

32

The two shadow-piercing combinators have been removed, as stated in https://www.chromestatus.com/features/6750456638341120

So, what's the substitute for achieving the same thing? Or has this shadow-piercing feature been completely abandoned?

Olvan answered 2/3, 2016 at 8:15 Comment(1)
For something to replace ::shadow and deep that works now, use a style element inside your shadow root, with something like @import url( '/common-style.css' ). See #34699850 and #30829519 The longer-term solution is CSS Custom Properties (aka “CSS variables”). – Zohara
A
20

::shadow and /deep/ were removed for breaking encapsulation.

The substitutes are:

Aesculapius answered 6/3, 2016 at 23:10 Comment(8)
For cases when you cannot access the shadow dom before it is rendered, it's impossible to avoid ::shadow – Hostel
@MarcG If there's no mechanism to break encapsulation, how can I override framework styling? – Melanesian
I don't agree with "The problem is that ::shadow and /deep/ break encapsulation. I am glad they are gone.". Although they break encapsulation, if you use 3rd party components and they don't have css variables to style the way you want, you are simple without options, except for asking them to create the variables you want (which could never be created), or having to fork the component and to maintain it yourself just because of some trivial css you could have applied if /deep/ was supported. I would prefer never have to use /deep/, but I would want to be able to use it when needed. – Monitory
@LucasBasquerotto So you actually do agree they break encapsulation, but you think that's OK when you have no other option. Well, when you have no other option and you really need to do something, any option is good. But remember breaking encapsulation is bad for a reason, and your use of the component may break when the 3rd party changes the component's internal representation. Ideally, yes, the 3rd party should allow for you to style everything you need, otherwise their components are lacking. – Aesculapius
@MarcG Yes, they break encapsulation and whenever possible such a thing should be avoided. I see your point, and I agree to it partially, but I don't agree that removing /deep/ was something good. In an ideal world, every library would provide every expected css variable so as to make the use of hacks such as /deep/ unecessary. Unfortunately, they are people with limited resources and time, and it's expected that their components will have css properties that the consumers can't override through css because of the shadow DOM. Such problems would be greatly mitigated with /deep/. – Monitory
Just had a situation where a third pary autocomplete input was showing it's auto complete suggestions behind my elements. should be a simple fix, just a z-index. But no this was painful to fix. I finally stumbled upon /deep/ which works but i see it's been depreciated. I don't see how you would fix this problem when it is fully removed. I think we still need a feature like this but override need to be explicit instead of implicit. – Sigmon
The problem here isn't that encapsulation could be broken - the problem is the hubris of whomever decided nobody should code in manner X. Let good code break no encapsulation, let bad code be, don't try to enforce 'good' on everybody. You cause problems that way and engender hatred and fury. I think there will be a revolt. – Mapel
How does it make any sense that forced encapsulation on a shadow DOM is a best practice while mode: closed is a worst practice? It doesn't! This is an excellent example of blindly following "best practices" without understanding why they are best practices. The shadow DOM is not a class. A class is a logic container that's significantly easier to break. A custom component is most often used as a scoped template to increase productivity and follow DRY principles. Forcing me to write "part" on everything and disabling core styling principles actively fights productivity and DRY principles. – Levana
T
2

As of Polymer 2:

  • ::shadow (shadow-piercing selectors) - there is no direct substitute. Instead a custom CSS properties has to be used. Polymer 2: Custom CSS Properties

  • /deep/ - there is some sort of replacement by defining :host > * { ... } (applies a ruleset to all of the top-level children in the host's shadow tree, which doesn't conflict with the rule in the main document).

For more detailed information check Polymer 2 Upgrade Notes

Territus answered 2/8, 2017 at 14:6 Comment(0)
U
2

At the time of writing you can try ::part and ::theme with Chrome 73 and above:

https://www.chromestatus.com/feature/5763933658939392

<submit-form>
  #shadow-root
  <x-form exportparts="some-input, some-box">
    #shadow-root
    <x-bar exportparts="some-input, some-box">
      #shadow-root
      <x-foo part="some-input, some-box"></x-foo>
    </x-bar>
  </x-form>
</submit-form>

<x-form></x-form>
<x-bar></x-bar>

You can style all the inputs with:

:root::part(some-input) { ... }

There is the full documentation how it works:

https://github.com/fergald/docs/blob/master/explainers/css-shadow-parts-1.md

This somehow can solve your problem, but I still miss the days how I styled embedded tweets with ::shadow.

Ufa answered 2/4, 2019 at 6:49 Comment(0)
E
0

"::v-deep" is working for me. For example: 

    .menu {
        // stuff
    }
    /deep/.sub-menu {     // override submenu
        .sub-menu__mini {
                //stuff
            }
            a, a:hover {
                //stuff
            }
        }
    }

becomes:

    .menu {
        // stuff
    }
    ::v-deep .sub-menu {     // override submenu
        .sub-menu__mini {
                //stuff
            }
            a, a:hover {
                //stuff
            }
        }
    }
Emanuelemanuela answered 7/6, 2019 at 17:31 Comment(1)
This is specific to Vue. The equivalent in Angular is ::ng-deep – Tyratyrannical

© 2022 - 2024 — McMap. All rights reserved.