W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2014

Re: HTML imports in Firefox

From: Brian Kardell <bkardell@gmail.com>
Date: Mon, 15 Dec 2014 16:37:58 -0700
Message-ID: <CADC=+jfRi5Or-aKWn2UJyj_fPvR4Ut0fkT4bp7gpdg0dLu59Bw@mail.gmail.com>
To: Ashley Gullen <ashley@scirra.com>
Cc: public-webapps@w3.org
Very generally: this is actually why I said way back that a lot of things
seem like prollyfills (we hope that's the future) rather than polyfills
(it's a done deal) and advocated we make sure it's a future-safe, forward
compatible approach.

On Dec 15, 2014 4:06 PM, "Ashley Gullen" <ashley@scirra.com> wrote:
>
> On 15 December 2014 at 19:09, Boris Zbarsky <bzbarsky@mit.edu> 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.

The p(r)olyfill is actually pretty decent and not huge, smaller than a lot
of module loaders.  For such an integral kind of platform feature, if we
have a fairly nice  polyfill and things are potentially still debatable and
there are legit seeming wants that aren't met, why not use it?

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?

Currently, I agree, some of us are working on that so that we tighten the
feedback loop with both positive and negative feedback without overwhelming
the system.

>
> On 15 December 2014 at 19:09, Boris Zbarsky <bzbarsky@mit.edu> 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
>>
Received on Monday, 15 December 2014 23:38:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:32 UTC