Mixed response here... >> I love the idea of making HTML imports *not* block rendering as the default behavior In terms of custom elements, this creates as a standard, the dreaded FOUC problem about which a whole different group of people will be blogging and tweeting... Right? I don't know that the current solution is entirely awesome, I'm just making sure we are discussing the same fact. Also, links in the head and links in the body both "work" though the spec disallows the later it is defacto - the former blocks, the later doesn't.... I think. This creates some interesting situations for people that use something like a CMS where they don't get to own the head upfront. > So, for what it's worth, the Polymer team has the exact opposite desire. I of course acknowledge use cases > where imports are being used to enhance existing pages, but the assertion that this is the primary use case is > at least arguable. Scott, is that because of what I said above (why polymer has the exact opposite desire)? > if we allow "Expressing the dependency in JS" then why doesn't 'async' (or 'sync') get us both what we want? Just to kind of flip this on its head a bit - I feel like it is maybe valuable to think that we should worry about how you express it in JS *first* and worry about declarative sugar for one or more of those cases after. I know it seems the boat has sailed on that just a little with imports, but nothing is really final else I think we wouldnt be having this conversation in the first place. Is it plausible to excavate an explantation for the imports magic and define a JS API and then see how we tweak that to solve all the things?
Received on Monday, 18 November 2013 23:56:30 UTC