This same claim could be made about every item in ECMAScript.
Implementation variation in ModuleSpecifiers is no different from variation
in the allowed keywords, character set, or really anything a developer
types. Failing to specify this aspect of the language makes no sense to
this developer
Don't worry. It is going to be spec'ed as part of the module loader spec.
http://whatwg.github.io/loader/
On Mon, Jun 1, 2015 at 10:47 AM John Barton johnjbar...@google.com wrote:
This same claim could be made about every item in ECMAScript.
Implementation variation in ModuleSpecifiers is no
Who is failing to do what now? :-/
/be
John Barton wrote:
This same claim could be made about every item in ECMAScript.
Implementation variation in ModuleSpecifiers is no different from
variation in the allowed keywords, character set, or really anything a
developer types. Failing to
It is syntactically valid, but there is no specification for what the module
specifier string should contain. Traceur has one rule, and if you’re using
Traceur you need to follow Traceur’s rules. I’m sure other transpilers have
their own chosen rules.
In a hypothetical future where browsers
Browsers in any semi-competitive market will agree on a standard. I
don't see why that needs to be called into doubt, even as part of a
hypothetical future :-|. (Is there another kind? :-P)
/be
Domenic Denicola wrote:
Yes, in theory. However, browsers are more likely to wait until
there’s a
Are you saying that in the future each browser can have its own rule for
module specifier strings?
On Sun, May 31, 2015 at 4:31 PM, Domenic Denicola d...@domenic.me wrote:
It is syntactically valid, but there is no specification for what the
module specifier string should contain. Traceur has
@mozilla.org
Subject: Re: import ModuleSpecifier
Are you saying that in the future each browser can have its own rule for module
specifier strings?
On Sun, May 31, 2015 at 4:31 PM, Domenic Denicola
d...@domenic.memailto:d...@domenic.me wrote:
It is syntactically valid
7 matches
Mail list logo
