Native HTMLImports support in the next Polymer release

297 views
Skip to first unread message

Steve Orvell

unread,
Jan 23, 2014, 5:48:06 PM1/23/14
to polym...@googlegroups.com

In today's release... Polymer now supports native HTMLImports!


If you turn on the ‘Enable HTML Imports’ flag in Chrome Canary, Polymer should seamlessly work and take advantage of native imports.


We’re also now providing a new event called ‘polymer-ready’.


Use the ‘polymer-ready’ event to know when all the polymer elements that have been loaded are upgraded and ready for use. Previously we recommended using the ‘WebComponentsReady’ event for this purpose but we’re now providing an explicit event because element upgrade timing has changed.


Here’s some additional info...


In enabling support for native imports, we’ve moved some features that are not supported by native imports out of the polyfill and into Polymer. Fixing url attributes and loading stylesheets in templates inside polymer-element’s are now both the responsibility of Polymer.


Because of the need to avoid FOUC, it’s important that element stylesheets are loaded prior to rendering. To keep things simple, we’re delaying element registration until these resources are ready. This means that polymer needs a new signal to indicate that elements are ready; thus, ‘polymer-ready’.


There’s still more work to do. The HTMLImports polyfill does not yet support imperatively constructed imports. We’re working on addressing that right now. Once we have this, we plan to demonstrate how bundles of elements can be easily loaded and used asynchronously, on demand.


Please let us know if you have feedback or discover issues.


Hajime Morrita

unread,
Jan 23, 2014, 9:14:37 PM1/23/14
to Steve Orvell, polym...@googlegroups.com
Great work Steve!!

I'd live to have people actually try the native import and see if your components work with it. If it breaks your thing, it might just hit the incompatibility edge between native and polyfill, or it might hit some real bug. Please let us know if you see any problem around HTML Import. You can file either poymer bug or crbug.com for that.

I'm thinking to merge --enable-html-imports flag to --enable-experimental-web-features once all major bugs are fixed so that we can exercise the native code more broadly. 

--
morrita




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/CA%2BrMWZg%3DTeFUBx61%2B74YoDDMCoVza76v1Z%2B1n2Nydwj-99DnoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Steve Orvell

unread,
Jan 23, 2014, 10:51:38 PM1/23/14
to Hajime Morrita, polym...@googlegroups.com
Merging the flags sounds good to me.

Eric Bidelman

unread,
Jan 23, 2014, 10:52:56 PM1/23/14
to Steve Orvell, polymer-dev

Awesome work. This is huge! I do have a couple of questions:

What (if anything) should the WebComponentsReady signal be used for now?

The polymer-ready event is only relevant when using imports, correct?

Has there been any further discussion on prollyfilling an async attribute on link[rel=import]? Or, will dynamically created imports be enough?

Steve Orvell

unread,
Jan 23, 2014, 11:02:26 PM1/23/14
to Eric Bidelman, polymer-dev
What (if anything) should the WebComponentsReady signal be used for now?

It's primarily useful when platform.js or HTMLImports + CustomElements polyfill are used without polymer.

When native imports is used, a script tag in the main document blocks the loading of imports so you can be sure that any imports have loaded and any registered elements have been upgrade. This behavior is difficult to polyfill so we don't try. Instead the WebComponentsReady event is a stand in for this behavior.

The polymer-ready event is only relevant when using imports, correct?

No, it's always necessary. Polymer elements support resources that require loading (stylesheets) and we've chosen to register them only when these resources become available. Therefore you can only be assured that polymer has registered and upgraded elements at polymer-ready time.

Has there been any further discussion on prollyfilling an async attribute on link[rel=import]? Or, will dynamically created imports be enough?

Yes, there has. Step 1 is to support dynamic imports in the polyfill. At that point we may choose to create a polymer-import element that is a stand in for link with async attribute. This should be enough for exploration.

Addy Osmani

unread,
Jan 24, 2014, 7:23:53 AM1/24/14
to polym...@googlegroups.com

This is fantastic. Thanks, Steve!
 

We’re also now providing a new event called ‘polymer-ready’.


Use the ‘polymer-ready’ event to know when all the polymer elements that have been loaded are upgraded and ready for use. Previously we recommended using the ‘WebComponentsReady’ event for this purpose but we’re now providing an explicit event because element upgrade timing has changed.


So, our previous advice around 'WebComponentsReady' has been if you prematurely fetch an element from the DOM before it has a chance to upgrade you'll run into issues and you should instead wait for this event to fire before trying to interact with the element. 

Given your notes to Eric below, are we now saying that polymer-ready should instead be used to 100% guarantee Polymer elements and their dependencies are loaded? In which case..

- WebComponentsReady: only use if you're working with the polyfills and not Polymer
- polymer-ready: opt for this if you are using Polymer, it's timing is more reliable.

Is that right?

Sam Carecho

unread,
Jan 24, 2014, 10:13:05 AM1/24/14
to Eric Bidelman, Steve Orvell, polymer-dev
Great question. 
This was something I was in doubt about.



Steve Orvell

unread,
Jan 24, 2014, 10:22:58 AM1/24/14
to Sam Carecho, Eric Bidelman, polymer-dev
- WebComponentsReady: only use if you're working with the polyfills and not Polymer
- polymer-ready: opt for this if you are using Polymer, it's timing is more reliable.
Is that right?

Exactly right.

Mark Moissette

unread,
Jan 24, 2014, 10:39:15 AM1/24/14
to polym...@googlegroups.com, Sam Carecho, Eric Bidelman
Thanks for posting this !
Had updated my bower dependencies this morning and was wondering why I had different behaviour in the WebComponentsReady callback !

David Marr

unread,
Jan 25, 2014, 11:05:34 AM1/25/14
to polym...@googlegroups.com
Did this break support for the polyfilled HTMLImports? I see the following error in Chrome (non-canary):
Uncaught ReferenceError: HTMLImports is not defined 

I do see things work when using Canary, but I would like to have non-native support for people not using Canary.
Thanks,
Dave

Steve Orvell

unread,
Jan 27, 2014, 11:31:38 AM1/27/14
to David Marr, polym...@googlegroups.com
No, that's unexpected. Can you provide more info? What version of Polymer are you loading? How are you loading Polymer? Thanks.

The release did get delay by a couple of days due to misc bugs. We should have it out early this week.


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.
Reply all
Reply to author
Forward
0 new messages