Re: [XHR] responseType "json"

On Fri, Jan 6, 2012 at 3:18 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 1/6/12 12:13 PM, Jarred Nicholls wrote:
>
>> WebKit is used in many walled garden environments, so we consider these
>> scenarios, but as a secondary goal to our primary goal of being a
>> standards compliant browser engine.  The point being, there will always
>> be content that's created solely for WebKit, so that's not a good
>> argument to make.  So generally speaking, if someone is aiming to create
>> content that's x-browser compatible, they'll do just that and use the
>> least common denominators.
>>
>
> People never aim to create content that's cross-browser compatible per se,
> with a tiny minority of exceptions.
>
> People aim to create content that reaches users.
>
> What that means is that right now people are busy authoring webkit-only
> websites on the open web because they think that webkit is the only UA that
> will ever matter on mobile.  And if you point out this assumption to these
> people, they will tell you right to your face that it's a perfectly
> justified assumption.  The problem is bad enough that both Trident and
> Gecko have seriously considered implementing support for some subset of
> -webkit CSS properties.  Note that "people" here includes divisions of
> Google.
>
> As a result, any time WebKit deviates from standards, that _will_ 100%
> guaranteed cause sites to be created that depend on those deviations; the
> other UAs then have the choice of not working on those sites or duplicating
> the deviations.
>
> We've seen all this before, circa 2001 or so.
>
> Maybe in this particular case it doesn't matter, and maybe the spec in
> this case should just change, but if so, please argue for that, as the rest
> of your mail does, not for the principle of shipping random spec violations
> just because you want to.


I think my entire mail was quite clear that the spec is inconsistent with
rfc4627 and perhaps that's where the changes need to happen, or else yield
to it.  Let's not be dogmatic here, I'm just pointing out the obvious
disconnect.

This is an editor's draft of a spec, it's not a recommendation, so it's
hardly a violation of anything.  This is a 2-way street, and often times
it's the spec that needs to change, not the implementation.  The point is,
there needs to be a very compelling reason to breach the contract of a
media type's existing spec that would yield inconsistent results from the
rest of the web platform layers, and involve taking away functionality that
is working perfectly fine and can handle all the legit content that's
already out there (as rare as it might be).

Let's get Crockford on our side, let him know there's a lot of support for
banishing UTF-16 and UTF-32 forever and change rfc4627.


>   In general if WebKit wants to do special webkitty things in walled
> gardens that's fine.  Don't pollute the web with them if it can be avoided.
>  Same thing applies to other UAs, obviously.


IE and WebKit have gracefully handled UTF-32 for a long time in other parts
of the platform, and despite it being an "unsupported" codec of the HTML
spec, they've continued to do so.  I've had nothing to do with this, so I'm
not to be held responsible for its present perpetuation ;)  My argument is
focused around the JSON media type's spec, which blatantly contradicts.


>
>
> -Boris
>
>


-- 
................................................................

*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
<http://twitter.com/jarrednicholls>