On 15 December 2014 at 19:09, Boris Zbarsky <[email protected]> wrote: > > > But more to the point, we're not shipping imports because we've gotten > feedback from a number of people that imports are not solving the problems > they actually need solved. We'd prefer to not ship imports and then need > to ship yet another HTML import system that solves those problems. >
Well, imports work better for us than Javascript modules, for the reasons I gave. I hadn't given any feedback because everything looked great with HTML imports and I was simply waiting for it to arrive in browsers. Maybe the process biases feedback towards the negative? I guess you never hear the chorus of "cool, can't wait!" from everyone looking forwards to it? On 15 December 2014 at 19:09, Boris Zbarsky <[email protected]> wrote: > > On 12/15/14, 1:10 PM, Ashley Gullen wrote: > >> Why would modules affect the decision to ship HTML imports? >> > > Because the interaction of the various import systems with each other > needs to be specified, for one thing. > > But more to the point, we're not shipping imports because we've gotten > feedback from a number of people that imports are not solving the problems > they actually need solved. We'd prefer to not ship imports and then need > to ship yet another HTML import system that solves those problems. > > The webcomponents.org <http://webcomponents.org> polyfill for imports >> has a couple of caveats, so it doesn't look like it's totally equivalent >> and portable with browsers with native support, like Chrome which has >> shipped it already. >> > > Chrome has shipped a lot of things in this space already. Feel free to > mail me privately for my feelings on the matter. chrome shipping something > is not sufficient reason to ship something we're pretty sure is deficient, > I'm afraid. > > -Boris > >
