addyosmani
Using platform.js to get this working on Firefox
I had to make some compromises - document.querySelector('#template') within the component definitions was returning null. In Chrome it appears that calling the IIFE with document.currentScript.ownerDocument gives you the right (isolated) context, but in Firefox w/ platform.js that is returning the main document for index.html, which doesn't have a #template element, and it returns null. So instead of fighting with something I didn't understand, I decided to move the templates into index.html, change the IIFE invocation to simply document and see what happened. And it worked :bangbang: :sunglasses:
This sort of stuff is really exciting to me. It was only when I realised that Polymer and Platform were different and might be able to used separately, and the pace at which native implementations have reached Chrome, that I started to think that we could do 'raw' Web Components cross-browser, now. Which I would like very much for x-gif :)
One final thought, how easy would it be to detect native support for the Web Components features in the browser and conditionally load platform.js?
Thanks for putting this example together!
Update, with even more success!
Using both document and document._currentScript.ownerDocument in the component definition gets this working with the templates back where they started. This now means that platform.js needs to be loaded, even in Chrome, but a workaround for that is surely possible.
Currently in Safari 8 nothing works - getting TypeError: Attempted to assign to readonly property. But that's the same on http://www.polymer-project.org so I'm guessing that's a LOLYOSEMITE bug at the moment.
Thanks for the continued work on this!. What would you think about us offering up a version that works without platform.js and one that works everywhere using it? This might help those who run into similar native vs. issues further down the line.
Yep that'd be the way to go I think. A single version that works with or without platform.js, so it's dependecy-free on Chrome and only one file needed for everything else :)
What is document._currentScript actually doing in this case?
I'm going to be converting x-gif to this style this week then talk about it as Cascadia, so I might ping you with a few more questions.
Figured out what appears to be a minimal set of feature detects to avoid loading platform.js, and then using (document._currentScript || document.currentScript).ownerDocument means if the shim is present it gets used, otherwise use the native implementation. That's enough to get it working with minimal dependencies in both browsers.
I have to apologize for taking forever (1 week!) to get back to you, but https://github.com/geelen/componentized-todo/commit/3e5112136b46b86b8e394d2601230fb6c78f61fc is really hawt. Nice work, @geelen. Is that the only set of changes that are now required to get this puppy working?
When trying with Firefox/Nightly (34.0a1 on http://mcepl.github.io/componentized-todo/) I get this error when storing TODO item:
12:05:05.687 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://fonts.gstatic.com/s/robotodraft/v2/u0_CMoUf3y3-4Ss4ci-VwR_xHqYgAV9Bl_ZQbYUxnQU.woff. This can be fixed by moving the resource to the same domain or enabling CORS. u0_CMoUf3y3-4Ss4ci-VwR_xHqYgAV9Bl_ZQbYUxnQU.woff
12:05:30.964 TypeError: todoItem.shadowRoot is null component.html:186
Confirmed that I'm seeing the same error as above in the latest FF Nightly builds. Investigating.
Line that is likely to blame: https://github.com/addyosmani/componentized-todo/blob/gh-pages/components/todo-app/component.html#L186