23206 2013-09-11 04:31:56 +0000 [Custom]: The base element queue doesn't prevent custom element processing running ahead of imports 2013-09-11 21:11:45 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC Linux RESOLVED FIXED P2 normal --- 14968 1 dominicc dglazkov public-webapps-bugzilla oldest_to_newest 93224 0 dominicc 2013-09-11 04:31:56 +0000 Maybe I just don't understand the set of related specs well enough, but I don't see anything which stops custom element processing in a given document running ahead of imports in that document. The base element queue is sorted, and things are enqueued in it in a certain order, but it is unclear given: <x-a> <link rel="import" href="two.html"> <x-b> two.html: ... <x-c> ... that x-a, x-b, x-c isn't a valid order provided that x-a, x-b are run at one microtask checkpoint and x-c is run at another. 93227 1 dominicc 2013-09-11 06:52:38 +0000 Here's a stab at a more operational algorithm that I think might be feasible: There is a DOCUMENT QUEUE. Each document has a BASE ELEMENT QUEUE. When the parser pops an Custom Element, frazzle the element. Additionally, when a <link rel="import" ...> is inserted into a document, frazzle that element too. To frazzle ELEMENT: If ELEMENT's owner document is not in DOCUMENT QUEUE: Insert ELEMENT's owner document into DOCUMENT QUEUE If ELEMENT is not in owner document's BASE ELEMENT QUEUE: Insert ELEMENT into owner document's BASE ELEMENT QUEUE At a microtask checkpoint: For each DOCUMENT in DOCUMENT QUEUE: If DOCUMENT "is an import"*: Skip DOCUMENT Otherwise: Process DOCUMENT's BASE ELEMENT QUEUE * Being an import is a dynamic condition. If the <link> tag that begot you orphans you, you're not an import any more? (I didn't do any DOCUMENT QUEUE emptying. The BEQs become empty so repeatedly processing them is a no-op. But an implementation would remove a document that has finished parsing from the DOCUMENT QUEUE.) To process a BEQ: For each ELEMENT in BEQ, in order: If ELEMENT is an IMPORT: If ELEMENT has an imported document: Process the ELEMENT's imported document's BEQ (ie recurse). If the ELEMENT's IMPORT READY FLAG is not set: Stop these steps. Commentary: Everything (including the link element) is left in BEQ for next time. Remove ELEMENT from the BEQ Process ELEMENT's associated CALLBACK QUEUE (if any) Commentary: There are complicating factors motivating this craziness: - <link rel="import" ...> can be inserted and removed, bringing multiple documents into existence as it does so (I think?) so we need the document queue as a catch-all to make sure we eventually start calling people's callbacks. - <link rel="import" ...> doesn't necessarily have an associated document, so we need to use the link tags themselves to keep track of things. The ordering is going to be defined, but extremely wild, if you move a link tag (particularly to a different document.) The wildness if because we use a link tag to find a document to recurse to, but that might not be the one begotten from that insertion; time might have marched on? You get what you deserve. 93259 2 dglazkov 2013-09-11 17:32:17 +0000 (In reply to Dominic Cooney from comment #0) > Maybe I just don't understand the set of related specs well enough, but I > don't see anything which stops custom element processing in a given document > running ahead of imports in that document. The base element queue is sorted, > and things are enqueued in it in a certain order, but it is unclear given: > > <x-a> > <link rel="import" href="two.html"> > <x-b> > > two.html: > ... > <x-c> > ... > > that x-a, x-b, x-c isn't a valid order provided that x-a, x-b are run at one > microtask checkpoint and x-c is run at another. You're right! If: 1) the queue is in this state: [ x-a, @, x-b ], where "@" is the import that has not loaded, 2) parser yields and the microtask checkpoint occurs, 3) the callbacks for x-a and x-b will be invoked, and x-c will be invoked later. 93271 3 dglazkov 2013-09-11 21:10:05 +0000 (In reply to Dominic Cooney from comment #1) In spec, I think I can express this in just a few sentences. Let me give it a shot. > Commentary: > > There are complicating factors motivating this craziness: > > - <link rel="import" ...> can be inserted and removed, bringing multiple > documents into existence as it does so (I think?) so we need the document > queue as a catch-all to make sure we eventually start calling people's > callbacks. Adding and removing import links imperative means that: 1) we're no longer operating on base element queue, and 2) all fetches are synchronous This helps greatly, since this makes all these operations atomic and we don't need to worry about stability of order (or ordering at all). > - <link rel="import" ...> doesn't necessarily have an associated document, > so we need to use the link tags themselves to keep track of things. > > The ordering is going to be defined, but extremely wild, if you move a link > tag (particularly to a different document.) The wildness if because we use a > link tag to find a document to recurse to, but that might not be the one > begotten from that insertion; time might have marched on? You get what you > deserve. I think it's same as above. I could be wrong. This is complicated stuff :) 93272 4 dglazkov 2013-09-11 21:11:45 +0000 https://dvcs.w3.org/hg/webcomponents/rev/ae75ca747696, WDYT?