On Fri, 06 Jan 2012 17:20:04 +0100, Glenn Maynard gl...@zewt.org wrote:
Anne: There's one related change I'd suggest. Currently, if a JSON
response says Content-Encoding: application/json; charset=Shift_JIS,
the explicit charset will be silently ignored and UTF-8 will be used.
I think this
On 2012-01-06 22:58, Tab Atkins Jr. wrote:
...
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
On 2012-01-07 10:48, Anne van Kesteren wrote:
On Fri, 06 Jan 2012 17:20:04 +0100, Glenn Maynard gl...@zewt.org wrote:
Anne: There's one related change I'd suggest. Currently, if a JSON
response says Content-Encoding: application/json; charset=Shift_JIS,
the explicit charset will be silently
On Sat, 07 Jan 2012 11:30:42 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
charset is undefined on application/json, so ignoring it is the right
thing.
text/event-stream;charset=hz-gb-2312 on the other hand is invalid (as
far as I understand the spec), so if this defaults to UTF-8
On 2012-01-07 15:15, Anne van Kesteren wrote:
On Sat, 07 Jan 2012 11:30:42 +0100, Julian Reschke
julian.resc...@gmx.de wrote:
charset is undefined on application/json, so ignoring it is the right
thing.
text/event-stream;charset=hz-gb-2312 on the other hand is invalid (as
far as I understand
On Sat, 07 Jan 2012 02:55:15 +0100, Jarred Nicholls jar...@webkit.org
wrote:
Not exact, but close. For discussion's sake and in this context, you
could call it the Unicode text decoder that does BOM detection and
switches Unicode codecs automatically. For enforced UTF-8 I'd (have to)
On Mon, Dec 5, 2011 at 3:15 PM, Glenn Adams gl...@skynav.com wrote:
But, if the browser does not support UTF-32, then the table in step (4) of
[1] is supposed to apply, which would interpret the initial two bytes FF
FE
as UTF-16LE according to the current language of [1], and further,
Please be careful with quote markers; you quoted text written by me as
written by Glenn Adams.
On Fri, Jan 6, 2012 at 10:00 AM, Jarred Nicholls jar...@webkit.org wrote:
I'm getting responseType json landed in WebKit, and going to do so without
the restriction of the JSON source being UTF-8. We
On 2012-01-06 17:20, Glenn Maynard wrote:
...
Big -1 to perpetuating UTF-16 and UTF-32 due to braindamage in an IETF spec.
...
You seem to feel strongly about this (and I might agree for UTF-32).
How about raising this issue in a place where there's an actual chance
to cause changes? (-
On 1/6/12 11:20 AM, Glenn Maynard wrote:
Accepting content that other browsers don't will result in pages being
created that work only in WebKit. That gives the least
interoperability, not the most.
I assume Jarred was talking about interoperability with content, not
with other browsers.
On 2012-01-06 17:56, Boris Zbarsky wrote:
On 1/6/12 11:20 AM, Glenn Maynard wrote:
Accepting content that other browsers don't will result in pages being
created that work only in WebKit. That gives the least
interoperability, not the most.
I assume Jarred was talking about interoperability
On Fri, Jan 6, 2012 at 11:20 AM, Glenn Maynard gl...@zewt.org wrote:
Please be careful with quote markers; you quoted text written by me as
written by Glenn Adams.
Sorry, copying from the archives into Gmail is a pain.
On Fri, Jan 6, 2012 at 10:00 AM, Jarred Nicholls jar...@webkit.org
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
On Fri, Jan 6, 2012 at 3:18 PM, Boris Zbarsky bzbar...@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
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.
HTH
Ms2ger
On Fri, Jan 6, 2012 at 12:18 PM, Boris Zbarsky bzbar...@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
On Fri, Jan 6, 2012 at 4:34 PM, Ms2ger ms2...@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.
* 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. 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
On Fri, Jan 6, 2012 at 4:58 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
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
I know that's a common error, but I never said I was going against a Rec.
On Fri, Jan 6, 2012 at 4:54 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* 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. This is a 2-way street, and often times
it's the spec that needs to change, not the
On Fri, Jan 6, 2012 at 12:13 PM, Jarred Nicholls jar...@webkit.org 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
Sent from my iPhone
On Jan 6, 2012, at 7:11 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jan 6, 2012 at 12:13 PM, Jarred Nicholls jar...@webkit.org wrote:
WebKit is used in many walled garden environments, so we consider these
scenarios, but as a secondary goal to our primary goal of
On Fri, Jan 6, 2012 at 7:36 PM, Jarred Nicholls jar...@webkit.org wrote:
Correction: rfc4627 doesn't describe BOM detection, it describes zero-byte
detection. My question remains, though: what exactly are you doing? Do
you do zero-byte detection? Do you do BOM detection? What's the order
On Jan 6, 2012, at 8:10 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jan 6, 2012 at 7:36 PM, Jarred Nicholls jar...@webkit.org wrote:
Correction: rfc4627 doesn't describe BOM detection, it describes zero-byte
detection. My question remains, though: what exactly are you doing? Do you
do
On Fri, Jan 6, 2012 at 1:45 PM, Jarred Nicholls jar...@webkit.org wrote:
On Fri, Jan 6, 2012 at 4:34 PM, Ms2ger ms2...@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
On Fri, Jan 6, 2012 at 12:36 PM, Ojan Vafai o...@chromium.org wrote:
I'm ambivalent about whether we should restrict to utf8 or not. On the one
hand, having everyone on utf8 would greatly simplify the web. On the other
hand, I can imagine this hurting download size for japanese/chinese websites
On Fri, Jan 6, 2012 at 4:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Note that this may be subject to the same counter-intuitive forces
that cause UTF-8 to usually be better for CJK HTML pages (because a
lot of the source is ASCII markup). In JSON, all of the markup
artifacts (braces,
On Mon, Dec 12, 2011 at 7:08 PM, Jarred Nicholls jar...@sencha.com wrote:
There's no feeding (re: streaming) of data to a parser, it's buffered until
the state is DONE (readyState == 4) and then an XML doc is created upon the
first access to responseXML or response. Same will go for the JSON
On Sun, 11 Dec 2011 15:44:58 +0100, Jarred Nicholls jar...@sencha.com
wrote:
I understand that's how you spec'ed it, but it's not how it's implemented
in IE nor WebKit for legacy purposes - which is what I meant in the above
statement.
What do you mean legacy purposes? responseType is a new
I'd like to bring up an issue with the spec with regards to responseText +
the new json responseType. Currently it is written that responseText
should throw an exception if the responseType is not or text. I would
argue that responseText should also return the plain text when the type is
json.
I'd like to bring up an issue with the spec with regards to responseText +
the new json responseType. Currently it is written that responseText
should throw an exception if the responseType is not or text. I would
argue that responseText should also return the plain text when the type is
json.
On Sun, Dec 11, 2011 at 4:08 PM, Jarred Nicholls jar...@sencha.com wrote:
A good compromise would be to only throw it away (and thus restrict
responseText access) upon the first successful parse when accessing
.response.
I disagree. Even though conceptually, the spec says that you first
On Mon, Dec 12, 2011 at 5:37 AM, Anne van Kesteren ann...@opera.com wrote:
On Sun, 11 Dec 2011 15:44:58 +0100, Jarred Nicholls jar...@sencha.com
wrote:
I understand that's how you spec'ed it, but it's not how it's implemented
in IE nor WebKit for legacy purposes - which is what I meant in
On Mon, Dec 12, 2011 at 6:39 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Sun, Dec 11, 2011 at 4:08 PM, Jarred Nicholls jar...@sencha.com
wrote:
A good compromise would be to only throw it away (and thus restrict
responseText access) upon the first successful parse when accessing
On Mon, 12 Dec 2011 14:12:57 +0100, Jarred Nicholls jar...@sencha.com
wrote:
I started an initiative to bring XHR in WebKit up-to-spec (see
https://bugs.webkit.org/show_bug.cgi?id=54162) and got a lot of push
back. All I'm asking is that if I run into push back again, that I can
send them
On 12/12/2011 03:12 PM, Jarred Nicholls wrote:
On Mon, Dec 12, 2011 at 5:37 AM, Anne van Kesteren ann...@opera.com
mailto:ann...@opera.com wrote:
On Sun, 11 Dec 2011 15:44:58 +0100, Jarred Nicholls
jar...@sencha.com mailto:jar...@sencha.com wrote:
I understand that's how you
On Mon, Dec 12, 2011 at 9:28 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/12/11 8:12 AM, Jarred Nicholls wrote:
I started an initiative to bring XHR in WebKit up-to-spec (see
https://bugs.webkit.org/show_**bug.cgi?id=54162https://bugs.webkit.org/show_bug.cgi?id=54162)
and got a lot of
On Sat, Dec 10, 2011 at 9:10 PM, Jarred Nicholls jar...@sencha.com wrote:
I'd like to bring up an issue with the spec with regards to responseText +
the new json responseType. Currently it is written that responseText
should throw an exception if the responseType is not or text. I would
On Sun, 11 Dec 2011 06:10:26 +0100, Jarred Nicholls jar...@sencha.com
wrote:
For legacy reasons, responseText and responseXML continue to work
together despite the responseType that is set.
This is false. responseType text allows access to responseText, but not
responseXML. document allows
On Sun, Dec 11, 2011 at 5:08 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Sat, Dec 10, 2011 at 9:10 PM, Jarred Nicholls jar...@sencha.com
wrote:
I'd like to bring up an issue with the spec with regards to responseText
+
the new json responseType. Currently it is written that
On Sun, Dec 11, 2011 at 9:08 AM, Jarred Nicholls jar...@sencha.com wrote:
On Sun, Dec 11, 2011 at 5:08 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Sat, Dec 10, 2011 at 9:10 PM, Jarred Nicholls jar...@sencha.com
wrote:
I'd like to bring up an issue with the spec with regards to
On Sun, Dec 11, 2011 at 6:55 AM, Anne van Kesteren ann...@opera.com wrote:
On Sun, 11 Dec 2011 06:10:26 +0100, Jarred Nicholls jar...@sencha.com
wrote:
For legacy reasons, responseText and responseXML continue to work
together despite the responseType that is set.
This is false.
I'd like to bring up an issue with the spec with regards to responseText +
the new json responseType. Currently it is written that responseText
should throw an exception if the responseType is not or text. I would
argue that responseText should also return the plain text when the type is
json.
On Sun, 04 Dec 2011 21:38:53 +0100, Bjoern Hoehrmann derhoe...@gmx.net
wrote:
I did not reverse-engineer the current proposal, but my impression is it
would handle text and json differently with respect to the Unicode
signature. I do not think that would be particularily desirable if true.
On Fri, 02 Dec 2011 14:00:26 +0100, Anne van Kesteren ann...@opera.com
wrote:
I tied it to UTF-8 to further the fight on encoding proliferation and
encourage developers to always use that encoding.
FYI, I also tied it to ECMAScript's definition of JSON, which has some
restrictions in place
What do you mean by treat content that clearly is UTF-32 as
UTF-16-encoded? Do you mean interpreting it as a sequence of unsigned
shorts? That would be a direct violation of the semantics of UTF-32, would
it not?
I'm not advocating the use of UTF-32 for interchange, but it does have the
advantage
* Glenn Adams wrote:
What do you mean by treat content that clearly is UTF-32 as
UTF-16-encoded? Do you mean interpreting it as a sequence of unsigned
shorts? That would be a direct violation of the semantics of UTF-32, would
it not?
Consider you have
...
Content-Type:
In the example you give, there is consistency between the content metadata
(charset param) and the content itself (as determined by sniffing). So why
would both the metadata and content be ignored?
If there were an inconsistency (but there isn't) then [1] would apply, in
which case the metadata
On Sun, 4 Dec 2011, Bjoern Hoehrmann wrote:
The fight here is for standards.
The fight, if you want to characterise it as such, is for
interoperability, not standards. Standards are just a tool we use today
for that purpose.
For these purposes, we can ignore UTF-32. It's poorly implemented
On Mon, Dec 5, 2011 at 11:12 AM, Glenn Adams gl...@skynav.com wrote:
In the example you give, there is consistency between the content metadata
(charset param) and the content itself (as determined by sniffing). So why
would both the metadata and content be ignored?
Because in the real
On Mon, Dec 5, 2011 at 1:00 PM, Glenn Adams gl...@skynav.com wrote:
[2] http://www.w3.org/TR/charmod/#C030
No, it wouldn't. That doesn't say that UTF-32 must be recognized.
You misread me. I am not saying or supporting that UTF-32 must be
recognized. I am saying that MIS-recognizing
Let me choose my words more carefully.
A browser may recognize UTF-32 (e.g., in a sniffer) without supporting it
(either internally or for transcoding into a different internal encoding).
If the browser supports UTF-32, then step (2) of [1] applies.
[1]
On Mon, 5 Dec 2011, Glenn Adams wrote:
I see the problem now. It seems that the table in step (4) should be
changed to interpret an initial FF FE as UTF-16BE only if the following
two bytes are not 00.
The current text is intentional. UTF-32 is explicitly not supported by the
HTML
On Mon, Dec 5, 2011 at 3:15 PM, Glenn Adams gl...@skynav.com wrote:
But, if the browser does not support UTF-32, then the table in step (4) of
[1] is supposed to apply, which would interpret the initial two bytes FF FE
as UTF-16LE according to the current language of [1], and further, return a
The problem as I see it is that the current spec text for charset detection
effectively *requires* a browser that does not support UTF-32 to
explicitly ignore content metadata that may be correct (if it specifies
UTF-32 as charset param), and further, to explicitly mis-label such content
as
On Mon, 5 Dec 2011, Glenn Adams wrote:
The problem as I see it is that the current spec text for charset
detection effectively *requires* a browser that does not support
UTF-32 to explicitly ignore content metadata that may be correct (if it
specifies UTF-32 as charset param), and further,
On Fri, 02 Dec 2011 17:03:37 +0100, Henri Sivonen hsivo...@iki.fi wrote:
Does anyone actually transfer JSON as UTF-16?
Note that you cannot transmit UTF-16 JSON from a page (sending text is
UTF-8 only) so not being able to receive it either seems fine. I actually
think that we should make
On 2011-12-04 16:52, Anne van Kesteren wrote:
On Fri, 02 Dec 2011 17:03:37 +0100, Henri Sivonen hsivo...@iki.fi wrote:
Does anyone actually transfer JSON as UTF-16?
Note that you cannot transmit UTF-16 JSON from a page (sending text is
UTF-8 only) so not being able to receive it either seems
* Anne van Kesteren wrote:
I tied it to UTF-8 to further the fight on encoding proliferation and
encourage developers to always use that encoding.
The fight here is for standards. You know, you read the specification,
create some content, and then that content works in all implementations
that
* Henri Sivonen wrote:
Browsers don't support UTF-32. It has no use cases as an interchange
encoding beyond writing evil test cases. Defining it as a valid
encoding is reprehensible.
If UTF-32 is bad, then it should be detected as such and be rejected.
The current idea, from what I can tell, is
On 2011-12-02 14:00, Anne van Kesteren wrote:
I added a json responseType
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#the-responsetype-attribute
and JSON response entity body description:
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#json-response-entity-body
This is based on a
Le 2 déc. 2011 à 08:00, Anne van Kesteren a écrit :
I tied it to UTF-8 to further the fight on encoding proliferation and
encourage developers to always use that encoding.
Do we have stats on what is currently done on the Web with regards to the
encoding?
--
Karl Dubost -
On Dec 2, 2011, at 14:00 , Anne van Kesteren wrote:
I tied it to UTF-8 to further the fight on encoding proliferation and
encourage developers to always use that encoding.
That's a good fight, but I think this is the wrong battlefield. IIRC (valid)
JSON can only be in UTF-8,16,32 (with BE/LE
On 2011-12-02 14:41, Robin Berjon wrote:
On Dec 2, 2011, at 14:00 , Anne van Kesteren wrote:
I tied it to UTF-8 to further the fight on encoding proliferation and encourage
developers to always use that encoding.
That's a good fight, but I think this is the wrong battlefield. IIRC (valid)
On Fri, Dec 2, 2011 at 3:41 PM, Robin Berjon ro...@berjon.com wrote:
On Dec 2, 2011, at 14:00 , Anne van Kesteren wrote:
I tied it to UTF-8 to further the fight on encoding proliferation and
encourage developers to always use that encoding.
That's a good fight, but I think this is the wrong
65 matches
Mail list logo
