Alternative to /deep/ in the future
NetanelBasal opened this issue · 37 comments
[ 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-deepare 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 as per link you provided ::ng-deep will be also removed in future, i think @NetanelBasal is asking for long-term solution.
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.
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?
I'm with @roddy! I'm using Material2 and because of this change I am now no longer able to apply custom styles 😿
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?
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.
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 :(.
@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.
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.
@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.
@mlc-mlapis in that case ng-deep shouldn't be marked as deprecated ;).
This is closed, but it's a discussion that hasn't been resolved ?
So, I guess there's no alternative right now, so we should all continue to use it, because it's practical.
The only thing I hate with ::ng-deep is that it affects all other components
@jaydarken ... which all other components? How do you want to differentiate them?
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
}
As @vicb said:
Closing this as we have no plan to remove
::ng-deepin 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.
The ideal alternative to ::ng-deep is ::part() and ::theme() from the CSS Shadow Parts spec.
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
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:
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
if i replace ::ng-deep with ::slotted, then i am right? on docs says that ::ng-deep is deprecated as well
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.
::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.
Any news on alternatives since the documentation states that you have plans for dropping support for the ::ng-deep feature 💥
with a big refactor you can resolve it with classes ...
@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
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!
@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)
I changed to encapsulation: ViewEncapsulation.None, as for 3rd party components, it should be solved by the 3rd party developer, I suppose.
Of course every solution has its own quirks...
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.
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).
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.