Re: [dispatch] Dispatching Work on ECMAScript Media Types Updates

Bradley Meck <> Thu, 17 August 2017 13:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8437C132510 for <>; Thu, 17 Aug 2017 06:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ou005vT78dTE for <>; Thu, 17 Aug 2017 06:23:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BAADF12700F for <>; Thu, 17 Aug 2017 06:23:51 -0700 (PDT)
Received: by with SMTP id g35so22890698ioi.3 for <>; Thu, 17 Aug 2017 06:23:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u621bOGBxuBaLWigGJqVNaxCFJXOzzu5IGLrvYhJ3ck=; b=Ui8FqIjO9VtApKyWO74ZaHdP1aD4njihAd06AJQ+709z1rF2Yh+VtlYGX1DMgRb2Pf vdfX5PN7YFerd+AS/qGnSFH20H1hixA9140TQhttNsDFR4C6l0XmuIcec5Qm6OqRCvSx BJJbp9fNpeFVDWze/1zQc+R14OVtzRPjh2SQSoXY4qbMyD0nHZOHruklZEgXLENS2MEZ i+2ROPcbCRgss54dTUiohqYEMD7EfbduKHlbYMYmyhFFZqaDJrGaeTOuV4jRkmSFoDNC HCtbcTXI6s54L86BZ29jRjX4wjp9i0yKNb19K5IosvSQGAECoWsUr5plQtNu3F+dk+Uf 4s5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u621bOGBxuBaLWigGJqVNaxCFJXOzzu5IGLrvYhJ3ck=; b=Lht0ylvN+3D4Y7xzBD95YNyDJ8swNc234dc0xDedGeKQ9IalFHsuA2S9S4+4oErHD2 5AESu6jtXvNlh10lfQX66pMIONOPOUNm/2iRvfYe2wD13KUlBKrqichcsf6lZ9zE7Ro3 BJ8Ec6+OfT7WBms6wajKwH0+dSDHZ/weoNTJSUpxVioWNLdWj22q9ejtWXaLkrkwVvSL OAhCHRNr7IG5LySvTYJ7GDYfHyw6lheEFIVj2xg/P1dmLedDgmLOh413mAlwZ0GdPUuu TzjoOWwjZxHo9qoraSPMkCDFve+k9brRJnNTRwu5Am2oJ3RrKxk3IyHt0HEPxNzgzC+j u+oQ==
X-Gm-Message-State: AHYfb5hi0i1qNJtRxb5zsrMxtqPV5Jk6YME5VVt/+coMJnLnybaFTuya YDxQFfQD1spN3WvduQI7XA2RJwsG6zbuUMg=
X-Received: by with SMTP id e73mr4713394ioe.158.1502976230933; Thu, 17 Aug 2017 06:23:50 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 17 Aug 2017 06:23:30 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Bradley Meck <>
Date: Thu, 17 Aug 2017 08:23:30 -0500
Message-ID: <>
To: Martin Thomson <>
Cc: "Matthew A. Miller" <>, DISPATCH <>
Content-Type: multipart/alternative; boundary="001a1141ac2e59ccc00556f2ec5f"
Archived-At: <>
Subject: Re: [dispatch] Dispatching Work on ECMAScript Media Types Updates
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Aug 2017 13:24:00 -0000

Replies inline.

On Thu, Aug 17, 2017 at 6:38 AM, Martin Thomson <>

> On 17 August 2017 at 20:03, Bradley Meck <> wrote:
> >> My initial reaction to this statement was: so why aren't we seeing a
> > request for a new media type?
> >
> > This was discussed in a few different places, ultimately culminating in
> no
> > body wanting to take that route. You can read some info on that in the
> link
> > to the informative TC39 issue
> It
> > appears you might be more interested in the HTML side of things, which
> would
> > be that a new media type would not load with the specification they have
> > already started deploying ( there was an issue about this on HTML side in
> > ). Some discussion about a
> `mode`
> > parameter instead of media type is in an issue on this proposal
> > . That
> might be
> > the better route since it will work in web browsers.
> I'm not questioning the decision (though I appreciate the pointers,
> thanks), just pointing out that there is an obvious question arising
> from your introductory text.  You don't need to defend the decision,
> but you should answer that question by mentioning that link metadata
> (type=module) ensures that no one else asks the question.

Certainly, I can do that in the next version.

> The discussion (and outcome if I'm reading correctly) on #1 leading to
> mode= certainly seems sensible.  Please pick a default of mode=script
> and save us all headaches.

If and when we agree on this parameter, I think a default of mode=script
without usage restriction for .js is a good idea. A similar usage
restriction and default of mode=module on .mjs also seems reasonable.

> Question, mainly for my gratification: if I include a module in a
> <link rel=preload>, how do I signal that it's a module?  You can't use
> a type= attribute there, because that key is taken for something else
> (media type).  I know that browsers like doing things like pre-parsing
> in addition to preloading.

Interestingly code can be loaded as both Script and Module due to the
ambiguities in place in the grammars and HTML reusing the same MIME type.
This makes it difficult to know ahead of time which grammar is being used.
Pre-parsing work on top level parsing for non-ambiguous sources has been
talked about a few times, but I don't know if they are implemented.

A good example of this ambiguity is having a file only containing:

// example
console.log(this) // window in Script, undefined in Module

You can see this in practice by loading it in both grammars with 2
different script tags:

<script type="module" src="./example"></script>
<script src="./example"></script>

I have to assume that you just use native es6 modules keywords rather
> than importScript in workers, so you don't need explicit
> identification there.

There are 2 mechanisms for dealing with Modules that can be used here.

1. The `import(...)` meta function of ECMAScript ( ) will be available in both
grammars. Browsers intend to treat any javascript using import mechanisms
as a Module. This meta function is not currently landed in the
specification, but is in the process of doing so pending implementation and
deployment. Once it becomes available a worker can use `importScripts()` to
load something like the following:

// this file is to be loaded via importScripts, it is using the Script

// the following both are loaded as modules, and are loaded in parallel

2. You can declare the type of a Worker using a configuration option. See for more

> >> Nit: There Are So Many Proper Nouns In This Document.  Is that really
> >> necessary?
> >
> > I think this is in part a stylistic thing of my writing. I tend to avoid
> > pronouns and am capitalizing grammar productions in the same manner as
> the
> > ECMAScript specification. We could make stylistic changes though!
> Consistency good >> Too Many Capitals Are Bad
> (In other words, don't change on my account.)