On Wed, May 20, 2015 at 12:40 PM, <[email protected]> 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 [email protected].
> 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=email&utm_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 [email protected].
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.

Reply via email to