- From: Dimitri Glazkov <dglazkov@google.com>
- Date: Tue, 26 Mar 2013 08:59:22 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: public-webapps <public-webapps@w3.org>, Elliott Sprehn <esprehn@gmail.com>, Angelina Fabbro <angelinafabbro@gmail.com>, Brian Kardell <bkardell@gmail.com>, Steve Orvell <sorvell@google.com>, Ryan Seddon <seddon.ryan@gmail.com>, Ladislav Thon <ladicek@gmail.com>, Dominic Cooney <dominicc@google.com>
Splitting off the thread for sanity. On Tue, Mar 26, 2013 at 6:16 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > I think I'd like to know the scope of what this feature might evolve > into. If this features is going to be used eventually to instantiate > components through markup the fetching security model used might not > be the best one. It would give the embedding page about as much > trouble as it gets via including <script> cross-origin today. There is one big part that will effectively fill out the scope: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21215 After all resources are loaded and processed, we'll need to process <element> instances, in reverse order of loading. Processing means: 1) Registering a custom element, specified by this <element>. This will involve running its children <script> elements with some special rules. 2) Running element upgrade: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-element-upgrade As for the fetching security model, I have a bug for this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21226. Please guide me, would love your fetch-spec-writing experience :) As an additional wrinkle, the webdevs really want this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21229 :DG<
Received on Tuesday, 26 March 2013 15:59:54 UTC