custom-elements-everywhere
custom-elements-everywhere copied to clipboard
webcomponents
Add tests for ability to work with customized built-ins
Check if frameworks are able to recognize the special meaning of the is=""-attribute, and that it cannot be handled like a traditional attribute when it comes to dynamic element creation.
@franktopel hm that's interesting.
I guess a strawman proposal would be to create an element like <a is="x-link"> and verifying that it has both the properties associated with a regular link, as well as any properties added by the type extension.
It seems Angular still does not handle the is="" attribute correctly when rendering: https://github.com/angular/angular/issues/6827#issuecomment-475379813.
Maybe the test could include something like comparing the innerText of the extended button in the following demos: Angular (not working): https://stackblitz.com/edit/angular-dginkc React (working): https://stackblitz.com/edit/react-saktyo
And it is still not working in Angular, I have tested https://stackblitz.com/edit/angular-dginkc with Angular version 8.2.14 and Angular version 9.0.0-rc.7. It would be nice to have test for this and it would also be more fair for React, since at the moment the first impression is that it a100% works in Angular but not in React. Btw I work in Angular.
I think this would be a tricky test to add because the is="" attribute is not and likely will never be supported in Safari.
@rob
I think this would be a tricky test to add because the
is=""attribute is not and likely will never be supported in Safari.
What makes you think Safari likely will never support this?
Also, does that mean that you only consider scenarios that are well supported by all major browsers?
What makes you think Safari likely will never support this?
This comment from Safari is the best explanation I could find: https://github.com/w3c/webcomponents/issues/509#issuecomment-230700060
Also, does that mean that you only consider scenarios that are well supported by all major browsers?
Yeah I think so. I feel weird asking a framework to do work to support a feature which another browser actively opposes.
I think if all the browsers agreed to a feature, but just hadn't gotten around to implementing it yet, that would be a different scenario and it would make sense to have tests then.