Mark S. Miller
erights at google.com
Thu Sep 29 18:46:17 UTC 2016
On Thu, Sep 29, 2016 at 9:25 AM, Alexander Jones <alex at weej.com> wrote:
> Maybe we should just make U+2028 and U+2029 valid in JS then? What other
> productions in JSON are invalid syntax in JS?
IIRC, Doug Crockford, possibly Mike Samuel, and I (and perhaps others)
advocated such a change to EcmaScript back during the transition from ES3
to ES3.1/ES5. ES differed enough between platforms in other ways that, some
of us felt, it would have been worth the experiment to see if we could get
away with it -- without breaking the web. We were not able to convince
people to engage in that experiment then. Such an experiment would be much
more expensive now, with a much lower probability of success, and with a
lower payoff. I don't see it happening.
> On Thursday, 29 September 2016, Mike Samuel <mikesamuel at gmail.com> wrote:
>> On Thu, Sep 29, 2016 at 8:45 AM, Oriol Bugzilla
>> <oriol-bugzilla at hotmail.com> wrote:
>> >> ECMAScript, while highly used in web browsers, should really not care
>> >> about HTML constructs. That's where WHATWG and W3C come in. I suggest
>> >> type of feature should come from one of those groups, not ECMA.
>> > That applies to escaping things like `</script>` or `]]>`, and I agree.
>> > as Mike Samuel mentioned, JSON strings containing U+2028 or U+2029 are
>> > valid JS expressions. I think it would make sense for `JSON.stringify`
>> > escape these.
>> What is it that you're saying is not in TC-39's bailiwick?
>> Is it that w3c/whatwg should define what constitutes "embeddable JSON"?
>> Or is it that if it's worth defining a function that produces
>> embeddable JSON from an EcmaScript object, that w3c/whatwg should
>> include that in some set of EcmaScript APIs that it defines?
>> If you agree with my earlier claim
>> We're talking about JSON serializers. Every serializers produces
>> a subset of the output language. Choices about that sublanguage affect
>> how easy/hard it is to use that serializer with other tools.
>> then it seems that TC-39 might take embeddability into account when
>> crafting the subset of JSON that JSON.stringify produces.
I agree that this issue belongs with TC39 much more than it belongs
anywhere else. TC39's steering of JS is certainly influenced by how JS gets
used in web browsers. When an issue touches both JS and browser specific
concerns, it can often be unclear whose "jurisdiction" it belongs in. This
one is not unclear. It should be treated as a language issue by TC39.
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss