-
Notifications
You must be signed in to change notification settings - Fork 26.2k
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
Comments
@ericmartinezr as per link you provided |
Closing this as we have no plan to remove It will be first deprecated and at this time we will provide docs about migration. |
The docs now say:
So the question remains: what is the long-term alternative to |
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 |
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.
|
@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? |
@jaydarken not if you nest it like such:
|
nice, I didn't realize you could do this
…On Tue, Oct 2, 2018 at 4:35 AM Chris Haines ***@***.***> wrote:
The only thing I hate with ::ng-deep is that it affects all other
components
@jaydarken <https://github.com/jaydarken> not if you nest it like such:
.my-parent-class ::ng-deep .my-child-component-class {
// Won't affect other components
}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17867 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIFNB_1ZAMvm3Gv1DnA0XQsSPMU8devks5ugyVKgaJpZM4OKNOy>
.
|
As @vicb said:
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 |
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 :/ |
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 |
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. |
@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 |
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 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 |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
[ x ] Documentation issue or request
From the CHANGELOG ( 4.3.0-beta.1 ):
I would like to know whether there will be an alternative in the future to
/deep/
or should we start using other ways?The text was updated successfully, but these errors were encountered: