Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Alternative to /deep/ in the future #17867

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

Closed
NetanelBasal opened this issue Jun 30, 2017 · 37 comments
Closed

Alternative to /deep/ in the future #17867

NetanelBasal opened this issue Jun 30, 2017 · 37 comments

Comments

@NetanelBasal
Copy link

NetanelBasal commented Jun 30, 2017

[ x ] Documentation issue or request

From the CHANGELOG ( 4.3.0-beta.1 ):

Because the deep combinator is deprecated in the CSS spec,
/deep/, >>> and ::ng-deep are also deprecated in emulated shadow DOM mode
and will be removed in the future.

I would like to know whether there will be an alternative in the future to /deep/ or should we start using other ways?

@ericmartinezr
Copy link
Contributor

#17677

@tytskyi
Copy link

tytskyi commented Jun 30, 2017

@ericmartinezr as per link you provided ::ng-deep will be also removed in future, i think @NetanelBasal is asking for long-term solution.

@vicb
Copy link
Contributor

vicb commented Jun 30, 2017

Closing this as we have no plan to remove ::ng-deep in a near future.

It will be first deprecated and at this time we will provide docs about migration.
Then, some time later only it will be removed.

@roddy
Copy link

roddy commented Aug 31, 2017

The docs now say:

As such we plan to drop support in Angular (for all 3 of /deep/, >>> and ::ng-deep).

So the question remains: what is the long-term alternative to ::ng-deep?

@ghost
Copy link

ghost commented Sep 4, 2017

I'm with @roddy! I'm using Material2 and because of this change I am now no longer able to apply custom styles 😿

@hasMobi
Copy link

hasMobi commented Sep 7, 2017

I believe this thread is wrongly closed, because all online official documentation, except the above comment by @vicb, claim that ALL 3 POSSIBILITIES to put shadow piercing CSS rules are being deprecated.

Do we have a solid confirmation that ::ng-deep is a long term solution that will not need replacement/refactoring of current code in the future, and is here to stay indeed?

@emilio-martinez
Copy link
Contributor

I think CSS Custom Properties are going to be the ones to replace this behavior eventually because they can "cross" shadow boundaries. The only impediment from my perspective for that to happen is browser support. CSS Custom Properties are polyfillable but not without concerning caveats, one of which I'd consider to be performance.

I agree that the deprecation of this is concerning, but hopefully it will last in Emulated encapsulation long enough for CSS Custom properties to be more widely available.

@sandorfr
Copy link

I think this issue should be opened ;). The comment made here by @vicb #17867 (comment) clearly conflicts with the one done by @IgorMinar there #17677 (review)

Is it now considered a bad practice? In that case what's the alternative good practice? There's is a communication and documentation gap here :(.

@mlc-mlapis
Copy link
Contributor

mlc-mlapis commented Feb 15, 2018

@sandorfr ... I think that both have the same meaning ... just words used to express the relevant time period are slightly different ... but in reality it is not possible to expect that anything in this area will be fast ... take into account, for example, how long it takes till IE won't be supported ... which allow all of us move much more faster ... how long it takes the specs and full support in browsers around Shadow DOM ... and it is just unrealistic to expect any movement forward without those.

@rdicroce
Copy link

I agree that there needs to be some way to apply styling to child components. Currently, there's no way to do that other than using the deep selector (which is deprecated and will be removed according to the docs) or using unencapsulated styling.

CSS Custom Properties is not a sufficient replacement IMO. Maybe I'm missing something, but it looks like that would only work if the child component is using a variable for the thing you want to change. Which is fine if the child component is first-party code that you can easily modify, but not so much if it's a third-party component.

@mlc-mlapis
Copy link
Contributor

mlc-mlapis commented Feb 15, 2018

@rdicroce ... it is right ... but there is also the fact that this behavior is intended ... because it creates the API for styling ... what a component's author wanted to allow (it is related to many security or functionality factors, ...).

The most blocking factor is actually support for IE because no IE version is able to use CSS Custom Properties. It is a counterproductive reality ... more time for supporting IE (and extending time when some apps are able to run under ... for some cost savings) means on the other side much more financial and timing costs for others.

Technically maybe also the fact that CSS Custom Properties are actually able only map trivial values and not any objects, is a limitation for some cases ... for a large number of properties.

... only work if the child component is using a variable for the thing you want to change.

@sandorfr
Copy link

@mlc-mlapis in that case ng-deep shouldn't be marked as deprecated ;).

@sgentile
Copy link

sgentile commented May 8, 2018

This is closed, but it's a discussion that hasn't been resolved ?

@mlc-mlapis
Copy link
Contributor

@sgentile ... follow this one: #23636

@ganqqwerty
Copy link

So, I guess there's no alternative right now, so we should all continue to use it, because it's practical.

@jaydarken
Copy link

The only thing I hate with ::ng-deep is that it affects all other components

@mlc-mlapis
Copy link
Contributor

@jaydarken ... which all other components? How do you want to differentiate them?

@Hainesy
Copy link

Hainesy commented Oct 2, 2018

The only thing I hate with ::ng-deep is that it affects all other components

@jaydarken not if you nest it like such:

.my-parent-class ::ng-deep .my-child-component-class {
    // Won't affect other components
}

@sgentile
Copy link

sgentile commented Oct 2, 2018 via email

@maximelafarie
Copy link

maximelafarie commented Oct 17, 2018

As @vicb said:

Closing this as we have no plan to remove ::ng-deep in a near future.

It will be first deprecated and at this time we will provide docs about migration.
Then, some time later only it will be removed.

But now that it's deprecated (c.f.: https://angular.io/guide/component-styles#deprecated-deep--and-ng-deep), the doc doesn't suggest any other way (with the same behavior) to achieve the same thing with a supported alternative.

@fr0
Copy link

fr0 commented Oct 24, 2018

The ideal alternative to ::ng-deep is ::part() and ::theme() from the CSS Shadow Parts spec.

#26728

@ciel
Copy link

ciel commented Jan 14, 2019

Yeah this is getting pretty frustrating. If there's not an alternative in the pipeline, then this is seriously going to muck with the whole ecosystem

@trevorhreed
Copy link

A possible solution for those who are trying, simply, to style an element inside a component that is not included by Angular in the view encapsulation scope:

https://stackoverflow.com/a/54913259/269061

@LouAdrien
Copy link

any css or scss only solution? I don't see myself implementing style through js as @trevorhreed mentionned :/
Also, why is this still closed, should we open another issue that is specifically called "Alternative to ::ng-deep right now"? :P

@p3x-robot
Copy link

if i replace ::ng-deep with ::slotted, then i am right? on docs says that ::ng-deep is deprecated as well

@ciel
Copy link

ciel commented Apr 2, 2019

I don't think so. ::slotted works with ShadowDOM slots and I don't think it works the same way unless you switch to ShadowDOM encapsulation.

@emilio-martinez
Copy link
Contributor

::slotted isn't the same as /deep/ was, but it could function as an alternative in some use cases for ::ng-deep. Unfortunately, as mentioned above it currently only works in ShadowDOM. It would be nice if it worked for Emulated encapsulation.

@sp90
Copy link
Contributor

sp90 commented May 3, 2019

Any news on alternatives since the documentation states that you have plans for dropping support for the ::ng-deep feature 💥

@p3x-robot
Copy link

with a big refactor you can resolve it with classes ...

@sp90
Copy link
Contributor

sp90 commented May 3, 2019

@p3x-robot I have just started the project so just wanted to figure out if there was a quick solution got a tut on the refactoring you're talking about

@p3x-robot
Copy link

p3x-robot commented May 3, 2019

i never used deep, but from a side project, i saw this. i always been using with classes.... but i do not know a quick solution.
but as of now ::ng-deep is still working!

@lucasbasquerotto
Copy link

@p3x-robot How can you access shadow dom (or emulated) with classes? What about 3rd party components? (waiting for a PR to land for every css you want to apply or fork the component repository are both horrible solutions. If you own the component, on the other hand, this wouldn't be an issue, as you can easily change the css)

@p3x-robot
Copy link

I changed to encapsulation: ViewEncapsulation.None, as for 3rd party components, it should be solved by the 3rd party developer, I suppose.

@p3x-robot
Copy link

Of course every solution has its own quirks...

@rszemplinski
Copy link

So the question still stands. Is there an alternative to ng-deep or is this something that's just going to be ignored? I don't want to rely on 3rd party components to do things right the first time.

@lucasbasquerotto
Copy link

I don't want to rely on 3rd party components to do things right the first time

I would say that in lots of cases it's not even about do things right. The 3rd party component may be working fine, but it's expected that the clients that use the component may want to add customizations to its appearance and behaviour, and it's also expected that the 3rd party component owner won't implement all those customizations (or it could take a lot of time, unless you fork the component repository).

I see a lot of potential in shadow dom, especially because it won't override other components css if I don't say so explicitly (which is a problem without shadow dom, because you don't have a way to really avoid that, the best you can do is give css classes that you don't think will be used by other components).

But being unable to use something like /deep/ in shadow dom makes it impossible to override css styles explicitly (in cases where I really need), unless I use some javascript ugly hacks. I hope that angular at least keeps ::ng-deep, removing the deprecation, and better yet, that the shadow dom specification includes something like /deep/ in the future (I don't know if the main reason for it to be removed was encapsulation or performance, if it was performance it may be a bit harder for it to be included again).

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 15, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests