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...
I'm submitting a...
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 thedocument-register-elementpolyfill to thewebcomponentsjsone. This is a great step forward but there are two more issues:/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)webcomponentsjspolyfill loaded Angular Elements using SD on non SD browsers do not have their styles encapsulatedExpected behavior
I would love to have Angular Element fully supporting
viewEncapsulation.ShadowDomfor 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
webcomponentsjspolyfill outside of angular. This probably isn't trivial on the Angular side but makes it easier for Angular consumers.Alternatively maybe the
viewEncapsulation.Emulatedmechanism could be somehow leveraged for Angular Elements usingviewEncapsulation.ShadowDomto 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 sideWhat 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