feat(platform-browser): add viewencapsulation shadowdom for shadow dom v1 support - #19059

It might have been decided somewhere else but I'm curious about the naming.
Since this is using Shadow DOM V1 what are we going to call the API that uses Shadow DOM V2, if there is one?
Maybe something like ViewEncapsulation.Native2 would be more appropriate, similar to what Renderer2 did

I felt that ViewEncapsulation.Modern was more developer friendly. If a versioned name is needed it should be ViewEncapsulation.Native1 so that it matches the version of the Shadow DOM being requested.

Wouldn't it be possible instead to only keep ViewEncapsulation.Native and just let Angular deal with the difference internally? What if you need support for browser that only support one or the other? Angular should default to the latest specification at all times if available, and fall back to older ones if necessary and possible.

Shadow DOM v0 was an experimental non-finalized standard with limited browser support. Every browser that supported it supports v1 with the exception of old Android browsers. It should be deprecated and removed from Angular.

Supporting both of them seamlessly would be difficult at best. For example if a developer wanted write a component that used slots and they wrote it in v0 they would have this

<div>
  <content id=i1 select=".foo"></content>
  <content id=i2 select="my-child"></content>
  <content id=i3></content>
</div>

Angular would have to take that template detect that it's being rendered int v1 mode and convert it to

<div>
  <slot id=s1 name=slot1></slot>
  <slot id=s2 name=slot2></slot>
  <slot id=s3></slot>
</div>

Read more about the difference in slots.

My personal preference would be to just replace v0 with v1. Especially since v0 was experimental with limited browser support that was an opt-in feature. That feels to aggressive for Angular though. Hence this PR creates it as a new code path. Another route would be after v0 is removed, deprecate the Modern name and move it back to Native.

Alright, I'm convinced. Do you think it would be a good idea to deprecate the current Native option as DeprecatedNative (or something similar) and just have Native use the v1 specification by default? An Angular version later, the old DeprecatedNative option could be removed completely. This is what happened to the I18NPipesModule (now deprecated - but still usable - as DeprecatedI18NPipesModule) when it got replaced.

I'd be 👍 with renaming Native to DeprecatedNative and implementing a new Native with v1.

@skreborn ... if we take the fact that because of actual browsers possibilities ... using of current Native is very, very rare ... so your proposal looks as a logical and smarter step ahead.

This issue with the proposed solutions is breaking changes.
renaming Native -> DeprecatedNative is a breaking change.
Since people who are currently using Native would all of a sudden be swapped over to the new DOM V1 Native in which their <template> tags would no longer work

Renamed ViewEncapsulation.Modern to ViewEncapsulation.ShadowDOM and got the tests passing.

Hopefully the spec won't introduce any breaking changes down the line from here on out. If it does, we can still go on with ViewEncapsulation.ShadowDOM2 (although I'd like it very much if we didn't have to start versioning it).

Is there anything else I can do to move this along or just wait for a core member to review it?

Some thoughts (thanks for looking at this @abraham!)

• note that Angular emulates slot/content elements, even in native mode (this is why we renamed to ng-content to avoid conflicts). We're working on a Custom Elements integration that will need to account for this as well, but this will involve larger (likely breaking) changes wrt how nodes are assigned etc. Let's stay away from changes to projection here.

• Let's go with ViewEncapsulation.ShadowDom (note the casing, sorry!) as Native2 et al are confusing (Shadow DOM V1!)

• We should probably consider if/how/when we need to change the behavior of the emulated mode, see : https://github.com/angular/angular/blob/master/packages/compiler/src/shadow_css.ts - it's largely based on https://github.com/webcomponents/webcomponentsjs/blob/4efecd7e0e/src/ShadowCSS/ShadowCSS.js, which iirc is V0 based.

• If/when this lands, we should go ahead with the deprecation of the ViewEncapsulation.Native API (note this does not mean immediate removal)

@robwormald I've updated the casing. The other three points sounded like things to think about but not direct actionable items.

@robwormald Is there a reason that this solution which was in initial Renderer is not in Renderer2 anymore ?

Hello? Don't want to hassle you. Sure you're busy. But this PR has some merge conflicts that you probably ought to resolve.
That is... if you want it to be merged someday...

I'd be happy to fix up merge issues if there is some indication that my time won't be wasted.

ShadowDOM v0 is now deprecated in Chrome.

what is the status of this? Custom elements with safari requires attachShadow support...

Is there any update for this pull request?
I'm waiting for a working solution for the ViewEncapsulation.Native. There is currently no working polyfill for IE.
I would be very happy if this pull request could be merged soon.
Thank you very much for your effort.

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.}