No thanks to Mr. Crawford for not fixing the \u2028-9 issue. JSON as defined is not a subset of javascript. It is a design mistake that was pointed out to him years ago, but he is too stubborn or arrogant to fix it.
Trailing commas would make the problem worse! If you allow trailing commas then you would break json parsing in all old version of IE. The unicode line ending problem is more subtle.
I have seen people write code like (mix javascript and some templating):
<script>
var prefs = <%= user_prefs.to_spec_conforming_json() %>;
...
The above code looks okay, but if the json is just spec conforming, then you are exposed to a potential XSS attack.
Most people that write json encoders are aware of the problem, but why publish a a spec that can potentially create serious security problems?
I suppose you have a better way to do cross-platform cross-domain APIs? Enlighten us. Facebook and Google use this method, and I assume it is because there isn't a better way.
You can use CORS [1] on browsers that support it. [2] You really should use it if at all possible given your application's constraints, so you don't have to abuse GET requests and can use a JSON parser.
Unfortunately CORS is not really doable if you have to support IE and need non-cookie authentication, as my company recently discovered to our sorrow. No custom headers, so goodbye to your X-Auth-Token. That has only been fixed in IE10.
Developing nations have a tendency to not use the latest and greatest. If reaching them is important for you/your product then you have to keep tracking this stuff.
I'm not sure about this but a lot of software might have been written specifically for IE6 and IE6 only, which might not translate well to Chrome/Firefox, and could cost businesses a lot of money, more money than they deem its worth. There could be ActiveX controls and such which can't be ported to Chrome/Firefox without money.
This is based on my experience at UPS which used a single machine using IE6 and some form of web app to control start up and shut down procedures, or something to that effect. It had no Internet connection, only LAN I believe.
I did ask myself this question too and it does seem peculiar. After some thought, my only guess is the above!
> There could be ActiveX controls and such which can't be ported to Chrome/Firefox without money.
South Korea is a huge example of this. When online banking first came to market, the only way to do it legally in South Korea was through ActiveX controls embedded in Internet Explorer because they had specific encryption requirements in the 1990s versus what IE or other browsers supported natively.
Even as recent as last year [1] it was a big deal in elections, with at least one candidate promising to end the legal requirements and allow banks to enter the modern age of browsers.
Don't they have another browser around for dealing with the rest of the world though? It's not like many modern sites are going to render correctly on IE6 these days...
No, not really. The JSON standard says you can't put raw newlines in strings, and you must write \n. Why does it say it is okay to put raw unicode line_separator rather than requiring \u2028 ? Two more lines to the spec, and DC's variant of JSON would actually be a subset of Javascript. Instead we are left with an edge case that we are going to have to worry about for the next 20 years.