You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 18, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 18, 2021. It is now read-only.
I'm not sure what the color codes mean but I think everything that is currently red for custom elements / shadow dom should be set to yellow since everyone is either actively working on those and some folks have already shipped them in preview.
I think HTML Imports should be the only red squares.
Mobile browser support would be cool to include. Might make the table kinda long though?
@robdodson I agree on the mobile browsers. I was thinking we could either make the images smaller and have 2 rows or just say we support the latest mobile versions of these as well as the desktop versions
As for yellow on Shadow DOM - are we sure about active development in all browsers or has it been scheduled but work has not started yet ?
In Safari I'm pretty sure they're actively prototyping Custom Elements (there's a ticket...somewhere) and Shadow DOM v1 just shipped in Safari Technology Preview.
What about IE(9-10) support? Is that still necessary? We absolutely need 11 but I wonder if the polyfills has evolved recently. I would think so but IDK
@robdodson IE9-10 combine for almost 10% of global market share, from my quick look - which seems rather significant. Web Components JS doesn't offer support for browsers that low, but we added a couple small API polyfills to our distribution that enable it, and we haven't had issues (with Custom Elements, not Shadow DOM)
From a Shadow DOM perspective @treshugart (SkateJS) & @EisenbergEffect (Aurelia) both have polyfills for named-slots for Shadow DOM v1 . It might make sense to work together toward a common project on these polyfills. Thoughts @csuwildcat or @robdodson ?
I suppose the first step would be to setup a shared set of tests that each
implementation can run against the same criteria. @robdodson, is there a
current set of tests that are easy to run against other polyfill
implementations?
I suppose the first step would be to setup a shared set of tests that each
implementation can run against the same criteria. @robdodson, is there a
current set of tests that are easy to run against other polyfill
implementations?
We have a set of tests for the DOM API that @nadiam84 has been doing quite a bit of work on but it's not exhaustive.
FWIW, our polyfill is a polygap / prollyfill. We only intend on supporting the JavaScript API - which is a must-have for integration with React and other virtual DOM libraries - but CSS support is a nice to have for us and isn't worth the page weight and performance hit. IE9 is supported.
Happy to do anything we can to collaborate on this stuff.
Maybe it makes sense to list the browser support for native as we do.
I think it would be great to break down the polyfill browser support as well since more polyfills are being used now as well as versions and pieces of webcomponents.js. Breaking out the parts of webcomponents.js & webcomponents-lite.js and the support makes sense. Also taking any other polyfills and doing the same.
Activity
Nevraeka commentedon May 7, 2016
cc @robdodson @csuwildcat
robdodson commentedon May 9, 2016
I'm not sure what the color codes mean but I think everything that is currently red for custom elements / shadow dom should be set to yellow since everyone is either actively working on those and some folks have already shipped them in preview.
I think HTML Imports should be the only red squares.
Mobile browser support would be cool to include. Might make the table kinda long though?
Nevraeka commentedon May 10, 2016
@robdodson I agree on the mobile browsers. I was thinking we could either make the images smaller and have 2 rows or just say we support the latest mobile versions of these as well as the desktop versions
As for yellow on Shadow DOM - are we sure about active development in all browsers or has it been scheduled but work has not started yet ?
robdodson commentedon May 10, 2016
In Safari I'm pretty sure they're actively prototyping Custom Elements (there's a ticket...somewhere) and Shadow DOM v1 just shipped in Safari Technology Preview.
As for Edge... @csuwildcat any updates on that?
Nevraeka commentedon May 10, 2016
What about IE(9-10) support? Is that still necessary? We absolutely need 11 but I wonder if the polyfills has evolved recently. I would think so but IDK
csuwildcat commentedon May 10, 2016
@robdodson it is in the queue, but behind Service Worker development - they're just a bit backed up at the moment.
robdodson commentedon May 10, 2016
@Nevraeka I don't think there's any plan to work on IE9-10 support in either webcomponentsjs or polymer.
csuwildcat commentedon May 10, 2016
@robdodson IE9-10 combine for almost 10% of global market share, from my quick look - which seems rather significant. Web Components JS doesn't offer support for browsers that low, but we added a couple small API polyfills to our distribution that enable it, and we haven't had issues (with Custom Elements, not Shadow DOM)
robdodson commentedon May 10, 2016
oh sorry, not saying it's not an important sector, I just don't think anyone (on our end at least) has the availability to work on supporting it.
Related to x-tag?
csuwildcat commentedon May 10, 2016
@robdodson yeah, we get IE9-10 support for the non-Shadow DOM specs just by including a DOMTokenList polyfill
robdodson commentedon May 10, 2016
@csuwildcat would you want to vend those custom element polyfills on webcomponents.org with instructions on how to use them?
Nevraeka commentedon May 10, 2016
👍 to
good call @robdodson . I want to update the resources page asap anyway and thats a great place for these
Nevraeka commentedon May 27, 2016
From a Shadow DOM perspective @treshugart (SkateJS) & @EisenbergEffect (Aurelia) both have polyfills for named-slots for Shadow DOM v1 . It might make sense to work together toward a common project on these polyfills. Thoughts @csuwildcat or @robdodson ?
csuwildcat commentedon May 27, 2016
I suppose the first step would be to setup a shared set of tests that each
implementation can run against the same criteria. @robdodson, is there a
current set of tests that are easy to run against other polyfill
implementations?
On Fri, May 27, 2016 at 11:31 AM, Erik Isaksen notifications@github.com
wrote:
robdodson commentedon May 27, 2016
Good question. @azakus @addyosmani do you know of any SD unit test suite?
On Fri, May 27, 2016 at 11:38 AM, Daniel Buchner notifications@github.com
wrote:
treshugart commentedon May 28, 2016
We have a set of tests for the DOM API that @nadiam84 has been doing quite a bit of work on but it's not exhaustive.
FWIW, our polyfill is a polygap / prollyfill. We only intend on supporting the JavaScript API - which is a must-have for integration with React and other virtual DOM libraries - but CSS support is a nice to have for us and isn't worth the page weight and performance hit. IE9 is supported.
Happy to do anything we can to collaborate on this stuff.
robdodson commentedon May 28, 2016
It looks like there's a number of tests living in the webcomponents.js repo that use WebComponentTester
https://github.com/webcomponents/webcomponentsjs/tree/master/tests
miguelamello commentedon Jun 2, 2016
Polymer 1.0 is not working properly in IE 11.0.9600.18314
Many average users still use IE 11, and even IE10.
I think it is a concern.
Nevraeka commentedon Jun 3, 2016
Maybe it makes sense to list the browser support for native as we do.
I think it would be great to break down the polyfill browser support as well since more polyfills are being used now as well as versions and pieces of webcomponents.js. Breaking out the parts of webcomponents.js & webcomponents-lite.js and the support makes sense. Also taking any other polyfills and doing the same.
teppeis commentedon Jan 8, 2017
Why is HTML Imports of Firefox YELLOW?
Why is "IE/Edge" combined?