PIE VS json5-spec

One thing (only thing) I honestly miss about IE5.5-8 is how amenable the engine was to polyfilling. It wasn't fast, but you could do almost anything with the right polyfill technique. No sessionStorage? Use window.name. No (then-) modern CSS? Use CSS3PIE [0] IE doesn't support the transform CSS property? Use an *.htc behavior to convert the transform to a matrix filter.

It was madness, and it was beautiful in a Cthulhu kind of way.

[0] http://css3pie.com/

Ah, CSS expressions. So many memories of making IE6/7 polyfills in 2011. Without CSS expressions and behaviors, wonderful tools like CSS3PIE would never have been possible.

https://github.com/lojjic/PIE

As painful as IE6 and IE7 were in the late 2000s/early 2010s, they were surprisingly polyfillable (at a speed cost).

One of the larger issues I've run into is duplicates. Douglas Crockford, JSON's inventor, tried to fix the duplicate issue but it was decided it was too late. Although Douglas Crockford couldn't change the spec forcing all implementations to error on duplicate, his Java JSON implementation errors on duplicates. Others use last-value-wins, support duplicate keys, or other non-standard behavior. The JSON RFC states that implementations should not allow duplicate keys, notes the varying behavior of existing implementations, and states that when names are not unique, "the behavior of software that receives such an object is unpredictable." Duplicate fields are a security issue, a source of bugs, and a surprising behavior to users. See the article, "An Exploration of JSON Interoperability Vulnerabilities" Disallowing duplicates conforms to the small I-JSON RFC, which is a stricter JSON. The author of I-JSON, Tim Bray, is also the author of JSON RFC 8259. See also the JSON5 duplicate issue.

Virtually any sequence is not the same as adopting a specification five years after it’s been published and adopted by industry: https://spec.json5.org/

I appreciate that SQLite can’t write the format, because those changes are human afordances

That's why you pick a superset of JSON that already has some adoption, like JSON5: https://spec.json5.org/

The "dual" standard RFC 8259 [1] (both are normative standards under their respective bodies, ECMA and IETF) is also a useful comparison here. It's wording is a bit stronger than ECMA's, though not by much. ("Good interoperability" is its specific call out.)

It's also interesting that the proposed JSON 5 (standalone) specification [2] doesn't seem to address it at all (but does add back in the other IEEE 754 numbers that ECMA 404 and RFC 8259 exclude from JSON; +/-Infinity and +/-NaN). It both maintains that its numbers are "arbitrary precision" but also requires these few IEEE 754 features, which may be even more confusing than either ECMA 404 or RFC 8259.

[1] https://datatracker.ietf.org/doc/html/rfc8259#section-6

[2] https://spec.json5.org/#numbers

For anyone coming back to this, I just wrote a small proposal to define JSON5 duplicate object name behavior. I'd love any support on the issue:

https://github.com/json5/json5-spec/issues/38