[XHR] readystatechange for multiple open calls
Hi Hallvord, While reviewing https://critic.hoppipolla.co.uk/r/86, I found the changed version assumes not firing readystatechange for the subsequent open() calls where the readyState is already 1, which in my understanding is not conformed to the current spec text. Commits are specifically: https://critic.hoppipolla.co.uk/a526c904?review=86 https://critic.hoppipolla.co.uk/89cc3591?review=86 I'll submit relevant issue comments right in Critics but in general do you see any issue with the readystatechange behavior with consecutive open() calls in the current spec text? Current browser implementations show: - Firefox fires. - Chrome and Opera do not. Jungkee Jungkee Song Samsung Electronics
RE: [XHR] readystatechange for multiple open calls
I just noticed that the topic has been discussed in another thread early this week. Sorry for rushing around after all that. BTW, what was the conclusion? -Original Message- From: Jungkee Song [mailto:jungkee.s...@samsung.com] Sent: Thursday, May 16, 2013 5:33 PM To: hallv...@opera.com; WebApps WG Subject: [XHR] readystatechange for multiple open calls Hi Hallvord, While reviewing https://critic.hoppipolla.co.uk/r/86, I found the changed version assumes not firing readystatechange for the subsequent open() calls where the readyState is already 1, which in my understanding is not conformed to the current spec text. Commits are specifically: https://critic.hoppipolla.co.uk/a526c904?review=86 https://critic.hoppipolla.co.uk/89cc3591?review=86 I'll submit relevant issue comments right in Critics but in general do you see any issue with the readystatechange behavior with consecutive open() calls in the current spec text? Current browser implementations show: - Firefox fires. - Chrome and Opera do not. Jungkee Jungkee Song Samsung Electronics
[Bug 22059] New: Composition dictionary should be changed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22059
Bug ID: 22059
Summary: Composition dictionary should be changed
Classification: Unclassified
Product: WebAppsWG
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: IME API
Assignee: m...@w3.org
Reporter: ko...@google.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
As the spec dropped Javascript IME spec, Composition dictionary
doesn't have to be a separate dictionary but can be a part of
InputMethodContext.
In 20130404 WD:
dictionary Composition {
readonly attribute Node text;
readonly attribute Range caret;
};
In Microsoft's proposal
https://dvcs.w3.org/hg/ime-api/raw-file/default/proposals/IMEProposal.html
interface InputMethodContext : EventTarget {
...
readonlyattribute DOMString compositionText;
readonlyattribute unsigned long compositionStartOffset;
readonlyattribute unsigned long compositionEndOffset;
};
The rationale for this is
For composition dictionary in current proposal, we can see exposing IME clauses
as child nodes of text node, and making them real DOM nodes with styles being
useful for a JS-based IME as the IME needs to tell the web application how to
render the composition, but if JS IME is not a goal, is there any other
scenarios that will benefit from this? If not, how about a simple design that
expose the text being composed as DOMString?
For caret range, if it’s for enabling JS-based IME, then exposing the caret
ranges of IME clauses is helpful, but if it’s not for JS IME, is there any
other usage? We understand that web applications want to know about the whole
string of the tentative composition, but we are not sure in which case they
want to know how the whole tentative composition string is divided into several
parts. Another issue is that the range type only tells the start and end
offsets of the composition from its immediate parent. Web application usually
wants to know the offset from the beginning of the text field so that it could
combine the composition alternate with the text before it to create a full text
string. But the beginning of the text field can be up in the parent tree if
it’s a contentEditable element and requires JavaScript code to trace up in the
parent tree to get the right offset.
So instead of a dictionary type for composition, we suggest compositionText,
compositionStartOffset and compositionEndOffset as a simpler design. Please let
us know if you have scenarios that need to be the other way.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug 22058] New: error event should fire before final readystatechange event
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22058 Bug ID: 22058 Summary: error event should fire before final readystatechange event Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: hallv...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org #request-error part of spec: Step 6: Fire an event named readystatechange. . . Step 9: Fire a progress event named event. // this fires the actual 'error' event This seems to be an order of events that isn't really user-friendly. Given a typical XHR-using script has logic like this: if readystatechange fires with readyState === 4 report success, handle response data if error event fires report failure this typical XHR user would end up running the success code first, then the failure code. This seems less than ideal.. Is there any reason we can't move the fire error step to before the fire readystatechange step? -- You are receiving this mail because: You are on the CC list for the bug.
Re: RE: [XHR] readystatechange for multiple open calls
I just noticed that the topic has been discussed in another thread early this week. Sorry for rushing around after all that. BTW, what was the conclusion? The conclusion is this commit: https://github.com/whatwg/xhr/commit/972797fb12106ca00292b9a2e2cb91d8766c4640 which seems reasonable to me (but then, it aligns the spec with both old Opera and Chrome/Chromium/new Opera, so I'm sort of naturally biased to think it makes sense). Also, kudos for reviewing the test changes so closely that you pointed out this issue and it's non-alignment with the spec as it was without being aware of the discussion. :-) -- Hallvord R. M. Steen Core tester, Opera Software
[Bug 22058] error event should fire before final readystatechange event
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22058 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Anne ann...@annevk.nl --- Either fully use readystatechange or use the other set of events. If you start mixing, you're on your own. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 16304] DONE != DONE
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16304 Anne ann...@annevk.nl changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #14 from Anne ann...@annevk.nl --- http://xhr.spec.whatwg.org/#states states: The data transfer has been completed or something went wrong during the transfer (e.g. infinite redirects). There are no implications about events in particular. -- You are receiving this mail because: You are on the CC list for the bug.
RE: RE: [XHR] readystatechange for multiple open calls
-Original Message- From: Hallvord Reiar Michaelsen Steen [mailto:hallv...@opera.com] Sent: Thursday, May 16, 2013 7:02 PM The conclusion is this commit: https://github.com/whatwg/xhr/commit/972797fb12106ca00292b9a2e2cb91d8766c4 640 The ED has been updated with the change: https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html which seems reasonable to me (but then, it aligns the spec with both old Opera and Chrome/Chromium/new Opera, so I'm sort of naturally biased to think it makes sense). It's *readystatechange* event. It is always the last open() the request actually takes the action on. Unless otherwise we would intend for authors to be notified every open() call, the change seems reasonable to me, too. Also, kudos for reviewing the test changes so closely that you pointed out this issue and it's non-alignment with the spec as it was without being aware of the discussion. :-) -- Hallvord R. M. Steen Core tester, Opera Software
Re: webcomponents: import instead of link
On Wed, May 15, 2013 at 9:08 PM, Simon Pieters sim...@opera.com wrote: Case study: img was historically not capable of executing script from an external file. This lead to sites expecting img to be safe (e.g. allow untrusted comments to use img). When browsers wanted to support SVG in img, scripting had to be disabled in order to not break the assumption that img is safe. Further case-in-point: Hosting SVG same-origin is nevertheless still very much a no-no as tricking the user into loading the file directly will expose the user to said scripts. -- http://annevankesteren.nl/
Re: Re: [XHR] anonymous flag
On Tue, May 14, 2013 at 11:46 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: Say, for example, OpenID is a setup where the user might provide an untrusted URL to a third-party web site (Here's the service that can authenticate me), and XHR might be involved - but the Open ID *provider* would of course want to know what site it is interacting with, to present some information about what authenticating means to the user.. Why? That information could be in the resource. Or if you e.g. implement your own browser-like thing that accepts arbitrary URLs you would want something similar. You might also want to do same-origin requests that do not include the overhead of Cookie / Origin / Referrer headers. HTML already has rel=noreferrer for that. We should expose functionality like that in the low-level API. -- http://annevankesteren.nl/
Re: CfC: Face to face meeting on Components, 21 June
On Wed, May 15, 2013 at 4:00 PM, Angelina Fabbro angelinafab...@gmail.com wrote: I assume meeting notes will be posted to the list for those who can't attend? A lot of good topics there. Yes! There's a new ::distributed() pseudo-element function, which provides a way for a shadow tree to affect style of the elements, distributed into insertion points This makes me (and will make other developers I've talked to) a happy panda. Good to hear :) :DG
Overlap between StreamReader and FileReader
StreamReader proposed in the Streams API spec is almost the same as FileReader. By adding the maxSize argument to the readAs methods (new methods or just add it to existing methods as an optional argument) and adding the readAsBlob method, FileReader can cover all what StreamReader provides. Has this already been discussed here? I heard that some people who had this concern discussed briefly and were worrying about derailing File API standardization. We're planning to implement it on Chromium/Blink shortly.
Re: Overlap between StreamReader and FileReader
On Thu, May 16, 2013 at 5:58 PM, Takeshi Yoshino tyosh...@google.com wrote: StreamReader proposed in the Streams API spec is almost the same as FileReader. By adding the maxSize argument to the readAs methods (new methods or just add it to existing methods as an optional argument) and adding the readAsBlob method, FileReader can cover all what StreamReader provides. Has this already been discussed here? I heard that some people who had this concern discussed briefly and were worrying about derailing File API standardization. We're planning to implement it on Chromium/Blink shortly. The Streams API https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm is no good as far as I can tell. We need something else for IO. (See various threads on this list by me.) Alex will tell you the same so I doubt it'd get through Blink API review. -- http://annevankesteren.nl/
RE: Overlap between StreamReader and FileReader
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Thu, May 16, 2013 at 5:58 PM, Takeshi Yoshino tyosh...@google.com wrote: StreamReader proposed in the Streams API spec is almost the same as FileReader. By adding the maxSize argument to the readAs methods (new methods or just add it to existing methods as an optional argument) and adding the readAsBlob method, FileReader can cover all what StreamReader provides. Has this already been discussed here? I heard that some people who had this concern discussed briefly and were worrying about derailing File API standardization. We're planning to implement it on Chromium/Blink shortly. The Streams API https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm is no good as far as I can tell. We need something else for IO. (See various threads on this list by me.) Alex will tell you the same so I doubt it'd get through Blink API review. Since we have Streams implemented to some degree, I'd love to hear suggestions to improve it relative to IO. Anne can you summarize the points you've made on the other various threads?
Re: webcomponents: import instead of link
On Wed, May 15, 2013 at 11:03 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: On Wed, May 15, 2013 at 10:59 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, May 15, 2013 at 10:21 AM, John J Barton johnjbar...@johnjbarton.com wrote: On Tue, May 14, 2013 at 8:04 PM, Jonas Sicking jo...@sicking.cc wrote: Apparently I wasn't clear enough before. We shouldn't add dynamically updating imports of components just because we're choosing to reuse link. We add dynamic imports if there are use cases. So far no-one has presented any use cases. Sorry if this is out-of-context, but as far as I can tell you are proposing that demand-loading of Web components for Web apps is not a valid use-case for components. That's not what I'm proposing. What I'm saying is that unloading of a component document is not a use case. I agree that unloading a component document is not a high-priority use case. I.e. using link to point to URL A and wait for it to load the components in A. Then change the link to point to URL B and have it unload the components from A and instead load the components in B. This is how stylesheets work if you dynamically modify a link from pointing at A to pointing at B. And the same logic could apply to web-components. However the consequences need not be similar. When you remove a stylesheet you remove rules from an active rule set. The only reason is history. Historically we had poor JS control over CSS so we did not manipulate the CSS rule set. This meant 1) unloading the stylesheet had some utility and 2) removing the corresponding rules makes some sense. If we had a lot of JS operating on CSS, then we would consider CSS rule removal with stylesheet unloading to be a horrible mistake. Unloading web-components need not follow that path. Unloading could simply mean un-registering the component so no new instances of that component could be created. Would that be horrible? I don't think so. The next attempt to create that component instance simply falls over. I definitely agree there are use cases for at some point after a document has finished loading, loading components from url A, and again at a yet later point loading components from URL B. I think unloading components (unregistering custom elements, to be precise), is out of questions and never should be on the table. In fact, we have a separate table for that -- it's in a dark, scary place with eternal burning fire, where all bad ideas go after they die. If web-components are meta objects for creating instances, then unloading is a marginal-value idea. Else there is something more to understand... What makes unloading apocalyptically bad? jjb :DG
RE: Overlap between StreamReader and FileReader
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Thu, May 16, 2013 at 6:31 PM, Travis Leithead travis.leith...@microsoft.com wrote: Since we have Streams implemented to some degree, I'd love to hear suggestions to improve it relative to IO. Anne can you summarize the points you've made on the other various threads? I recommend reading through http://lists.w3.org/Archives/Public/public- webapps/2013JanMar/thread.html#msg569 Problems: * Too much complexity for being an Blob without synchronous size. * The API is bad. The API for File is bad too, but we cannot change it, this however is new. And I think we really want an IO API that's not about incremental, but can actively discard incoming data once it's processed. Thanks, I'll review the threads and think about this a bit more.
RE: Overlap between StreamReader and FileReader
Can you please go into a bit more detail? I've read through the thread, and it mostly focuses on the details of how a Stream is received from XHR and what behaviors can be expected - it only lightly touches on how you can operate on a stream after it is received. The StreamReader by design mimics the FileReader, in order to give a consistent experience to developers. If we agree the FileReader has some flaws and we want to take an opportunity to address them with StreamReader, or an alternative, then I think that is reasonable. I do agree the API should allow for scenarios where data can be discarded, given that is an advantage of a Stream over a Blob. That said, Anne, what is your suggestion for how Streams can be consumed? Also, apologies for being a bit late to the conversation - I missed the conversations the past month. I'm now hoping to solicit more feedback and update the Streams spec accordingly. Date: Thu, 16 May 2013 18:41:21 +0100 From: ann...@annevk.nl To: travis.leith...@microsoft.com CC: tyosh...@google.com; slightly...@google.com; public-webapps@w3.org Subject: Re: Overlap between StreamReader and FileReader On Thu, May 16, 2013 at 6:31 PM, Travis Leithead travis.leith...@microsoft.com wrote: Since we have Streams implemented to some degree, I'd love to hear suggestions to improve it relative to IO. Anne can you summarize the points you've made on the other various threads? I recommend reading through http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg569 Problems: * Too much complexity for being an Blob without synchronous size. * The API is bad. The API for File is bad too, but we cannot change it, this however is new. And I think we really want an IO API that's not about incremental, but can actively discard incoming data once it's processed. -- http://annevankesteren.nl/
Re: Overlap between StreamReader and FileReader
I skimmed the thread before starting this and saw that you were pointing out some issues but didn't think you're opposing so much. Let me check requirements. a) We don't want to introduce a completely new object for streaming HTTP read/write, but we'll realize it by adding some extension to XHR. b) The point to connect the I/O API and XHR should be only the send() method argument and xhr.response attribute if possible. c) The semantics (attribute X is valid when state is ..., etc.) should be kept same as other modes. d) The I/O API needs to work with synchronous XHR. e) Resource for already processed data should be able to be released explicitly as the user instructs. f) Reading with maxSize argument (don't read too much). g) The I/O API should allow for skipping unnecessary data without creating a new object for that. Not requirement h) Some people wanted Stream to behave like not an object to store the data but kinda dam put between response attribute and XHR's internal buffer (and network stack) expecting that XHR doesn't consume data from the network until read operation is invoked on Stream object. (i.e. Stream controls data flow in addition to callback invocation timing). But it's no longer considered to be a requirement. i) Reading with size argument (invoke callback only when data of the specified amount is ready. Only data of the specified size at the head of stream is passed to the handler) On Fri, May 17, 2013 at 2:41 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 16, 2013 at 6:31 PM, Travis Leithead travis.leith...@microsoft.com wrote: Since we have Streams implemented to some degree, I'd love to hear suggestions to improve it relative to IO. Anne can you summarize the points you've made on the other various threads? I recommend reading through http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg569 Problems: * Too much complexity for being an Blob without synchronous size. * The API is bad. The API for File is bad too, but we cannot change it, this however is new. And I think we really want an IO API that's not about incremental, but can actively discard incoming data once it's processed. -- http://annevankesteren.nl/
RfC: LCWD of Indexed Database; deadline June 7
This is a Request for Comments for the 16 May 2013 Last Call Working Draft of Indexed Database: http://www.w3.org/TR/2013/WD-IndexedDB-20130516/ The comment deadline is June 7 and all comments should be sent to the public-webapps@w3.org list. -Thanks, AB
CfC: publish Widget Updates as a WG Note; deadline May 23
It appears there is no longer sufficient interest to move the Widget Updates on the Recommendation track so this is a Call for Consensus to publish this spec as a WG Note and thus formally stop work on it. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by May 23 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. -Thanks, AB Original Message Subject:Re: [widgets] Does anyone still care about Widget Updates? Resent-Date:Tue, 14 May 2013 13:33:26 + Resent-From:public-webapps@w3.org Date: Tue, 14 May 2013 09:32:22 -0400 From: ext Arthur Barstow art.bars...@nokia.com To: public-webapps public-webapps@w3.org Scott indicated [1] Wookie implemented Widget Updates and Chaals indicated [2] he would followup with Opera but I couldn't find a response from them in the list archive. Do we have two (complete?) implementations of the spec? Opera, Richard? It's not clear to me if we should drop this spec (i.e. publish as a WG Note) or if there are sufficient resource commitments to continue to advance it along the REC track. Marcos - what is the status of the test suite http://dev.w3.org/2006/waf/widgets-updates/test-suite/? (The Implementation Report doesn't look good http://dev.w3.org/2006/waf/widgets-updates/imp-report/.) -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0256.html [2] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0261.html On 10/20/12 8:12 AM, ext Arthur Barstow wrote: For various reasons, a Candidate Recommendation of Widget Updates was never published, although the CfC to do so passed and the ED is prepared as such [widget-updates]. Since no one has raised this as an issue, I would like feedback on what we should do with this spec. The main options are: 1) to stop work (and publish a WG Note); 2) to move forward with the CR. I don'tthink it makes much sense to move the spec to CR if we do not have commitments for at least two independent implementations of the CR. Therefore, Implementors should please speak up if they willcommit to implementing this CR. -Thanks, AB [widget-updates] http://dev.w3.org/2006/waf/widgets-updates/ Original Message Subject: CfC: publish Candidate Recommendation of Widget Updates; deadline May 2 Resent-Date: Thu, 26 Apr 2012 16:42:00 + Resent-From: public-native-web-a...@w3.org Date: Thu, 26 Apr 2012 12:41:34 -0400 From: ext Arthur Barstow art.bars...@nokia.com To: public-webapps public-webapps@w3.org CC: public-native-web-a...@w3.org The comment deadline for the Widget Updates LCWD ended April 19. No comments were submitted for that document so this is a Call for Consensus to publish a Candidate Recommendation of the spec using the LC as the basis http://www.w3.org/TR/2012/WD-widgets-updates-20120322/. The Exit Criteria for the CR will be the same as that used for the other widget specs, namely that two or more implementations must pass each test case. This CfC satisfies: a) the group's requirement to record the group's decision to request advancement to CR; and b) General Requirements for Advancement on the Recommendation Track as defined in the Process Document: http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs Positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is May 2 and all comments should be sent to public-webapps at w3.org. -Thanks, AB
