W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2014

Re: Fetch API

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 4 Jun 2014 12:15:39 -0700
Message-ID: <CA+c2ei-L2isEF-3e46+Lo3Ut0ZmVshwNPT-bhzx29kHAfW+Jyw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Jake Archibald <jaffathecake@gmail.com>, Domenic Denicola <domenic@domenicdenicola.com>, public-script-coord <public-script-coord@w3.org>, Joshua Bell <jsbell@chromium.org>, Jungkee Song <jungkee.song@samsung.com>, Yehuda Katz <wycats@gmail.com>, Alex Russell <slightlyoff@google.com>, Tobie Langel <tobie.langel@gmail.com>, WebApps WG <public-webapps@w3.org>
On Wed, Jun 4, 2014 at 2:46 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Wed, Jun 4, 2014 at 9:49 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Wed, Jun 4, 2014 at 12:31 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> Does ES define the order of { "x": "a", "y": "b" } btw?
>>
>> I believe so, but someone would need to check. Either way I think
>> browsers effectively are forced to return a consistent order for
>> web-compat reasons.
>
> I checked. It's not true, see
> http://esdiscuss.org/topic/for-in-evaluation-order#content-10

Ah. So the enumeration order for { "x": "a", "y": "b" } is actually
consistent across browsers. But once you start doing more complex
things than that, like sticking enumerable properties on the prototype
chain, or deleting properties, then the order is not consistent.

I would still be ok with allowing a plain JS object being passed. If
differences in order for "complex" operations hasn't bitten people for
JS enumeration, then maybe it won't for header order either.

/ Jonas
Received on Wednesday, 4 June 2014 19:16:40 UTC

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