[Bug 15059] New: Hi this the first test of my html5.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15059 Summary: Hi this the first test of my html5. Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org Specification: http://www.w3.org/TR/webstorage/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: Hi this the first test of my html5. Posted from: 119.145.5.249 User agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.8 (KHTML, like Gecko) Chrome/17.0.942.0 Safari/535.8 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [XHR] responseType 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. Thanks, fixed; that was an oversight: http://dvcs.w3.org/hg/xhr/rev/edfeab9138a4 http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#json-response-entity-body -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] responseType json
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 that the JSON RFC does not have. Given that ECMAScript thus far had the only platform-based implementation of JSON it made sense for XMLHttpRequest to follow that. -- Anne van Kesteren http://annevankesteren.nl/
[Bug 15059] Hi this the first test of my html5.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15059 Art Barstow art.bars...@nokia.com changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@nokia.com Resolution||INVALID -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [XHR] responseType json
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 of being fixed length encoding covering the entirety of Unicode. On Sun, Dec 4, 2011 at 1:41 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * 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 to ignore UTF-32 exists, and treat content that clearly is UTF-32 as UTF-16-encoded, which is much worse, as some components are likely to actually detect UTF-32, they would disagree with other components, and that tends to cause strange bugs and security issues. Thankfully, that is not a problem in this particular case.
Re: [XHR] responseType json
* 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: example/example;charset=utf-32 FF FE 00 00 ... Some would like to treat this as UTF-16 encoded document starting with U+ after the Unicode signature, even though it clearly is UTF-32. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
[dom] Mutation Observers
As discussed mutation observers would be best defined in the DOM. The DOM is discussed on www-...@w3.org: http://lists.w3.org/Archives/Public/www-dom/ (I bcc'd public-webapps just in case anyone missed this.) I think I now defined the last hook needed for mutation observers, replace all. The hooks related to tree mutations are defined here: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#mutation-algorithms To illustrate: * appendChild(node) maps to the append algorithm, which invokes pre-insert, which eventually does insert. * setting textContent maps to the replace all algorithm, which invokes remove (for each child node) followed by a single append * setting innerHTML can be defined just like textContent, using a DocumentFragment for the nodes to be inserted Whether separate pre-insert and insert is really necessary depends on how we end up defining mutation observers. I'm not sure what the current status of mutation observers is, but one open question was whether we should special case the style attribute due to it being frequently mutated. Has any data been gathered on that already? I have another question, if we expect a lot of mutations, should we split MutationRecord for the attribute/characterData versus childList case? There's a bunch of members that do not make sense for either of those. Mutation observer IDL is currently maintained here: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#mutation-observers -- Anne van Kesteren http://annevankesteren.nl/
[cors] when a preflight goes bad
The spec for resource sharing never discusses a status code for a failed. It just says, 'terminate'. To me, this suggests that, if there is no other OPTIONS processing going on, the net result will be a NOT FOUND. For that matter, it occurs to me, even if the entire preflight is a success, the status code will still be not found, won't it, if there is no other OPTIONS handler for the resource? Am I misinterpreting?
Re: [cors] when a preflight goes bad
On Mon, 05 Dec 2011 16:42:54 +0100, Benson Margulies bimargul...@gmail.com wrote: The spec for resource sharing never discusses a status code for a failed. It just says, 'terminate'. To me, this suggests that, if there is no other OPTIONS processing going on, the net result will be a NOT FOUND. For that matter, it occurs to me, even if the entire preflight is a success, the status code will still be not found, won't it, if there is no other OPTIONS handler for the resource? Am I misinterpreting? There is no status code. http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#cross-origin-request-status is set to network error which is on the granularity of failed to connect, unknown domain, etc. -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] when a preflight goes bad
The spec for resource sharing never discusses a status code for a failed. It just says, 'terminate'. To me, this suggests that, if there is no other OPTIONS processing going on, the net result will be a NOT FOUND. For that matter, it occurs to me, even if the entire preflight is a success, the status code will still be not found, won't it, if there is no other OPTIONS handler for the resource? Am I misinterpreting? There is no status code. http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#cross-origin-request-status is set to network error which is on the granularity of failed to connect, unknown domain, etc. That's on the client side, isn't it?. I'm worried about the resource side. On the resource side, what HTTP status code should be coming back from server to client for a preflight when the server has no other OPTIONS to return. 200? or 40x? -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] when a preflight goes bad
On Mon, 05 Dec 2011 16:57:17 +0100, Benson Margulies bimargul...@gmail.com wrote: That's on the client side, isn't it?. I'm worried about the resource side. On the resource side, what HTTP status code should be coming back from server to client for a preflight when the server has no other OPTIONS to return. 200? or 40x? Oh sorry, that does not matter. Whatever else you do in response to the OPTIONS request besides setting CORS-related headers on a 200 response is not observable. You could have a 200 response with CORS-related headers that make it fail, you could have a 201 response with CORS-related headers that make it pass, but will fail for it not being 200; you could have a 200 with no CORS headers. Whatever suits you. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] responseType json
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 can't be ignored without user consent. [1] http://www.w3.org/TR/webarch/#metadata-inconsistencies In any case, what is suggested below would be a direct violation of [2] as well. [2] http://www.w3.org/TR/charmod/#C030 On Mon, Dec 5, 2011 at 8:20 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * 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: example/example;charset=utf-32 FF FE 00 00 ... Some would like to treat this as UTF-16 encoded document starting with U+ after the Unicode signature, even though it clearly is UTF-32. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [XHR] responseType json
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 if at all, it's hardly ever used, and it provides no useful benefits for transport. Anything we can do to steer people more towards UTF-8 is a win. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [XHR] responseType json
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 world, UTF-32 isn't a transfer encoding. Browsers shouldn't have to waste time supporting it, and if someone accidentally creates content in that encoding somehow, it should be immediately clear that something is wrong. It would take a major disconnect from reality to insist that browsers support UTF-32. In any case, what is suggested below would be a direct violation of [2] as well. [2] http://www.w3.org/TR/charmod/#C030 No, it wouldn't. That doesn't say that UTF-32 must be recognized. -- Glenn Maynard
Re: [XHR] responseType json
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 UTF-32 as UTF-16 violates [2]. It's impossible to violate that rule if the encoding isn't recognized. When an IANA-registered charset name *is recognized*; UTF-32 isn't recognized, so this is irrelevant. If a browser doesn't support UTF-32 as an incoming interchange format, then it should treat it as any other character encoding it does not recognize. It must not pretend it is another encoding. When an encoding is not recognized by the browser, the browser has full discretion in guessing the encoding. (See step 7 of http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#determining-the-character-encoding.) It's perfectly reasonable for UTF-32 data to be detected as UTF-16. For example, UTF-32 data is likely to contain null bytes when scanned bytewise, and UTF-16 is the only supported encoding where that's likely to happen. Steps 7 and 8 gives browsers unrestricted freedom in selecting the encoding when the previous steps are unable to do so; if they choose to include if the charset is declared as UTF-32, return UTF-16 as one of their autodetection rules, the spec allows it. -- Glenn Maynard
Re: [XHR] responseType json
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] http://dev.w3.org/html5/spec/Overview.html#determining-the-character-encoding 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 confidence level of certain. 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. On Mon, Dec 5, 2011 at 11:45 AM, Glenn Maynard gl...@zewt.org wrote: 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 UTF-32 as UTF-16 violates [2]. It's impossible to violate that rule if the encoding isn't recognized. When an IANA-registered charset name *is recognized*; UTF-32 isn't recognized, so this is irrelevant. If a browser doesn't support UTF-32 as an incoming interchange format, then it should treat it as any other character encoding it does not recognize. It must not pretend it is another encoding. When an encoding is not recognized by the browser, the browser has full discretion in guessing the encoding. (See step 7 of http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#determining-the-character-encoding.) It's perfectly reasonable for UTF-32 data to be detected as UTF-16. For example, UTF-32 data is likely to contain null bytes when scanned bytewise, and UTF-16 is the only supported encoding where that's likely to happen. Steps 7 and 8 gives browsers unrestricted freedom in selecting the encoding when the previous steps are unable to do so; if they choose to include if the charset is declared as UTF-32, return UTF-16 as one of their autodetection rules, the spec allows it. -- Glenn Maynard
Re: [XHR] responseType json
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 standard. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [XHR] responseType json
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 confidence level of certain. 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. That wouldn't actually bring browsers and the spec closer together; it would actually bring them further apart. At first glance, it looks like it makes the spec allow WebKit and IE's behavior, which (unfortunately) includes UTF-32 detection, by allowing them to fall through to step 7, where they're allowed to detect things however they want. However, that's ignoring step 5. If step 4 passes through, then step 5 would happen next. That means this carefully-constructed file would be detected as UTF-8 by step 5: http://zewt.org/~glenn/test-utf32-with-ascii-meta.html-no-encoding That's not what happens in any browser; FF detects it as UTF-16 and WebKit and IE detect it as UTF-32. This change would require it to be detected as UTF-8, which would have security implications if implemented, eg. a page outputting escaped user-inputted text in UTF-32 might contain a string like this, followed by a hostile script, when interpreted as UTF-8. This really isn't worth spending time on; you've free to press this if you like, but I'm moving on. -- Glenn Maynard
Re: [XHR] responseType json
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 UTF-16LE in the case that the first four bytes are FF FE 00 00. Indeed, the current algorithm requires mis-labelling such content as UTF-16LE with a confidence of certain. The current text is also ambiguous with respect to what support means in step (2) of Section 8.2.2.1 of [1]. Which of the following are meant by support? - recognize with sniffer - be capable of using directly as internal coding - be capable of transcoding to internal coding [1] http://dev.w3.org/html5/spec/Overview.html#determining-the-character-encoding On Mon, Dec 5, 2011 at 3:10 PM, Ian Hickson i...@hixie.ch wrote: 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 standard. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [XHR] responseType json
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, to explicitly mis-label such content as UTF-16LE in the case that the first four bytes are FF FE 00 00. Indeed, the current algorithm requires mis-labelling such content as UTF-16LE with a confidence of certain. Yes, this is explicitly intentional. The current text is also ambiguous with respect to what support means in step (2) of Section 8.2.2.1 of [1]. Which of the following are meant by support? To quote from the terminology section: The specification uses the term supported when referring to whether a user agent has an implementation capable of decoding the semantics of an external resource. - recognize with sniffer - be capable of using directly as internal coding - be capable of transcoding to internal coding I don't know how to distinguish the latter two in a black-box manner. Either of the latter two is a correct interpretation as far as I can tell. I suppose the current spec could be read such that the user agent could autodetect an unsupported encoding, but that wouldn't be very clever. I guess I can add some text to the spec to make that more obviously bad. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[Bug 10623] Simplify Web IDL exceptions
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10623 Cameron McCormack c...@mcc.id.au changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #21 from Cameron McCormack c...@mcc.id.au 2011-12-06 05:59:53 UTC --- I don't think there are any actionable requests for changes left in this bug. Please reopen if I've got it wrong. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Feedback requested for UndoManager and DOM Transaction
Greetings all, As you maybe all aware, I've been working with developers of CKEditor, TinyMCE, and Google Docs along with developers from WebKit, Mozilla, and Opera on new UndoManager and DOM Transaction specificationhttp://rniwa.com/editing/undomanager.html for the last several months. And it's about time I ask for feedback from broader audience! Why? Because *undo and redo are broken on the Web today*. Whenever Web apps try to add a custom editing operation without using execCommand or do a fix up after browser executes a user editing action, user agents get confused by DOM mutations made by the apps and won't be able to undo or redo user editing actions and execCommand. This forces Web apps to re-implement undo and redo themselves, and in fact, *many rich text editors store innerHTML of* *a contenteditable element* as a string in their internal undo transaction history (a.k.a undo stack). There is also no way for Web apps to add new undo items and populate undo and redo menus on user agent's native UI. In addition, if an editor app has a widget with input/textarea, then the undo stack of the editor gets confused when the widget goes away because the undo transaction history exists only per document. In order to solve above and numerous other problems, we've come to a conclusion that we need to *add UndoManager and DOM Transaction*. *UndoManager* is an interface for managing *undo transaction history*. It exists on a document and an element with the undoscope content attribute. The main purpose of UndoManager is to communicate the list of undoable items with the user agent so that the user agent can provide a native UI (e.g. populating menu items with them). A *DOM transaction* is a sequence of DOM mutations that can be applied, unapplied, or reapplied. There are two types of DOM transactions: - *Automatic DOM transaction* - Only the logic to make the initial DOM changes is supplied by the author, and the user agent takes care of undo an redo. It is *compatible with user editing actions and editing commands*, and allows Web apps to easily do custom editing operations or fix up DOM after user editing actions. - *Manual DOM transaction* - Web apps specify logics to apply, unapply, and reapply the transaction and *takes the full control of undo and redo*. This transaction is useful for apps such as collaborative editor or canvas drawing apps that need to implement custom logic for undo and redo. You can see more concrete definitions of UndoManager and Transaction at: https://rniwa.com/editing/undomanager.html and see a list of uses cases at http://wiki.whatwg.org/wiki/UndoManager_Problem_Descriptions. I consider the current proposal to be ready for implementation feedback, and as such, I plan to prototype it in WebKit and give my own feedback as well. I sincerely request for your feedback on the proposal, and I will answer any question(s) you may have about the proposal. Best regards, Ryosuke Niwa Software Engineer Google Inc.
