Re: Fetch API
On Mon, Jun 2, 2014 at 6:59 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 29, 2014 at 4:25 PM, Takeshi Yoshino tyosh...@google.com wrote: http://fetch.spec.whatwg.org/#dom-request Add steps to set client and context? That happens as part of the restricted copy. However, that might still change around a bit. Ah, ok. http://fetch.spec.whatwg.org/#cors-preflight-fetch-0 Add steps to set client and context? That's an internal algorithm never directly used. You can only get there from http://fetch.spec.whatwg.org/#concept-fetch and that can only be reached through an API such as fetch(). Right. But preflight's client and context are not initialized before invoking HTTP fetch (http://fetch.spec.whatwg.org/#concept-http-fetch). client is referred in HTTP fetch. BTW, handle a fetch is a dead link. https://slightlyoff.github.io/ServiceWorker/spec/service_worker/handle-a-fetch The promise is rejected with a TypeError which seems inconsistent with XHR. Is this intentional? Yes. I wanted to stick to JavaScript exceptions. However, I suspect at some point once we have FormData integration and such there might be quite a bit of dependencies on DOM in general, so maybe that is moot. Got it. Thanks.
Re: Fetch API
For XHR.send(), we've finally chosen to accept only ArrayBufferView. http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0141.html Do we want to do the same for FetchBody body of RequestInit?
[Bug 25970] New: [WebSocket API] What Step 1 means is unclear. And typo report
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25970 Bug ID: 25970 Summary: [WebSocket API] What Step 1 means is unclear. And typo report Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) Assignee: i...@hixie.ch Reporter: tyosh...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html http://dev.w3.org/cvsweb/html5/websockets/Overview.html.diff?r1=1.310;r2=1.311;f=h What step 1 actually means is not so clear. Maybe step 1 of processing model for event loops. http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-7 Could you please add some text and point the processing model section? http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#garbage-collection-1 s/started reached step 1/reached step 1/ -- You are receiving this mail because: You are on the CC list for the bug.
Re: Fetch API
On Wed, Jun 4, 2014 at 8:13 AM, Takeshi Yoshino tyosh...@google.com wrote: On Mon, Jun 2, 2014 at 6:59 PM, Anne van Kesteren ann...@annevk.nl wrote: That's an internal algorithm never directly used. You can only get there from http://fetch.spec.whatwg.org/#concept-fetch and that can only be reached through an API such as fetch(). Right. But preflight's client and context are not initialized before invoking HTTP fetch (http://fetch.spec.whatwg.org/#concept-http-fetch). client is referred in HTTP fetch. Thanks! And my apologies for not getting that straight away. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25971 BTW, handle a fetch is a dead link. https://slightlyoff.github.io/ServiceWorker/spec/service_worker/handle-a-fetch Fixed. -- http://annevankesteren.nl/
Re: Fetch API
On Wed, Jun 4, 2014 at 8:30 AM, Takeshi Yoshino tyosh...@google.com wrote: For XHR.send(), we've finally chosen to accept only ArrayBufferView. http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0141.html Do we want to do the same for FetchBody body of RequestInit? What I really want is for IDL to be fixed as technically we cannot mention ArrayBuffer and ArrayBufferView in IDL as they are not IDL-defined constructs: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369 I'd like something in IDL where I can just say this accepts bytes and I want to return bytes, and IDL handles the complexities and ensures all APIs are compatible on this. What we did for XMLHttpRequest was probably a mistake as we could not make it an overarching policy. -- http://annevankesteren.nl/
Re: Fetch API
On Tue, Jun 3, 2014 at 9:00 PM, Jonas Sicking jo...@sicking.cc wrote:
One thing we should keep in mind is if we actually need to support
100% of all the crazyness that servers do. And especially if we need
to support it in a particularly convenient way.
Yes, that is https://github.com/slightlyoff/ServiceWorker/issues/300
Feedback would be greatly appreciated. Given Mark's latest comment
there it seems the current API might be broken.
Does ES define the order of { x: a, y: b } btw?
--
http://annevankesteren.nl/
Re: HTML imports: new XSS hole?
On Tue, Jun 3, 2014 at 7:20 PM, Oda, Terri terri@intel.com wrote: Perhaps it would make sense to also require explicit allowing of imports via CSP? Scripts are allowed when no CSP is provided for historical compatibility so you'd need to make sure that imports fell under a separate directive, but there's no need for backwards compatibility so it probably makes sense to choose a more conservative default behaviour for HTML Imports. Using script import seems like a solution that would be better in that case, as it does not provide opt-in through HTTP. Whenever we require HTTP for a feature, we get a ton of complaints. And script import is not that bad authoring-wise either: script import/script link rel=import href (Okay, you win two code points if you omit the quotes with link.) -- http://annevankesteren.nl/
Re: Fetch API
On Wed, Jun 4, 2014 at 9:49 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jun 4, 2014 at 12:31 AM, Anne van Kesteren ann...@annevk.nl wrote:
Does ES define the order of { x: a, y: b } btw?
I believe so, but someone would need to check. Either way I think
browsers effectively are forced to return a consistent order for
web-compat reasons.
I checked. It's not true, see
http://esdiscuss.org/topic/for-in-evaluation-order#content-10 See
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ordinary-object-internal-methods-and-internal-slots-enumerate
for the specification. It seems in particular implementations will
differ on numeric keys, potentially other bits.
--
http://annevankesteren.nl/
[Bug 18701] FileSystem/FileWriter API needs a method to flush/sync
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18701 Art Barstow art.bars...@nokia.com changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@nokia.com Resolution|--- |WONTFIX --- Comment #1 from Art Barstow art.bars...@nokia.com --- Work on this specification has stopped. -- You are receiving this mail because: You are on the CC list for the bug.
Multiple send() calls in XmlHttpRequest
According to the spec, the send() method of XmlHttpRequest objects enable an internal 'send()' flag showing that the request has been done, and not allowing to do several requests on the same XHR object, although the current API with an open() method leads to think that's possible. Due to this, I propose to allow to do several send() calls on an open XHR object. I know that the mayority of use cases are a simple one-shoot calls so this request would be useless, but there are use cases like JsonRPC-over-HTTP where it makes sense, so I think it would be a good requeriment (and the most intuitive) that you could be able to do several send() calls if it's defined a Connection Keep-Alive header. -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
Re: Multiple send() calls in XmlHttpRequest
On Wed, Jun 4, 2014 at 2:45 PM, pira...@gmail.com pira...@gmail.com wrote: According to the spec, the send() method of XmlHttpRequest objects enable an internal 'send()' flag showing that the request has been done, and not allowing to do several requests on the same XHR object, although the current API with an open() method leads to think that's possible. Due to this, I propose to allow to do several send() calls on an open XHR object. The send() flag is only set as long as the fetch is ongoing. Once the fetch has finished, it is no longer set. So this is already possible. -- http://annevankesteren.nl/
Re: Multiple send() calls in XmlHttpRequest
The send() flag is only set as long as the fetch is ongoing. Once the fetch has finished, it is no longer set. So this is already possible. I did some tests some months ago and I was not be able to achieve it, nor found any info or examples on Internet about if it's or it's not possible. So, is it possible with current spec/implementations, or could it be added? If it's currently possible, how could it be done? Waiting to the load event? KeepAlive header? Both at the same time? If so, it would be good to add a minimal example on the spec about this somewhat (undocumented?) corner-case just for reference... :-) -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
Re: Multiple send() calls in XmlHttpRequest
On Wed, Jun 4, 2014 at 3:05 PM, pira...@gmail.com pira...@gmail.com wrote:
The send() flag is only set as long as the fetch is ongoing. Once the
fetch has finished, it is no longer set. So this is already possible.
I did some tests some months ago and I was not be able to achieve it,
nor found any info or examples on Internet about if it's or it's not
possible.
You need to invoke open() to set the object in the proper state.
!DOCTYPE html
script
var client = new XMLHttpRequest,
i = 0
client.open(GET, image);
client.send()
client.onload = function() { w(i); i++; client.open(GET, image);
this.send() }
/script
--
http://annevankesteren.nl/
Re: Multiple send() calls in XmlHttpRequest
You need to invoke open() to set the object in the proper state. Ok, good trick (didn't know it, thanks :-) ), but I was asking about with just one call to .open(), being able to call several times to .send(). That's why I did the reference to KeepAlive header. -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
[admin] Process/Policy/Expectations for spec-specific distributed meetings
Hi All, Yesterday I received a request to hold a spec-specific distributed meeting, with the expectation the meeting would use the #webapps IRC channel as well as the Consortium's voice conference system. Although I fully support this proposal, and encourage all Editors and active contributors to have similar meetings, we also need to make sure that everyone in our world-wide group has an opportunity to participate in such meetings. To frame the general requirements for these types of meetings, I just updated WorkMode and added a small set of general requirements regarding the process, policy and expectations for these types of meetings. The points are pretty basic yet I think they cover the main constraints. [[ https://www.w3.org/2008/webapps/wiki/WorkMode#Meetings.3F_What_Meetings.3F Editors and active collaborators are encouraged to have spec-specific distributed meetings to discuss high priority bugs, to gather input on a specific topic, etc. To facilitate broad participation in these meetings including participants from across the globe, please note: * Meetings must be announced on the relevant e-mail list at least 48 hours before the meeting will begin and much earlier is highly recommended * The announcement should include a day + time that is acceptable to the expected participants. If that information is not known, a related discussion should begin before the meeting announcement such that a mutually agreeable time is known when the meeting is announced. * The meeting must use the W3C's #webapps IRC and the RRSAgent Meeting Minute bot * The meeting may use the Zakim Voice Conference system and requests to reserve a slot should be sent to team-weba...@w3.org at least 48 hours before the meeting starts. * Within 48 hours of the meeting ending (although sooner is preferred), the meeting's minutes must be sent to the e-mail list used in the meeting's announcement. ]] I'd like to follow the KISS principle as much as possible here but if something important is missing or unclear, that should be fixed. Comments, as always, are welcome. -Thanks, AB
Editing Conference Call June 6th
Hi WebApps, There will be a conference call on June 6th at 08:00 (8am) San Francisco time (PST) to discuss the recent editing topics contentEditable=minimal and CommandEvent[1]. We will be on #webapps with Zakim and will send minutes to this list. The pin and further details will be sent before the call. Sorry for the late notice- any future calls on this subject will have more advanced notice. ?Your participation is welcome and encouraged. Thanks! Ben [1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0582.html
File API For Review | was Re: Blob URL Origin
The 2 June 2014 Editor’s Draft of the File API solves some bugs and technical issues with Blob URLs. Review is encouraged, with a view towards a LCWD publication: http://dev.w3.org/2006/webapi/FileAPI/ In particular: 1. It nails down syntax differences between user agents on Blob URLs. 2. It specifies origin and origin extraction from Blob URL strings. 3. It provides other pieces of plumbing that specifications like URL and Fetch can use. A few issues remain, but all of these have dependencies: https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemail1=arun%40mozilla.comemailassigned_to1=1emailreporter1=1emailtype1=exactlist_id=38706 Notably, dependencies on Fetch (for Fetch of Blob URLs), and dependencies on WebIDL (e.g. removing DOMError altogether requires something done for error handling; supplanting FileList with array requires this part nailed down). I’m happy to have provisional specification text in place before WebIDL adopts fixes, but with guidance from the editor(s) of WebIDL. I expect a CfC to follow about the specification. — A* On May 29, 2014, at 5:42 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 29, 2014 at 8:38 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, May 22, 2014 at 1:29 AM, Anne van Kesteren ann...@annevk.nl wrote: For fetching blob URLs (and prolly filesystem and indexeddb) we effectively act as if the request's mode was same-origin. Allowing tainted cross-origin requests would complicate UUID (for the UA) and memory (for the page) management in a multiprocess environment. Hmm.. I think that is effectively it yes. I.e. even though img says that it wants to permit cross-origin loads, we'd override that if the fetch is for a blob: URL and only permit same-origin loads. Is that what you mean? Yes. However, I wonder if this at a standards level should come into play in the URL parser. After all that creates a structured clone of the blob in question. The lookup for the blob ID should probably fail at that point meaning it does not really matter when you then try to fetch that URL as it will simply not have an associated blob. -- http://annevankesteren.nl/
[editing] CommandQuery Object and Event
There has been some conversation about browser UI for Commands with
ContentEdtiable=minimal. Some people seem to believe that UI should not be
displayed because it may not be relevant. One way to solve this is to have an
event that would allow script to tell the browser what is relevant. Today,
there are several ways to ask the browser if a given command is
enabled/relevant. This includes queryCommandEnabled, queryCommandSupported, and
QueryCommandValue. However, the site is not able to influence the return value
of these events. In order to give more power to browsers, frameworks, and
sites, it seems to make sense to allow these values to be modified. Therefore I
propose a new method:
document.queryCommand(commandName)
which returns a new read-only object (called CommandQuery for now):
CommandQuery
{
Boolean isSupportedByUA;
Boolean isSupported;
Boolean isEnabled;
Object currentValue;
}
By default, this object will match the browser's support for this command in
the current context. However, before it returns, a CommandQuery event will fire
with a read/write CommandQuery object. If a framework or site wishes to
indicate different values for the command state, it can do so in that event.
CommandQueryEvent: Event {
{
CommandQuery commandQuery;
}
In this way, a framework can enable commands that a browser does not natively
support. Further, a browser could fire CommandQueryEvents to determine the
correct toolbar buttons to display. Thoughts?
Ben
Re: Fetch API
On Wed, Jun 4, 2014 at 2:46 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Jun 4, 2014 at 9:49 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jun 4, 2014 at 12:31 AM, Anne van Kesteren ann...@annevk.nl wrote:
Does ES define the order of { x: a, y: b } btw?
I believe so, but someone would need to check. Either way I think
browsers effectively are forced to return a consistent order for
web-compat reasons.
I checked. It's not true, see
http://esdiscuss.org/topic/for-in-evaluation-order#content-10
Ah. So the enumeration order for { x: a, y: b } is actually
consistent across browsers. But once you start doing more complex
things than that, like sticking enumerable properties on the prototype
chain, or deleting properties, then the order is not consistent.
I would still be ok with allowing a plain JS object being passed. If
differences in order for complex operations hasn't bitten people for
JS enumeration, then maybe it won't for header order either.
/ Jonas
Re: Editing Conference Call June 6th
On 6/4/14 11:42 AM, Ben Peters wrote: There will be a conference call on June 6th at 08:00 (8am) San Francisco time (PST) to discuss the recent editing topics contentEditable=minimal and CommandEvent[1]. We will be on #webapps with Zakim and will send minutes to this list. The pin and further details will be sent before the call. Sorry for the late notice-any future calls on this subject will have more advanced notice. Your participation is welcome and encouraged. The general logistics (IRC Voice Conference info) for this call are the same as for all of WebApps' other meetings: https://www.w3.org/wiki/Webapps/Meetings#General_Information. The PIN for the June 6 call is 9274. For links to some meeting-related resources such as tutorials for the RRSAgent bot, see https://www.w3.org/wiki/Webapps/Meetings#IRC_and_Meeting_Resources and as well as the following Scribe cheat sheet I wrote for the Pointer Events WG: https://www.w3.org/wiki/PointerEvents/Meetings#Meeting_Scribes. -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0582.html
RE: contentEditable=minimal
DOM L3 does require implementations to fire composition event for dead-key combinations, so insofar as the (Alt-`) combo results in a dead key for accent-grave (and other dead key combos mentioned below), the composition events should (or are supposed to) fire as a result. -Original Message- From: Ben Peters [mailto:ben.pet...@microsoft.com] Sent: Monday, June 2, 2014 2:00 PM To: Robin Berjon; Julie Parent Cc: Johannes Wilm; public-webapps@w3.org Subject: RE: contentEditable=minimal Great context. Thanks! Let me ask my question another way- should CompositionEvents be used when there isn't a composition? Should typing 'a' fire CompositionEnd? If not we still need a CommandEvent of type insertText, and it seems inconsistent not to fire it for all typing, doesn't it? From: Robin Berjon [mailto:ro...@w3.org] On 27/05/2014 01:52 , Ben Peters wrote: From: Robin Berjon [mailto:ro...@w3.org] On 23/05/2014 01:23 , Ben Peters wrote: As I said I am unsure that the way in which composition events are described in DOM 3 Events is perfect, but that's only because I haven't used them in anger and they aren't supported much. My thought is that we can use CommandEvent with type=insertText. This would be the corollary to execComamnd(insertText), and the data would be the ñ that is about to be inserted. But if you only get one event you can't render the composition as it is carrying out. I believe Composition Events are very important for IME input, but we should fire CommandEvent with Insert text for all text input, including IME. Are you saying we should use Composition Events even for non-IME input? I am not using an IME, and yet I could not type in French on my keyboard without composition. Obviously, if I switch to Kotoeri input, I'll get composition *and* an IME popup. But for regular French input (in a US keyboard) I need: é - Alt-E, E è - Alt-`, E à - Alt-`, A ô - Alt-I, O ü - Alt-U, U ñ - Alt-˜, N (for the occasional Spanish) (and a bunch more) Some older apps (you pretty much can't find them anymore) used to not display the composition as it was ongoing and only show the text after composition had terminated. That was survivable but annoying, and it only worked because composition in Latin-script languages is pretty trivial (except perhaps for all you Livonian speakers out there!), but I don't think it would be viable for more complex compositions. And even in simple cases it would confuse users to be typing characters with no rendering feedback. Without composition events you can't render the ongoing composition. See what's going on at: https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html - L81 That is basically inserting text in a range that's decorated to be underlined to show composition in progress. Composition updates *replace* the text in the range. And at the end the range is removed and text is inserted. The above is for Mac, but I have distant memories of using something similar on Windows called the US International Keyboard where you could have apostrophes compose as accents, etc.. I don't recall how it was rendered though. -- Robin Berjon - http://berjon.com/ - @robinberjon
