30

The two shadow-piercing combinators have been deprecated as stated in https://www.chromestatus.com/features/6750456638341120
Then what's the substitude for achieving the same thing, or this shadow-piercing feature has been completely abandoned?

Zhengquan Bai
  • 957
  • 3
  • 12
  • 29
  • 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 http://stackoverflow.com/questions/34699350/shadow-piercing-descendant-combinator-deep-including-shadow-pseudo-el/34706299#34706299 and http://stackoverflow.com/questions/30829019/polymer-share-styles-across-elements/32941101#32941101 The longer-term solution is [CSS Custom Properties (aka “CSS variables”)](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables). – sideshowbarker Mar 02 '16 at 10:40

4 Answers4

19

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

The substitutes are:

MarcG
  • 25,541
  • 18
  • 100
  • 118
  • 6
    For cases when you cannot access the shadow dom before it is rendered, it's impossible to avoid `::shadow` – RenaissanceProgrammer Aug 23 '17 at 19:45
  • 5
    @MarcG If there's no mechanism to break encapsulation, how can I override framework styling? – adamdport Mar 08 '18 at 19:22
  • 8
    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. – Lucas Basquerotto Oct 29 '18 at 12:52
  • @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. – MarcG Oct 29 '18 at 17:51
  • 7
    @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/`. – Lucas Basquerotto Oct 29 '18 at 18:18
  • 4
    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. – Ryan B Mar 12 '19 at 02:11
  • 2
    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. – smaudet Apr 16 '19 at 13:44
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

magiccrafter
  • 4,637
  • 1
  • 50
  • 48
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.

sparanoid
  • 1,118
  • 10
  • 9
1

"::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
            }
        }
    }
KirstieBallance
  • 1,014
  • 9
  • 25