Closed Bug 907860 Opened 7 years ago Closed 7 years ago
We can implement a WebComponents polyfill to load custom elements from external HTML documents. We should see significant performance improvements for apps which do not yet lazy load the DOM, and cleaner code for those that do. This also has the benefit of pushing future standards. The polyfill could make use of XHR to populate DOM nodes if they are not yet loaded. Unfortunately due to the latency of XHR, we need some kind of local caching. E-mail app is doing something similar, and is caching with cookies. I think the polyfill should be based on the following: 1 - Build time step to populate comment nodes within template files. 2 - Shared runtime script to populate nodes from comment nodes. 3 - DEBUG script to load external files on demand.
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Comment on attachment 793683 [details] Github pull request pointer James - going to mark you as reviewer of this one. See bug 907907 for an example of actual implementation.
Attachment #793683 - Flags: review?(jlal)
Comment on attachment 793683 [details] Github pull request pointer Vivien - would be great if you get a chance to review this as well.
Comment on attachment 793683 [details] Github pull request pointer Kaze - adding you for feedback here as this was in some way inspired by the settings app.
Comment on attachment 793683 [details] Github pull request pointer My outstanding question is should templates be able to import other templates? Is that spec'ed somewhere? I seem to recall that they should and if so we should have a followup bug filed to add that behavior.
Attachment #793683 - Flags: review?(jlal) → review+
(In reply to James Lal [:lightsofapollo] from comment #5) > Comment on attachment 793683 [details] > Github pull request pointer > > My outstanding question is should templates be able to import other > templates? Is that spec'ed somewhere? I seem to recall that they should and > if so we should have a followup bug filed to add that behavior. I think that is a powerful and exciting thing to think about. I don't see harm in adding to the polyfill as required by gaia developers. I think doing that in a follow-up would be fine though.
Comment on attachment 793683 [details] Github pull request pointer Giving r+ here approving the new file in shared/js/ I haven't checked the code, but like the idea behind this.
Attachment #793683 - Flags: review+
Comment on attachment 793683 [details] Github pull request pointer I think we're going to go ahead and land this one. If you guys have any further feedback/issues please note here or open a new bug. Thanks!
Landed in master: https://github.com/mozilla-b2g/gaia/commit/058c90186385b9556b70da6196d704edab87e256
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
web_components.js only seems to implement the HTML Imports spec: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/imports/index.html as linked from section 7 of the WebComponents spec: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html#imports-section Would it be better to fix-up the file name and document things so that it's clear we're only polyfilling HTML imports? like html_imports_polyfill.js? I worry that if we throw around the term 'web components' people are going to expect the more exciting magic bits. Oops; bugzilla mid-air and I see this has now landed: I can file a spin-off bug if there's agreement.
Hi Andrew, The plan is to follow spin-offs and implement as desired by gaia folks. We implemented the polyfill with performance in mind, hence the caching in DOM instead of async XHR requests at request time. I'm just concerned about performance impacts of a polyfill that implements *everything*. I would like us to support some of the other magic bits as long as they are performant. I am not against renaming the file to html_imports_polyfill. If you feel like there is anything specific you would like to see, please file a bug :)
You need to log in before you can comment on or make changes to this bug.