[polymer-dev] Re: localDom API and other libraries
Is the experimental import for avoiding Polymer.dom documented anywhere? I'd be interested in trying it out. On Monday, May 18, 2015 at 8:46:20 PM UTC-4, Eric Eslinger wrote: One of the really rad things about Polymer (0.5) and webcomponents is that everything is just DOM. You can pretty easily use core- and paper- components libraries inside of an (say) angular app to render out content. Doesn't matter if you're using jQuery raw or ember or what have you- DOM is DOM, and it mostly works (modulo some property / attribute bindings) The new localDom API seems to indicate that this may no longer be the case- if I'm redistributing DOM content, I need to use the polymer dom interface, rather than just plain parent/child/append calls on document. This seems to indicate that modern polymer isn't going to be compatible with angular, or with any other library that manipulates the DOM, or is it the case that this only matters when there's more complicated shady/light manipulations? As an example, if I have content in the drawer part of a paper-drawer-panel, and then, using jquery or some other element selector, inject nodes inside of the already-projected menu div, will this break things? Or is it only the case that I need to use the local DOM api when if I'm changing the nodes that would be selected as content to project (and not their child nodes)? Is there some way to shim the document-level query selectors in there or add a mutation observer that calls distributeContent as needed? I'm guessing it was this shimming and mutation observer that contributed to the slowness of 0.5 in non-chrome browsers. I've got next week blocked out to actually work on getting angular 1.4 to play nice with polymer 0.9 (we use angular to build the page and manage data, and polymer for handy flexbox directives and material design ui bindings). So I guess I'll figure it out then. e Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/65c523d0-47b1-4786-8584-fdd2d2fd8047%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [polymer-dev] Re: localDom API and other libraries
Jim, You can find the experimental patching import here: https://github.com/Polymer/polymer/blob/master/src/lib/experimental/patch-dom.html It has not been tested extensibly and there are a number of caveats (e.g. there is some performance impact, document.querySelector will traverse shady roots, etc.) so your mileage may vary. Kevin On Wed, May 20, 2015 at 10:48 AM, jim.j.si...@gmail.com wrote: We have experimented with patching dom traversal and mutation api's, and there's an experimental import in Polymer that does this. It can let some libraries interoperate more smoothly with Shady DOM powered elements that, for example, perform distribution. We're continuing to work on it and explore if it should be integrated out of the box or be available as an opt in layer. See the above quote. I just want to make sure I was clear about what I was asking about, as Steve Orvell seemed to be hinting at something that would work with Shady DOM and not require falling back to Shadow DOM. On Wednesday, May 20, 2015 at 1:41:47 PM UTC-4, Justin Fagnani wrote: On Wed, May 20, 2015 at 10:36 AM, jim.j...@gmail.com wrote: Is the experimental import for avoiding Polymer.dom documented anywhere? I'd be interested in trying it out. It's not experimental, it's the same Shadow DOM polyfill that we've had for a a long time: https://github.com/webcomponents/webcomponentsjs webcomponents.js includes the full polyfill, webcomponents-lite.js doesn't. On Monday, May 18, 2015 at 8:46:20 PM UTC-4, Eric Eslinger wrote: One of the really rad things about Polymer (0.5) and webcomponents is that everything is just DOM. You can pretty easily use core- and paper- components libraries inside of an (say) angular app to render out content. Doesn't matter if you're using jQuery raw or ember or what have you- DOM is DOM, and it mostly works (modulo some property / attribute bindings) The new localDom API seems to indicate that this may no longer be the case- if I'm redistributing DOM content, I need to use the polymer dom interface, rather than just plain parent/child/append calls on document. This seems to indicate that modern polymer isn't going to be compatible with angular, or with any other library that manipulates the DOM, or is it the case that this only matters when there's more complicated shady/light manipulations? As an example, if I have content in the drawer part of a paper-drawer-panel, and then, using jquery or some other element selector, inject nodes inside of the already-projected menu div, will this break things? Or is it only the case that I need to use the local DOM api when if I'm changing the nodes that would be selected as content to project (and not their child nodes)? Is there some way to shim the document-level query selectors in there or add a mutation observer that calls distributeContent as needed? I'm guessing it was this shimming and mutation observer that contributed to the slowness of 0.5 in non-chrome browsers. I've got next week blocked out to actually work on getting angular 1.4 to play nice with polymer 0.9 (we use angular to build the page and manage data, and polymer for handy flexbox directives and material design ui bindings). So I guess I'll figure it out then. e Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/65c523d0-47b1-4786-8584-fdd2d2fd8047%40googlegroups.com https://groups.google.com/d/msgid/polymer-dev/65c523d0-47b1-4786-8584-fdd2d2fd8047%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/1c7f2a46-ee03-455f-b73f-c5090dc90873%40googlegroups.com https://groups.google.com/d/msgid/polymer-dev/1c7f2a46-ee03-455f-b73f-c5090dc90873%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit
[polymer-dev] Re: localDom API and other libraries
Just wanna make sure... If I build a web-app that targets the Chrome browser, or any browser that will have native Shadow DOM support, can I refrain from using the Polymer.dom APIs, and use native DOM APIs? On Tuesday, May 19, 2015 at 3:46:20 AM UTC+3, Eric Eslinger wrote: One of the really rad things about Polymer (0.5) and webcomponents is that everything is just DOM. You can pretty easily use core- and paper- components libraries inside of an (say) angular app to render out content. Doesn't matter if you're using jQuery raw or ember or what have you- DOM is DOM, and it mostly works (modulo some property / attribute bindings) The new localDom API seems to indicate that this may no longer be the case- if I'm redistributing DOM content, I need to use the polymer dom interface, rather than just plain parent/child/append calls on document. This seems to indicate that modern polymer isn't going to be compatible with angular, or with any other library that manipulates the DOM, or is it the case that this only matters when there's more complicated shady/light manipulations? As an example, if I have content in the drawer part of a paper-drawer-panel, and then, using jquery or some other element selector, inject nodes inside of the already-projected menu div, will this break things? Or is it only the case that I need to use the local DOM api when if I'm changing the nodes that would be selected as content to project (and not their child nodes)? Is there some way to shim the document-level query selectors in there or add a mutation observer that calls distributeContent as needed? I'm guessing it was this shimming and mutation observer that contributed to the slowness of 0.5 in non-chrome browsers. I've got next week blocked out to actually work on getting angular 1.4 to play nice with polymer 0.9 (we use angular to build the page and manage data, and polymer for handy flexbox directives and material design ui bindings). So I guess I'll figure it out then. e Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/ac30e4b1-77df-4145-b642-ee20b65bd9af%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [polymer-dev] Re: localDom API and other libraries
We have experimented with patching dom traversal and mutation api's, and there's an experimental import in Polymer that does this. It can let some libraries interoperate more smoothly with Shady DOM powered elements that, for example, perform distribution. We're continuing to work on it and explore if it should be integrated out of the box or be available as an opt in layer. See the above quote. I just want to make sure I was clear about what I was asking about, as Steve Orvell seemed to be hinting at something that would work with Shady DOM and not require falling back to Shadow DOM. On Wednesday, May 20, 2015 at 1:41:47 PM UTC-4, Justin Fagnani wrote: On Wed, May 20, 2015 at 10:36 AM, jim.j...@gmail.com javascript: wrote: Is the experimental import for avoiding Polymer.dom documented anywhere? I'd be interested in trying it out. It's not experimental, it's the same Shadow DOM polyfill that we've had for a a long time: https://github.com/webcomponents/webcomponentsjs webcomponents.js includes the full polyfill, webcomponents-lite.js doesn't. On Monday, May 18, 2015 at 8:46:20 PM UTC-4, Eric Eslinger wrote: One of the really rad things about Polymer (0.5) and webcomponents is that everything is just DOM. You can pretty easily use core- and paper- components libraries inside of an (say) angular app to render out content. Doesn't matter if you're using jQuery raw or ember or what have you- DOM is DOM, and it mostly works (modulo some property / attribute bindings) The new localDom API seems to indicate that this may no longer be the case- if I'm redistributing DOM content, I need to use the polymer dom interface, rather than just plain parent/child/append calls on document. This seems to indicate that modern polymer isn't going to be compatible with angular, or with any other library that manipulates the DOM, or is it the case that this only matters when there's more complicated shady/light manipulations? As an example, if I have content in the drawer part of a paper-drawer-panel, and then, using jquery or some other element selector, inject nodes inside of the already-projected menu div, will this break things? Or is it only the case that I need to use the local DOM api when if I'm changing the nodes that would be selected as content to project (and not their child nodes)? Is there some way to shim the document-level query selectors in there or add a mutation observer that calls distributeContent as needed? I'm guessing it was this shimming and mutation observer that contributed to the slowness of 0.5 in non-chrome browsers. I've got next week blocked out to actually work on getting angular 1.4 to play nice with polymer 0.9 (we use angular to build the page and manage data, and polymer for handy flexbox directives and material design ui bindings). So I guess I'll figure it out then. e Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/65c523d0-47b1-4786-8584-fdd2d2fd8047%40googlegroups.com https://groups.google.com/d/msgid/polymer-dev/65c523d0-47b1-4786-8584-fdd2d2fd8047%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/1c7f2a46-ee03-455f-b73f-c5090dc90873%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [polymer-dev] Re: localDom API and other libraries
On Wed, May 20, 2015 at 10:36 AM, jim.j.si...@gmail.com wrote: Is the experimental import for avoiding Polymer.dom documented anywhere? I'd be interested in trying it out. It's not experimental, it's the same Shadow DOM polyfill that we've had for a a long time: https://github.com/webcomponents/webcomponentsjs webcomponents.js includes the full polyfill, webcomponents-lite.js doesn't. On Monday, May 18, 2015 at 8:46:20 PM UTC-4, Eric Eslinger wrote: One of the really rad things about Polymer (0.5) and webcomponents is that everything is just DOM. You can pretty easily use core- and paper- components libraries inside of an (say) angular app to render out content. Doesn't matter if you're using jQuery raw or ember or what have you- DOM is DOM, and it mostly works (modulo some property / attribute bindings) The new localDom API seems to indicate that this may no longer be the case- if I'm redistributing DOM content, I need to use the polymer dom interface, rather than just plain parent/child/append calls on document. This seems to indicate that modern polymer isn't going to be compatible with angular, or with any other library that manipulates the DOM, or is it the case that this only matters when there's more complicated shady/light manipulations? As an example, if I have content in the drawer part of a paper-drawer-panel, and then, using jquery or some other element selector, inject nodes inside of the already-projected menu div, will this break things? Or is it only the case that I need to use the local DOM api when if I'm changing the nodes that would be selected as content to project (and not their child nodes)? Is there some way to shim the document-level query selectors in there or add a mutation observer that calls distributeContent as needed? I'm guessing it was this shimming and mutation observer that contributed to the slowness of 0.5 in non-chrome browsers. I've got next week blocked out to actually work on getting angular 1.4 to play nice with polymer 0.9 (we use angular to build the page and manage data, and polymer for handy flexbox directives and material design ui bindings). So I guess I'll figure it out then. e Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/65c523d0-47b1-4786-8584-fdd2d2fd8047%40googlegroups.com https://groups.google.com/d/msgid/polymer-dev/65c523d0-47b1-4786-8584-fdd2d2fd8047%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAEKsHmBBB4Ru-YP%3DzV8MNh0efK6J%3D%3DqhYj-uHeFfudRGzA14xQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [polymer-dev] Re: localDom API and other libraries
On Wed, May 20, 2015 at 12:40 PM, razb...@gmail.com wrote: Just wanna make sure... If I build a web-app that targets the Chrome browser, or any browser that will have native Shadow DOM support, can I refrain from using the Polymer.dom APIs, and use native DOM APIs? I would not do this. If you're writing code, use Polymer.dom and everything will just work, whether in a browser with native Shadow DOM or not, or using the full polyfill or not. The question here is what to do about other libraries that you don't control that don't use Polymer.dom. That's where adapters, patching or falling back to the polyfill come into play. On Tuesday, May 19, 2015 at 3:46:20 AM UTC+3, Eric Eslinger wrote: One of the really rad things about Polymer (0.5) and webcomponents is that everything is just DOM. You can pretty easily use core- and paper- components libraries inside of an (say) angular app to render out content. Doesn't matter if you're using jQuery raw or ember or what have you- DOM is DOM, and it mostly works (modulo some property / attribute bindings) The new localDom API seems to indicate that this may no longer be the case- if I'm redistributing DOM content, I need to use the polymer dom interface, rather than just plain parent/child/append calls on document. This seems to indicate that modern polymer isn't going to be compatible with angular, or with any other library that manipulates the DOM, or is it the case that this only matters when there's more complicated shady/light manipulations? As an example, if I have content in the drawer part of a paper-drawer-panel, and then, using jquery or some other element selector, inject nodes inside of the already-projected menu div, will this break things? Or is it only the case that I need to use the local DOM api when if I'm changing the nodes that would be selected as content to project (and not their child nodes)? Is there some way to shim the document-level query selectors in there or add a mutation observer that calls distributeContent as needed? I'm guessing it was this shimming and mutation observer that contributed to the slowness of 0.5 in non-chrome browsers. I've got next week blocked out to actually work on getting angular 1.4 to play nice with polymer 0.9 (we use angular to build the page and manage data, and polymer for handy flexbox directives and material design ui bindings). So I guess I'll figure it out then. e Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/ac30e4b1-77df-4145-b642-ee20b65bd9af%40googlegroups.com https://groups.google.com/d/msgid/polymer-dev/ac30e4b1-77df-4145-b642-ee20b65bd9af%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAEKsHmDBtGJP9DgKLYjgChEFWzD1AdK5toK7em7_tMQ0EH87Ww%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
