- 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