On 6 June 2013 14:25, Jeremy Darling <jeremy.darl...@gmail.com> wrote:
> Thinking about this for JSON that means that if you were wanting to > serialize a complete object (prototype, setters, getters, etc) you would > then have to escape all of those as well. Since JavaScript doesn't really > have a standard symbol for stating "This is a control key" then dev's would > have to code for all possible key words in their escape/unescape sequence. > > Or the spec would have to be amended to contain some type of > "isReservedKey" statement. This just introduces a whole new can of worms > and more breaking points. > Yeah I agree it's a can of worms but I wanted to throw it out there for discussion. As we get more keywords and functionality it could bite in the butt in a few years time. I don't exactly understand your point in bullet 2? Why do < and > have to > be encoded, they are perfectly valid values inside of a string today, and > again many libraries make use of this functionality for transporting HTML, > XML, and Text fragments. To Crockfords point, "should not break" becomes > the issue with changing what should and should not be encoded. > For two reasons 1) Some browsers will render json as html (sniffing) 2) Inline JSON data will be parsed in a different order than it's intended. For example < will be parsed first as html and then javascript. Encoding < and > will have no effect on passing xml/html data but will prevent those issues.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
