Did you check if we could change behavior of existing display?

[kenchris]

Did you check how the implementations work today in WebKit, Firefox and Chrome? like what happens if you define two "display" members and one with an array instead. Maybe there is a way to change the behavior of "display" without breaking existing implementations?

https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/Modules/applicationmanifest/
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/common/manifest/

[dmurph]

I'm not sure if having two 'display' members, where maybe order matters, is going to be better than a new member...

From the code it should error if the field is not a string. I don't know what will happen if there are two fields with the same name.

[dmurph]

To clarify, in chrome this is where the display is parsed:
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/modules/manifest/manifest_parser.cc;l=140;drc=b399c8b19ba8dbca0fcd2943ae5f034cd3e87f4a?q=manifest_parser.cc&ss=chromium

The JSON deserializer will overwrite old key entries with new ones:
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/platform/json/json_values.h;l=214;drc=b399c8b19ba8dbca0fcd2943ae5f034cd3e87f4a

So while not an error, only the last entry with a given key will be considered in the blink json parser.

I found the same code in webkit:
https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/JSONValues.h#L385

So there is technically a way for us to do this, where developers would have two 'display' fields, and the one that comes last is the one that old browsers parse, and somehow new browsers would be able to pull out the earlier fields and use those (so they could be an array)

I still find this a little confusing - I kind of like the suggestion in #10 where we just create a new field here that new browsers will allow use of instead of display. WDYT about that?

@mgiuca WDYT here?

[mgiuca]

I went to check the JSON spec as to whether this would even be allowed at that basic level: ECMA-404§6:

The JSON syntax does not impose any restrictions on the strings used as names, does not require that name strings be unique, and does not assign any significance to the ordering of name/value pairs. These are all semantic considerations that may be defined by JSON processors or in specifications defining specific uses of JSON for data interchange.

So it's allowed by JSON, and technically could be allowed by the Manifest spec.

However, the Manifest spec currently uses the ECMAScript JSON parser. That parser explicitly parses a JSON object as a JavaScript object, which discards duplicates (preserving the last entry of a set of duplicated keys). So if we wanted to do this, we would have to write our own JSON parser.

I don't think it's a very good idea to rely on this ability. As @dmurph shows, JSON processors are likely to store the parsed data in a hash map which discards duplicates and shuffles the order of the keys. Even if we write it correctly, it's confusing for a human reader who may be accustomed to the {key: value} syntax meaning an orderless unique-keyed dictionary. I'd rather not write a spec that is sensitive to the order of duplicate keys (other than simply saying "if duplicate keys are found, discard all but the last").

If we wanted to define two display members, where the order matters and the first and second one have different semantics, then you are really defining two different members.

[dmurph]

I agree. I'm closing this, feel free to re-open if you feel strongly about this :)