[Angular Elements] Supporting Shadow Dom and Theming IE11+

[benoitjchevalier]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[ ] Other... Please describe:

Current behavior

Shadow Dom (SD) support has recently been added for Angular Elements, which is great. It works fine for browsers having native SD support, and obviously not so great for browsers not having it (IE, Edge...). SD is a crucial feature for Angular Elements, in particular for the ability to use <slot>.

It is actually currently possible to get <slot> to work on IE with Angular Elements by switching the document-register-element polyfill to the webcomponentsjs one. This is a great step forward but there are two more issues:

• theming. The recommended way to handle theming/style override in webcomponents with SD is to use css variables. To my knowledge this is the only solution forward as /deep/ has been deprecated. IE 11 unfortunately doesn't support css variables. It is currently possible to somewhat get around the issue by using this ponyfill but it introduces some custom code and limitations (such as having to use javascript to override a css variables on an element rather than just defining the css variables value on a css class)
• style encapsulation. Even with the webcomponentsjs polyfill loaded Angular Elements using SD on non SD browsers do not have their styles encapsulated

Expected behavior

I would love to have Angular Element fully supporting viewEncapsulation.ShadowDom for IE11 + browsers.

This could be done by Angular leveraging Shady CSS to both support style encapsulation and css variables. People needing that feature could manually load the webcomponentsjs polyfill outside of angular. This probably isn't trivial on the Angular side but makes it easier for Angular consumers.

Alternatively maybe the viewEncapsulation.Emulated mechanism could be somehow leveraged for Angular Elements using viewEncapsulation.ShadowDom to provide encapsulation to browsers without SD support? This would leave the css variables problem to the consumer of Angular but could still work. This probably puts less work on the Angular team and more on the consumer side

What is the motivation / use case for changing the behavior?

I think that the current stance is that there is no support for browsers that don't natively support SD. However making part of Angular supporting a different subset of browsers seems a bit odd and in my opinion as long as there is a way forward to support them Angular should. IE 9 and 10 probably can't be polyfilled but I'm hoping IE 11/FF/Edge could be supported with some work.

N.B: I know IE has a very small market share, but this market share is also unfortunately often a crucial one, such as utility companies, hospital, etc... Dropping IE is not an option for a lot of people in industrial settings.

Environment

Angular version: 7.x.x


Browser:
- [ ] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [x] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [x] IE version XX
- [x] Edge version XX

Others:

I'd love to hear more about the future of Angular Elements, how much focus is going to be put on them, what browser support we're looking at, any timeline... 

[mlc-mlapis]

@benoitjchevalier ... you can ask also MS for adding that support into IE. Simply you are asking for something on a wrong place ... do you think that it is normal that something what is practically dead already and thrown to the dustbin of history will be kept alive forever?

[benoitjchevalier]

@mlc-mlapis I don't think I'm asking it in the wrong place since Angular supports IE 11. I'm merely asking for the same support on one of the new feature. I've tried to bypass the issues externally as much as possible but am hitting some kind of wall at this point.

I'd like to hear what the angular team position is going to be on this as I don't think IE is as dead as people would like it to be (me included...)

ps: this is also going further than IE since one of the issue described concerns browsers not supporting SD, including FF (soon) and Edge (not sure what the status is right now)

[manklu]

Edge (not sure what the status is right now)

Currently in development. See https://developer.microsoft.com/en-us/microsoft-edge/platform/status/shadowdom/?q=shadow

[tommck]

MANY corporations haven't upgraded from Windows 7 and use IE, so they MUST use IE11. EDGE is not supported there. IE still has over 10% of the market

[skreborn]

@tommck While you're right that a lot of companies are stuck using IE11, it's unrealistic to assume that IE has anywhere near 10% of the market share across all devices - because like it or not, mobile is huge even in corporations.

In any case, even those companies that are stuck on Windows 7 are at liberty of using alternative browsers that are updated regularly and are following the standards.

With that said, I agree that an official statement on this would still be appreciated, as Angular itself does, in fact, promote itself as a framework fully supporting IE11.

[mlc-mlapis]

... that because of some of their reasons they are still using IE, is their business, but they shouldn't transfer their decision to the others. Because otherwise, their simply saved cost is paid by someone else (real money, but mainly the loss of time which is even more expensive).

[tommck]

@skreborn IE has 11.7% of the desktop browser market right now: https://netmarketshare.com/browser-market-share.aspx

I guarantee it's much higher in large corporations

[skreborn]

Well, that's a bit misleading, because that's the average of the last year. Right now it's just under 10%, but that's still just desktop browsers. Add mobile and it suddenly drops under 5%. Then again, we're not here to argue about percentages. IE11 is indeed in use by corporations - that's a fact. The question is, how much is the actual overlap between people forced to use IE11 as their only browser and people who are to consume Angular Elements induced applications.

[tommck]

So... we'll support Firefox and Edge, but not IE? They have less marketshare (this is month of September 2018)

[mlc-mlapis]

... but the decision was already made by MS several years ago. IE is really a dead thing ... with absolute no evolution ... and it doesn't matter if anybody is using it. The numbers above have no sense. So what are you solving? Do you want to solve it for MS? How?

[tommck]

What I'm solving is that LOTS of our users use IE. This is a nice feature that I'd love to be able to use in our app. this is a site that gets millions of hits per day with internal and external users. I would prefer not to be forced to use sub-optimal options just because of IE11. We must support it though, because there are still plenty of people that are not on Win10 yet and may not be savvy enough to install another browser

[mlc-mlapis]

@tommck ... I know all of that. 😺 But first you have to answer the basic question:

How long would you support it? 5 years, 10 years, ... and for all that time you wish to block any move to new things on Angular side and others ... because of IE doesn't know it (and it's not possible to create any reasonable polyfill due to inapplicability of performance with such a thing). Look what about to call MS side first to persuade them ... to add some key new specs and to allow using IE for such a long period.

There have to be some plans for sure, not just: We will see in some time in future.

[tommck]

We support until the usage level goes below 1%. So.. it'll probably be quite a while

[benoitjchevalier]

The question is, how much is the actual overlap between people forced to use IE11 as their only browser and people who are to consume Angular Elements induced applications.

Good point, I think this is a fairly "common" scenario with big companies investing more and more in Design Systems, which are the perfect place to use Web Components. If the company has invested in Angular2 in the past using Angular Elements makes a lot of sense.

Some of those big companies then serve "slower paced" segment of the market, such as power, healthcare... which are sometimes still locked in IE

[robwormald]

We are not going to make any special affordances for IE in the world of Shadow DOM and Custom Elements. I realize that's probably not what you want to hear, but the reality of these APIs is that they are extremely expensive to polyfill, and provide some capabilities that simply cannot be polyfilled 1-1.

The Edge team has now publicly stated they will be supporting Custom Elements and Shadow DOM in Edge and that development has started: (https://developer.microsoft.com/en-us/microsoft-edge/platform/status/shadowdom/?q=shadow%20DOM). They will not be supporting it in IE. Ever.

The polyfills do work, to the extent they are able to, for IE9+ - if there's an incompatibility we can work around, we're happy to look into that, but are not going to add a ton of functionality in Angular's core or compiler to emulate something that not even Microsoft is going to support going forward.

See polyfills here: https://github.com/webcomponents/webcomponentsjs

[robwormald]

(Note that Angular's Emulated View encapsulation is effectively ShadyCSS in the compiler)

[chaosmonster]

Thanks for the statement 👍

[benoitjchevalier]

@robwormald Thanks for the clarification, good to know where we stand.

Given that webcomponentsjs won't polyfill style encapsulation out of the box for IE I'm thinking of an "outside of angular" solution, could you tell me if you see any big blocker with it?

The idea would be for our library to use viewEncapsulation.emulated for all our Elements, getting style encapsulation by Angular implementation of ShadyCSS. We would then use our own provider/Renderer to actually create components with a shadowRoot. In essence a similar hack to what you proposed to use while we were waiting for Shadow Dom V1 to be implemented in Angular Element.

[collinstevens]

@benoitjchevalier Shadow DOM v1 is implemented as ViewEncapsulation.ShadowDom.

https://stackoverflow.com/questions/52237950/contain-the-style-of-my-angular-web-component-so-it-doesnt-bleed-to-the-compone/53020036#53020036

[mlc-mlapis]

... ShadyCSS provides a library to simulate ShadowDOM style encapsulation ... https://github.com/webcomponents/shadycss

[benoitjchevalier]

@collinstevens Yes but making your component using ViewEncapsulation.ShadowDom will prevent angular from emulating style encapsulation (which makes sense). It's perfectly fine for browsers supporting SD as they will encapsulate it themselves, but as mentioned in this issue that will mean IE won't have style encapsulated. Hence my suggestion.

@mlc-mlapis Yes, that's why I mentioned it in the issue. However just including it in your page won't provide style encapsulation, whatever framework "building" the components would have to leverage ShadyCSS to make it work. This was my suggestion above but as Rob mentioned they don't want to build special affordance for IE

[collinstevens]

@benoitjchevalier You said you are waiting for ShadowDOM v1 to be implemented in @angular/elements, while it already is. You also said you would prefer to use ViewEncapsulation.Emulated and then manually place your elements in a shadow-root, but you will not be able to put them in a shadow-root since IE11 does not support it. I'm confused by what you are trying to accomplish. Are you looking for a solution for IE11?

[benoitjchevalier]

Sorry for the confusion. I wasn't saying that we are waiting but that we were waiting. I mentioned a workaround we previously used, based on some example I nicked from Rob, at the time when ViewEncapsulation.ShadowDom wasn't available. We used to manually create a shadow root when using ViewEncapsulation.Native

It is possible to use a "shadow root" in IE with ShadyDom, loading the ShadyDom webcomponentsjs polyfill before creating the element will allow for it to work. The issue is that just loading the ShadyCSS polyfill does not provide style encapsulation out of the box

[morewry]

@robwormald What about this incompatibility? https://github.com/webcomponents/shadydom/pull/286 https://github.com/webcomponents/shadydom/issues/182

Also, I'd strongly prefer Angular not advertise support of IE11 if the support is only partial and conditional.

I'm not sure if Angular Elements' relationship with Angular is such that getting in the way of polyfilling SD style encapsulation counts, but it might.

[tommck]

Or maybe just put an * with a mention of what's not supported

[sarunint]

Angular itself supports up to IE9. But Angular Elements is a way to package Angular component as a web component. So the support for Angular Elements is the same as support for web components.

See https://www.webcomponents.org/ for more details.

[morewry]

But doesn't Angular also use a ShadyDOM implementation for style scoping and slots internally? Or was that dropped since I last looked (which was early Angular 2)?

[sarunint]

@morewry Yep, if you use ViewEncapsulation.Emulated in Angular Elements, you don't need Shadow DOM.

[collinstevens]

@sarunint Using ViewEncapsulation.Emulated does not replace the need for ShadowDOM v0/v1. The idea of @angular/elements as I understand it and as others have described it, is to create reusable web components which are embedded into other applications without worrying about the underlying technology used to create them.

For example, at my company, we are distributing @angular/elements which are consumed by other teams. If we we're using ViewEncapsulation.Emulated we would have to worry about styles bleeding into and out of the component; using ShadowDOM solves this issue by placing the styles inside of the #shadow-root.

[mlc-mlapis]

@collinstevens ... the logic of placing the styles inside is applied also in ViewEncapsulation.Emulated mode (but using the HEAD tag), the difference is also that with ShadowDOM you are able also to protect inside of that component from any outside access if you want, right?

[trotyl]

But doesn't Angular also use a ShadyDOM implementation for style scoping and slots internally? Or was that dropped since I last looked (which was early Angular 2)?

@morewry Angular has been using self-maintained emulation logic since the very first implementation, which was heavily based on webcomponents.js at the time of following Shadow DOM v0 spec, but never directly used any 3rd-party ponyfill library.

Also, the ShadyCSS project was started at Sep. 2016 only for Shadow DOM v1 spec, there's no way Angular could depend on it.

[morewry]

@trotyl Yeah, I thought that was the case, which is why I said "a ShadyDOM", not "ShadyDOM". I think I'm being confusing because I'm making several assumptions for what may be no good reason (they seem reasonable, but I haven't kept up with Angular (>=2) for a while). I'm aware that if some of these assumptions are wrong, my comments aren't relevant, and that's 👍

First, I'm assuming that viewEncapsulation.Emulated is Angular's ShadyDOM implementation under the hood and that it has bottom-up style scoping at least still as it did during beta. Second, that viewEncapsulation.ShadowDom makes no provision to polyfill, relying on Shadow DOM to be implemented natively (providing both top-down and bottom-up style scoping). Third, despite that, Angular Elements are intended to be compatible with webcomponentsjs polyfills for users who need more support than browsers with native Shadow DOM. Fourth, the webcomponentsjs polyfills could be argued to include ShadyCSS, but inarguably one can normally use ShadyCSS or CSS Modules with the webcomponentsjs polyfills to attain at least bottom-up style scoping in IE. Fifth, that Angular Elements as a project is closely related to Angular and that one of those relationships is that it allows a developer to compile an Angular component into a Web Component...and Angular components can normally have bottom-up style scoping in back to IE 9.

The idea that you can't get style scoping in IE with Angular Elements at the same time as being able to use native Shadow DOM in Chrome feels off in light of several of these assumptions.

Finally, I'm sort of conflating Angular Elements with "Angular's general compatibility with web components" and thinking of situations where Angular, AngularJS (1.x), vanilla Web Components, and Angular Elements get used in various combinations. My reasoning is it might seem broken to an Angular user who supports IE and depends on third party vanilla Web Components, Angular Elements, and webcomponentsjs polyfills. It's possible for the vanilla WC to have at least bottom-up encapsulation in IE thanks to the author using ShadyCSS, while the Angular Element author...can't (?), so the vanilla WC ends up working better than the leaking Angular Element. Might also be frustrating if an Angular user still working on fully migrating away from AngularJS pulls in an Angular Element and webcomponentsjs polyfills and runs into that problem I linked earlier.

I use "a ShadyDOM" to mean a non-rigorous ShadowDOM polyfill that makes heavy compromises. I should probably stop doing that.

[ray-kay]

Any news on this? Ideally I would like to use viewEncapsulation.ShadowDom and have a polyfill for es5 browsers but cant find a way to get it working.

[dimitriy-k]

still no news? used for the first time viewEncapsulation.ShadowDom and apparently it does not works in IE11

[alan-agius4]

Closing as IE 11 is no longer supported.

[angular-automatic-lock-bot[bot]]

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