Re: [XHR] UTF-16 - do content sniffing or not?
On Mon, Mar 23, 2015 at 1:45 PM, Simon Pieters sim...@opera.com wrote: On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: Given a server which sends UTF-16 data with a UTF-16 BOM but does *not* send charset=UTF-16 in the Content-Type header - should the browser detect the encoding, or just assume UTF-8 and return mojibake-ish data? What is your test doing? From what I understand of the spec, the result is different between e.g. responseText (honors utf-16 BOM) and JSON response (always decodes as utf-8). It tests responseText.
Re: [XHR] UTF-16 - do content sniffing or not?
On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: Hi, I've just added a test loading UTF-16 data with XHR, and it exposes an implementation difference that should probably be discussed: Given a server which sends UTF-16 data with a UTF-16 BOM but does *not* send charset=UTF-16 in the Content-Type header - should the browser detect the encoding, or just assume UTF-8 and return mojibake-ish data? Per my test, Chrome detects the UTF-16 encoding while Gecko doesn't. I think the spec currently says one should assume UTF-8 encoding in this scenario. Are WebKit/Blink - developers OK with changing their implementation? (The test currently asserts detecting UTF-16 is correct, pending discussion and clarification.) What is your test doing? From what I understand of the spec, the result is different between e.g. responseText (honors utf-16 BOM) and JSON response (always decodes as utf-8). -- Simon Pieters Opera Software
[Bug 27552] Make execCommand(InsertImage, false, ) insert an img element with no src attribute
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27552 Philip Jägenstedt phil...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Philip Jägenstedt phil...@opera.com --- That's a pretty depressing state of affairs, but thanks for sharing :) I don't volunteer to edit the spec, and am resolving this as WORKSFORME lacking any evidence that this matters to interop. Someone™ will have to have some sense of ownership for this to make any progress, but for now it's not me. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [XHR] UTF-16 - do content sniffing or not?
On Mon, 23 Mar 2015 14:32:27 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: On Mon, Mar 23, 2015 at 1:45 PM, Simon Pieters sim...@opera.com wrote: On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: Given a server which sends UTF-16 data with a UTF-16 BOM but does *not* send charset=UTF-16 in the Content-Type header - should the browser detect the encoding, or just assume UTF-8 and return mojibake-ish data? What is your test doing? From what I understand of the spec, the result is different between e.g. responseText (honors utf-16 BOM) and JSON response (always decodes as utf-8). It tests responseText. OK. I think the spec currently says one should assume UTF-8 encoding in this scenario. My understanding of the spec is different from yours. Let's step through the spec. https://xhr.spec.whatwg.org/#text-response [[ Let bytes be response's body. If bytes is null, return the empty string. Let charset be the final charset. ]] final charset is null. [[ If responseType is the empty string, charset is null, and final MIME type is either null, text/xml, application/xml or ends in +xml, use the rules set forth in the XML specifications to determine the encoding. Let charset be the determined encoding. [XML] [XMLNS] ]] Which MIME type did you use in the response? BOM sniffing in XML is non-normative IIRC. For other types, see below. [[ If charset is null, set charset to utf-8. Return the result of running decode on byte stream bytes using fallback encoding charset. ]] - https://encoding.spec.whatwg.org/#decode [[ For each of the rows in the table below, starting with the first one and going down, if the first bytes of buffer match all the bytes given in the first column, then set encoding to the encoding given in the cell in the second column of that row and set BOM seen flag. ]] This step honors the BOM. The fallback encoding is ignored. -- Simon Pieters Opera Software
[gamepad]-Demo
This is a very simplified and practical specification. As for me, I just graduated from Master of Science in Management. This article is related to my major and benefits my knowledge. Currently, it is also useful for me to search the job. The following is a short memo about this article in order to share with others. Summary: The framework looks like a Wikipedia. For example, it includes Abstract, Status of this Document, Introduction,Conformance,Scope. Gamepad Interface,Attributes, GamepadButton Interface, Attibutes,GamepadMappingType. Methods,GamepadEvent Interface, Attributes, Dictionary, Remapping, Usage Examples, The gamepadconnected event, The gamepaddisconnected event, Other events. All of all them are necessary parts for technical part in each proposal. In Attributes part, each function gives us the definition and how it gives the contribution to the Gamepad. Especially, axes, of type arrayof double, readonly, then describes it as the statistic method to show how it works in the function. Although it is a simple product, the specification is very professional and easy for the reader to understand the product. No matter whether customer or user, you can gain the benefits in my perspective.
[Bug 27552] Make execCommand(InsertImage, false, ) insert an img element with no src attribute
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27552 Simon Pieters sim...@opera.com changed: What|Removed |Added CC||sim...@opera.com Resolution|WORKSFORME |LATER --- Comment #5 from Simon Pieters sim...@opera.com --- (LATER seems like a better fit) -- You are receiving this mail because: You are on the CC list for the bug.
