Re: @supports-like feature on <script> tag

On Fri, Feb 6, 2015 at 9:44 AM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
> As far as we are planning to provide low-level APIs so that libraries can do
> more polyfill before a feature gets standardized, I propose that we add an
> attribute to <script> tag similar to @supports rule in CSS, which enables
> the UA to avoid loading modules which try to polyfill features it supports.
>
> However, the @supports rule provides a positive matching, while it'd be
> better to have a negative matching syntax here. In addition, it probably
> should not be limited to CSS features.

JS has the capability to do this by itself pretty easily - just do a
feature test of some kind and import conditionally based on that.

Also, we already did this once; it was called .hasFeature(), and it
was a giant failure.  The list of "feature name"=>"support" mappings
is completely disconnected from whether or not the actual feature is
supported, and to what degree/bugginess it is.  Due to this,
.hasFeature() got totally polluted with nonsense and became almost
completely useless.

@supports was specifically designed to avoid the same pitfalls - it is
based on parsing actual CSS, and we all already have policies about
not parsing things we don't support (and when we mess it up, authors
scream bloody murder at us).  It also lets you ask about *specific*
features at whatever granularity you desire, rather than having to
figure out what set of names are useful to have people ask about.

I don't think this can be done reasonably for JS.  Just stick with
feature testing.

~TJ

Received on Thursday, 5 February 2015 23:08:29 UTC