Re: [XHR] responseType "json"

On Fri, Jan 6, 2012 at 1:45 PM, Jarred Nicholls <jarred@webkit.org> wrote:
> On Fri, Jan 6, 2012 at 4:34 PM, Ms2ger <ms2ger@gmail.com> wrote:
>> On 01/06/2012 10:28 PM, Jarred Nicholls wrote:
>>> This is an editor's draft of a spec, it's not a recommendation, so it's
>>> hardly a violation of anything.
>>
>> With this kind of attitude, frankly, you shouldn't be implementing a spec.
>
> I resent that comment, because I'm one of the few that fight in WebKit to
> get us 100% spec compliant in XHR (don't even get me started with how many
> "violations" there are in Firefox, IE, and Opera...WebKit isn't the only one
> mind you), but that doesn't mean any spec addition, as fluid as it is in the
> early stages, is gospel.  In this case I simply think it wasn't debated
> enough before going in - actually it wasn't debated at all, it was just
> placed in there and now I'm a bad guy for pointing out its disconnect?  I
> think your attitude is far poorer.
>
> The web platform changes all the time - if this matter is sured up, then
> implementations will change accordingly.

While Ms2ger was a bit short, there's a reason.  Long experience shows
that people who say things like "I'm going to code against the Rec
instead of the draft, because the Rec is more stable" often end up
causing pain for everyone else, because that "more stable" Rec is also
*more wrong*, precisely because "stable" means "hasn't been updated to
take into account new information or to fix bugs".  This happens even
for smaller differences - well-meaning devs coding to the Working
Draft of a spec on /TR instead of the error-corrected Editor's Draft
cause never-ending pain.

Old RFCs are also often a source of pain, because we quite often find
that the authors aren't fully versed in the complexities and
subtleties of the public web.  They may be operating from an academic
or corporate standpoint, or otherwise be contained in a local
experience-minimum that affects their view of what's reasonable.

RFC4627, for example, is six years old.  This was right about the
beginning of the time when "UTF-8 everywhere, dammit" was really
starting to gain hold as a reasonable solution to encoding hell.
Crockford, as well, is not a browser dev, nor is he closely connected
to browser devs in a capacity that would really inform him of why
supporting multiple encodings on the web is so painful.  So, looking
to that RFC for guidance on current best-practice is not a good idea.

This issue has been debated and argued over for a long time, far
predating the current XHR bit.  There's a reason why new file formats
produced in connection with web stuff are utf8-only.  It's good for
the web if we're consistent about this.

~TJ

Received on Saturday, 7 January 2012 04:46:52 UTC