- From: <bugzilla@jessica.w3.org>
- Date: Mon, 26 Aug 2013 16:15:42 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23069 Bug ID: 23069 Summary: [Custom]: Elements in HTML Imports should upgrade as if imports blocked parsing Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglazkov@chromium.org Reporter: sorvell@chromium.org QA Contact: public-webapps-bugzilla@w3.org Blocks: 14968 Consider a custom element that declares other custom elements. See, for example, <polymer-element> (https://github.com/Polymer/polymer) which is similar to the deprecated <element> element. It's common to want to place dependencies in HTML Imports. Consider this setup: main document: <script src="polymer.js"></script> // registers polymer-element <link rel="import" href="x-a.html"> <polymer-element name="x-b" extends="x-a">...</polymer-element> x-a.html: <polymer-element name="x-a">...</polymer-element> In this case, because HTML Imports are non-blocking, the import will parse after the main document and the definition for x-a will not be available by the time x-b wants to extend it. Ideally, in the presence of HTML Imports custom elements would upgrade in the same order as if imports were blocking (e.g. polymer-element x-a upgrades before polymer-element x-b). Although placing the script element after the x-a import would also address this use case, it would be unfortunate if this were required because it makes loading the import block parsing the main document. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 26 August 2013 16:15:44 UTC