> On Wed, Aug 17, 2016 at 11:38:59, Marijn Kruisselbrink wrote:
> Sorry about that. Somehow that PR slipped through the cracks. I've commented
> on the PR.
>
> Anybody knows what the deal is with the ipr check? What makes it fail, and if
> it fails who is supposed to do what to not make it fail?
The chairs have published details of the Working Group decision
on referencing the Image Description (longdesc) extension in HTML.
In short, most of the CfC carried without objection but there were
some objections related to the longdesc examples.
For convenience, the decision text is pasted below
On Thursday, January 28, 2016 7:46 AM, Chaals McCathie Nevile wrote:
> Now we are three co-chairs, we will work between us to fill Art's shoes.
> It won't be easy.
>
> Thanks Art for everything you've done for the group for so long.
Thanks Art. You were there from the first day I showed up at W3
On Wednesday, April 30, 2014 2:53 PM, Anne van Kesteren wrote:
> In a private thread with one of the editors I suggested the following
> as replacement for the current API:
>
>
> enum DNTValues { "unspecified", "0", "1" };
>
> [NoInterfaceObject, Exposed=Window,Worker]
> interface NavigatorDNT {
On Tuesday, April 29, 2014 5:46 AM, Anne van Kesteren wrote:
> Both http://www.w3.org/2011/tracking-protection/drafts/tracking-
> dnt.html#exceptions-javascript-api
> and http://www.w3.org/2011/tracking-protection/drafts/tracking-
> dnt.html#exceptions-ww-javascript-api
> are inadequate. They need
On Thursday, December 12, 2013 1:57 PM, Jonas Sicking wrote:
> On Thu, Dec 12, 2013 at 1:45 PM, Joel Weinberger wrote:
> >> But it would suck if the result is that they create their own form
> >> fields using s and/or contenteditable.
> >
> > That's true, although some things like that are already
On Thursday, September 27, 2012 10:43 AM, Travis Leithead wrote:
> > From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On
> >
> > On Thu, Sep 27, 2012 at 7:00 PM, Travis Leithead
> > wrote:
> > > It hasn't been updated in a while, but we're still keen on seeing it
> > move forward
Microsoft supports this call.
On Tuesday, June 26, 2012 11:36 AM, Arthur Barstow wrote:
> Hi All - Arun is back to actively editing the File API spec and this is
> a Call for Consensus to publish a new WD of the spec. Please note that
> Arun will be committing some changes during this CfC and that
Microsoft supports this CfC.
On Wednesday, May 02, 2012 1:20 PM, Arthur Barstow wrote:
> As discussed during WebApps' May 1 f2f meeting [2], the Shadow DOM spec
> is ready for a First Public Working Draft (FPWD) publication and this a
> Call for Consensus (CfC) to do so:
>
> http://dvcs.w3.org/hg
Microsoft supports this call.
On Tuesday, May 1, 2012 9:26 PM, Arthur Barstow wrote:
> During WebApps' May 1 discussion about Web Components, a proposal was
> made ([1],[2]) to stop work on the XBL2 spec and this is a Call for
> Consensus to do do.
>
> If you have any comments or concerns about t
On Tuesday, January 10, 2012 12:34 PM, Arun Ranganathan wrote:
> Greetings Adrian,
>
> Sorry for the delay in responding to this email.
>
> Strictly speaking, we could remove the Blob Protocol Version (BLV) [1]. It
> isn't returned in getAllResponseHeaders. BLV 's purpose was in case the
> prot
I will wait to see the proposed text but in the meantime point out that
Microsoft has regulatory obligations that require us to direct customers to
these specifications until such time as there is a completed Recommendation
that succeeds them. As a consequence we want to make sure these customer
Microsoft is open to adding this to the WebApps charter.
We certainly want to see work on a speech API for user agents proceed at W3C.
Our priorities for the API are 1) a procedural (JavaScript) API and 2) a
declarative syntax for speech recognition and text-to-speech in HTML. We think
WebApps
On Wednesday, December 14, 2011 10:46 AM, Glenn Maynard wrote:
> > We can certainly talk through some of these issues, though the amount of
> > work we'd need to do doesn't go down. Our proposal is a small change to
> > the lifetime management of the Blob URL and was relatively simple (for
> > us)
On Wednesday, December 14, 2011 2:26 AM, Jonas Sicking wrote:
> On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren
> wrote:
> > On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman
> > wrote:
> >> This means that you can do something like:
> >>
> >> im
On Wednesday, December 14, 2011 1:43 AM, Anne van Kesteren wrote:
> On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman
> wrote:
> > This means that you can do something like:
> >
> > imgElement.src = URL.createObjectURL(blob,false)
> >
> > and not worry about h
On Wednesday, December 14, 2011 3:38 AM, Marcos Caceres wrote:
> On Wednesday, December 14, 2011 at 1:03 AM, Adrian Bateman wrote:
>
> > The current spec requires the opaque string in Blob URLs to be at least
> > 36 characters in length [1]. Our implementation doesn't curre
On Tuesday, December 13, 2011 10:41 PM, Simon Pieters wrote:
> On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman
> wrote:
> > At TPAC [1,2] I described our proposal for adding an isReusable flag
> > to createObjectURL. A common pattern we have seen is the need for a
> > b
At TPAC [1,2] I described our proposal for adding an isReusable flag to
createObjectURL. A common pattern we have seen is the need for a blob URL
for a single use (for example, loading into an element) and then
revoking the URL. This requires a fair amount of boilerplate code to
handle the load/er
Another topic that came up at TPAC was readAsBinaryString [1]. This method
predates support for typed arrays in the FileAPI and allows binary data
to be read and stored in a string. This is an inefficient way to store
data now that we have ArrayBuffer and we'd like to not support this method.
At T
The current spec requires the opaque string in Blob URLs to be at least
36 characters in length [1]. Our implementation doesn't currently use a
UUID and the length of the string is shorter than 36 characters. While
I have no problem with the recommendation to use UUIDs in the spec,
since it isn't a
The current spec defines the Blob Protocol Version [1]. Our current
implementation
doesn't require a protocol version and the way protocol handlers are defined in
Internet Explorer does require this. I don't know if this is ever exposed in
the web platform. The spec says that this should be return
Following the discussion we had at TPAC [1], we have uploaded our draft as
an editor's draft to Mercurial:
http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
This is just a starting point for discussion and we're looking forward to
incorporating feedback as we move forward. We know there
On Thursday, November 24, 2011 5:16 AM, Arthur Barstow wrote:
> Below, Darin proposes the Pointer Lock [PL] (formerly known as Mouse
> Lock) spec and the Gamepad [GP] spec be added to the Web Applications
> WG's charter and not the Web Events WG's charter. This is a Call for
> Consensus to accep
On Thursday, December 01, 2011 5:12 AM, Anne van Kesteren wrote:
> On Thu, 01 Dec 2011 13:29:37 +0100, Arthur Barstow
> wrote:
> > It appears Adrian is proposing:
> >
> > .../TR/XMLHttpRequest/ be a WG Note but it's not clear to me what
> > version of XHR would be used: the 3-Aug-2010 XHR CR,
On Wednesday, November 30, 2011 5:43 AM, Arthur Barstow wrote:
> Anne completed his merge XHR and XHR2 merge and the new History section
> includes information about the merge. As such, this is a Call for
> Consensus to publish a new WD of XHR using the following ED (not yet
> "pub ready") as th
On Tuesday, November 08, 2011 5:37 AM, Robin Berjon wrote:
> On Nov 3, 2011, at 05:38 , Arthur Barstow wrote:
> > Well, we may get together more frequently than just the annual TPAC meeting
> week. If folks think that would be useful (e.g. in 6 months), please speak up
> and we can take it from the
On Friday, November 04, 2011 4:59 PM, Arthur Barstow wrote:
> One of the topics discussed this week was to designate a "Test Spec
> Editor(s)" for each of our specs.
We're supportive of this idea.
> (BTW, the title of "Test Spec Editor" is a bit of a straw-man, so
> proposals for other titles are
ISSUE-182 to drive that change.
Cheers,
Adrian.
On Thursday, September 29, 2011 3:28 PM, Arun Ranganathan wrote:
> On 6/6/11 4:36 PM, Adrian Bateman wrote:
> > On Monday, June 06, 2011 5:56 AM, Arthur Barstow wrote:
> >> Hi Arun, Jonas, All,
> >>
> >> The last
There has been discussion in this group now and again about the need for stream
support as part of the File APIs including recently in the threads about
Streaming
Blobs [1] and XHR streaming [2]. I've also had several private conversations
with
members of the WG about the need we see for this kin
Microsoft supports this call.
On Tuesday, September 20, 2011 4:05 AM, Arthur Barstow wrote:
> This is a Call for Consensus to publish a Last Call Working Draft of the
> Web Socket API using the following document as the basis:
>
>http://dev.w3.org/html5/websockets/
>
> As noted in [1], this
Today we shipped Microsoft Internet Explorer 10 Platform Preview 3 as part of
the Windows 8 Developer Preview. Alongside this release, we have submitted
interop tests for several WebApps specs for review by the working group:
WebSockets API (101 tests/assertions)
Changeset: http://dvcs.w3.org/hg
On Wednesday, September 07, 2011 9:53 AM, Arthur Barstow wrote:
> It appears the majority of the people that voiced an opinion on this
> thread prefer "DOM4".
>
> If anyone objects to DOM4, please speak up by September 9 at the latest
> and include the rationale for your objection as well as an a
On Thursday, August 11, 2011 3:29 AM, Arthur Barstow wrote:
> [ Topic changed to how to organize the group's DOM specs ... ]
>
> Hi Adrian, Anne, Doug, Jacob, All,
>
> The WG is chartered to do maintenance on the DOM specs so a question for
> us is how to organize the DOM specs, in particular, wh
On Monday, August 15, 2011 2:22 AM, Anne van Kesteren wrote:
> On Thu, 04 Aug 2011 21:21:46 +0200, Anne van Kesteren
> wrote:
> > On Thu, 04 Aug 2011 21:06:58 +0200, Adrian Bateman
> > wrote:
> >> The name was changed. We weren't terribly keen on the change. It is
On Wednesday, August 10, 2011 10:18 AM, Arthur Barstow wrote:
> Anne, Ms2ger, All,
>
> Anne and others proposed in [Proposal] the DOM 2 View Recommendation
> [D2V] be "rescinded". The rescinding process is defined in the Process
> Document [Rescind]. However, Ian Jacobs just indicated in IRC
> [#
On Thursday, August 04, 2011 11:51 AM, Anne van Kesteren wrote:
> On Thu, 04 Aug 2011 20:24:47 +0200, Adrian Bateman
> wrote:
> > 1. We have received feedback from both customers and teams at Microsoft
> > that the name DOM Core is causing confusion with the previous ver
On Wednesday, August 03, 2011 7:12 AM, Arthur Barstow wrote:
> Anne would like to publish a new WD of DOM Core and this is a Call for
> Consensus (CfC) to do so:
>
>http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
>
> Agreeing with this proposal: a) indicates support for publishing a n
Microsoft supports this CfC.
On Tuesday, July 26, 2011 7:13 AM, Arthur Barstow wrote:
> The pre-LC comment period for Progress Events resulted in no comments
> [1]. As such, Anne proposes a new LC be published and this is a CfC to
> do so:
>
> http://dev.w3.org/2006/webapi/progress/
>
> This CfC
On Monday, July 25, 2011 1:32 PM, Aryeh Gregor wrote:
> On Thu, Jul 21, 2011 at 1:02 PM, Adrian Bateman
> wrote:
> > For platform features that directly affect web developers' pages that might
> > sometimes be true. However, compression is also optional in HTTP and it
>
On Thursday, July 21, 2011 12:33 PM, Ian Hickson wrote:
> On Thu, 21 Jul 2011, Adrian Bateman wrote:
> >
> > For platform features that directly affect web developers' pages that
> > might sometimes be true. However, compression is also optional in HTTP
> > and
On Thursday, July 21, 2011 8:31 AM, Anne van Kesteren wrote:
> On Thu, 21 Jul 2011 17:26:21 +0200, Arthur Barstow
> wrote:
> > What do others (Anne?, Maciej?, ...) think about this issue?
>
> I don't know enough about the WebSocket protocol, but optional web
> platform features suck. They will b
On Monday, July 18, 2011 12:52 PM, Michael Nordman wrote:
> The problem is around naming the binary parts attached to
> multi-part-form-encoded
> FormData. I think I'm in favor of the more direct solution to this problem,
> providing a FormData.append() variant that optionally allows the caller t
for binary data-- base64 encoding otherwise
> only works on DOMString.
>
> I'd like to see both proposals implemented... Then I get everything!
> On Jul 11, 2011, at 12:21 PM, Adrian Bateman wrote:
> > It requires more work for us. Our createObjectURL doesn't require tha
Phone
From: Charles Pritchard
Sent: 11-Jul-11 12:03 PM
To: Adrian Bateman
Cc: Jonas Sicking; Anne van Kesteren; Julian Reschke; Alfonso Martínez de
Lizarrondo; Webapps WG
Subject: Re: [XHR2] Blobs, names and FormData
getFile could work with dataTransfer for dropping files onto the desktop.
On 11 July 2011 10:53, Jonas Sicking wrote:
On Mon, Jul 11, 2011 at 10:12 AM, Adrian Bateman wrote:
> > Some content management systems use the original filename by default
> > when storing files in document libraries. It's certainly a lesser use case
> > but seems li
On 11 July 2011 10:02, Jonas Sicking wrote:
> Additionally, what is the use case of being able to set the filename
> during a FormData submission? My perception was that the main use case
> was to not get an empty filename as many serverside implementations of
> multipart/form-data did not deal wel
On Friday, July 08, 2011 1:12 PM, Ian Hickson wrote:
> > 12917 - "deflate-stream" should be an optional extension when
> establishing a connection
> > Resolved, WontFix
> > MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling
> the protocol spec
> > on what is optional in the proto
On Thursday, July 07, 2011 10:21 PM, Arun Ranganathan wrote:
> On 7/6/11 10:13 PM, Cameron McCormack wrote:
> > There was a recent change in Web IDL which made interface types (like
> > the readAsXXX argument types) not include null by default, and if you
> > want to allow null, to write it as “Typ
On Thursday, July 07, 2011 3:55 PM, Jonas Sicking wrote:
On Thu, Jul 7, 2011 at 3:00 PM, Adrian Bateman wrote:
> > 12917 - "deflate-stream" should be an optional extension when establishing
> > a connection
> > Resolved, WontFix
> > MICROSOFT PROPOSAL: We s
We're keen to resolve the remaining issues with the WebSockets API and have a
timetable
to get to Candidate Recommendation. From informal conversations we've had, we
believe
other browser vendors share this goal. I think the current WebSocket API is
feature
complete and meets the requirements fo
Microsoft supports publishing a Last Call working draft of the Web IDL spec.
We believe that the spec is feature complete and meets the requirements below.
While we have a few reservations about Exceptions and share some of the concerns
voiced in the separate thread on that topic, we believe that c
http://dev.w3.org/2006/webapi/FileAPI/#reading-a-file
What is the expected behaviour for FileReader.readAsXXX(null)? Currently
I think both IE10 and Chrome fail silently and there are no events fired
whereas Firefox appears to throw an internal NS_ERROR_INVALID_POINTER
exception.
The spec doesn't
Just catching up with this thread. We ran into the same problem last week while
investigating FormData and XHR. Since FormData is designed to allow XHR to
interact
with existing form end-points that usually required a navigation, we've found
that
few of them have been tested with empty filenames.
On Wednesday, June 22, 2011 3:24 PM, James Robinson wrote:
> On Wed, Jun 22, 2011 at 2:42 PM, Aryeh Gregor
> wrote:
> > On Mon, Jun 20, 2011 at 10:50 PM, Boris Zbarsky wrote:
> > > Note that there are currently major browsers that do not follow the spec
> > > as
> > > currently written and have
On Friday, June 10, 2011 7:05 AM, Arthur Barstow wrote:
> Adrian - this bug is for the Web Sockets API spec (and not Web Storage),
> correct?
>
> On Jun/8/2011 1:21 PM, ext bugzi...@jessica.w3.org wrote:
> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12913
Yes - corrected now, thanks!
On Tuesday, June 07, 2011 10:36 AM, Ian Hickson wrote:
> On Tue, 7 Jun 2011, Adrian Bateman wrote:
> > This check-in [1] reintroduces the onerror handler that was removed
> > previously [2]. Since, in general, WebSocket protocol errors are fatal
> > and result in onclose, w
On Tuesday, June 07, 2011 10:36 AM, Ian Hickson wrote:
> On Tue, 7 Jun 2011, Adrian Bateman wrote:
> > We have removed onerror from our implementation since the previous
> > change and it's frustrating trying track against the spec with
> > unexpected updates.
>
>
This check-in [1] reintroduces the onerror handler that was removed previously
[2].
Since, in general, WebSocket protocol errors are fatal and result in onclose,
what is
the purpose of adding this back? We have removed onerror from our implementation
since the previous change and it's frustrating
On Monday, June 06, 2011 5:56 AM, Arthur Barstow wrote:
> Hi Arun, Jonas, All,
>
> The last publication of the File API spec [ED] was last October so it
> would be good to publish a new Working Draft in w3.org/TR/.
>
> Since Tracker shows 0 bugs for the spec [Tracker] and the ED does not
> appear
As I proposed in March [1], we think it makes sense to separate the WebSocket
constructor from the operation to initiate the network operation. We proposed a
separate open() method similar to XHR. This allows a WebSocket object to be
constructed and initialised prior to communication. We think t
On Friday, May 27, 2011 4:30 PM, Ian Hickson wrote:
> On Fri, 27 May 2011, Jonas Sicking wrote:
> > For example, what is an implementation supposed
> > to do if a page does:
> >
> > ws.binaryType = otherwindow.ArrayBuffer
> >
> > or
> >
> > otherwindow.useThis(ws);
> > with other window containing
On Friday, May 27, 2011 4:23 PM, Jonas Sicking wrote:
> However, I think there might be another solution to this whole
> situation. There really is no reason that only binary data can be
> received as a Blob. Getting data as a Blob is useful any time you're
> dealing with a large chunk of data wher
I'm pleased to see the changes in the WebSockets API for binary message support.
I'm a little confused by this text:
When a WebSocket object is created, its binaryType IDL attribute must
be set to the Blob interface object associated with the same global
object as the WebSocket constru
First, thanks to Art for pulling all this content together. We're looking
forward to a more structured process for testing as various specifications
in the WebApps increase in maturity.
I have a couple of small comments related to the issues Aryeh raised.
Apologies for the lateness of these commen
On Monday, April 18, 2011 12:04 PM, Jonas Sicking wrote:
> On Mon, Apr 18, 2011 at 9:02 AM, Adrian Bateman
> wrote:
> > On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
> >> Yes. I.e. the semantics of readAsX is basically:
> >>
> >> read
On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
> On Fri, Apr 15, 2011 at 12:53 PM, Adrian Bateman
> wrote:
> > Yes, we could live with it but the semantics are more complex. Is this the
> > same as calling abort() then readAsXXX()?
>
> Yes. I.e. the semantics
On Friday, April 15, 2011 12:16 PM, Arun Ranganathan wrote:
> On 4/15/11 2:57 PM, Adrian Bateman wrote:
> > With this in mind, I don't personally have a strong feeling either way
> > between having to call abort() explicitly or having readAsXXX implicitly
> > call abort
On Tuesday, April 12, 2011 12:08 PM, Jonas Sicking wrote:
> FileReader is extremely similar to XMLHttpRequest. The main difference
> is in how you initiate the request (.open/.send vs. .readAsX). This
> similarity is even getting stronger now that XHR gets .result.
>
> So I think there are good re
On Saturday, April 09, 2011 4:23 AM, Arthur Barstow wrote:
> The Editors of the Indexed Database API would like to publish a new
> Working Draft of their spec and this is a Call for Consensus to do so:
>
> http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
>
> If one agrees with this pr
On Monday, April 11, 2011 10:23 AM, Eric Uhrhane wrote:
> On Mon, Apr 11, 2011 at 9:33 AM, Arun Ranganathan wrote:
> > In general, I'm averse to throwing, since I think it puts an additional
> > burden on the developer (to catch, for example).
>
> I don't think so. I think that calling two read m
On Monday, April 11, 2011 8:28 AM, Arun Ranganathan wrote:
> On 3/31/11 6:12 PM, Eric Uhrhane wrote:
> > I think it's cleaner and simpler just to throw. FileReader and XHR
> > are already different enough that a bit more, as long as it's a
> > usability improvement, isn't a big deal. The efficien
Microsoft supports publishing a new WD.
On Wednesday, April 06, 2011 4:02 AM, Arthur Barstow wrote:
> This is a Call for Consensus (CfC) to publish a new Working Draft of the
> WebSockets API:
>
> http://dev.w3.org/html5/websockets/
>
> Among the reasons to publish a new WD are: the last pub
On Tuesday, April 05, 2011 4:27 AM, Arthur Barstow wrote:
> Hi All,
>
> What needs to be done before the WebSocket API is LC ready?
>
> Bugzilla has three open bugs for this spec:
>
> 1. API for send/receive of binary data? Current IETF protocol drafts
> have binary type. Consider typed arrays (Ar
On Thursday, March 31, 2011 10:19 AM, Arun Ranganathan wrote:
> On 3/30/11 2:01 PM, Eric Uhrhane wrote:
> > On Mon, Mar 28, 2011 at 5:37 PM, Adrian Bateman
> wrote:
> >> Is there a reason for the current spec text?
> > I don't know the original rationale,
a reason for the current spec text?
Thanks,
Adrian.
--
Adrian Bateman
Program Manager - Internet Explorer - Microsoft Corporation
Phone: +1 (425) 538 5111
Email: mailto:adria...@microsoft.com
Microsoft supports this CfC.
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Arthur Barstow
Sent: Thursday, March 03, 2011 5:26 AM
To: public-webapps
Cc: Mark Nottingham; Julian Reschke; Nikunj Mehta
Subject: CfC: to stop work on Programmable HTTP Caching a
Microsoft supports this.
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Arthur Barstow
Sent: Monday, March 07, 2011 9:56 AM
To: public-webapps
Subject: CfC: publish Last Call Working Draft of HTML5 Web Messaging; deadline
March 14
This is a Call for Cons
Apologies for missing the March 7 deadline. We tried to carry out a detailed
pre-Last
Call review and have the following feedback. Microsoft would like to discuss
these
points before moving the Last Call.
Thanks,
Adrian.
Feedback on latest draft of Web Workers
Based on our understanding of t
Microsoft supports this.
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Arthur Barstow
Sent: Wednesday, March 02, 2011 4:08 AM
To: public-webapps
Subject: CfC: publish Last Call Working Draft of Progress Events spec; deadline
March 7
Given no comments we
On Friday, February 25, 2011 1:54 AM, Anne van Kesteren wrote:
> >> The idea is to provide a better definition of the events model at a more
> >> appropriate location. I do not think DOM Level 3 Events is the right way
> >> forward, but I am happy to work in parallel to see which turns out
> >> bet
On Thursday, February 24, 2011 2:37 PM, Anne van Kesteren wrote:
> On Thu, 24 Feb 2011 19:26:19 +0100, Adrian Bateman
> wrote:
> > I'm concerned about the working group endorsing a working draft with
> > phrasing like "The timeStamp attribute must be useless."
As we've been updating our WebSockets prototype [1] in line with the latest
protocol
changes we've been thinking about how the binary support that the protocol now
includes should be reflected in the API. I added the following comment to the
bug:
At Microsoft, we've been reviewing how the bi
On Wednesday, February 23, 2011 8:21 AM, Arthur Barstow wrote:
> Anne and Ms2ger (representing Mozilla Foundation) have continued to work
> on the DOM Core spec and they propose publishing a new Working Draft of
> the spec:
>
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
>
> As such,
On Wednesday, November 24, 2010 3:01 AM, Jeremy Orlow wrote:
> For over a year now, the WebStorage spec has stipulated that
> Local/SessionStorage store and retrieve objects per the structured clone
> algorithm rather than strings. And yet there isn't a single implementation
> who's implemented th
On Tuesday, November 16, 2010 8:11 AM, Jonas Sicking wrote:
> On Tuesday, November 16, 2010, Anne van Kesteren
> wrote:
> > On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking
> wrote:
> >
> > Ok, here is what I'll propose as the final solution:
> >
> > FileAPI will define the following WebIDL:
> >
On Thursday, November 11, 2010 11:47 AM, Jonas Sicking wrote:
> Oh, definitely, we still need the createObjectURL/revokeObjectURL
> functions. Sorry, that was probably unclear.
>
> However we're still left without a place to put them. Maybe it's as
> simple as putting them on the document object?
Microsoft supports publication of a FPWD of Web Messaging.
On Saturday, November 06, 2010 11:49 AM, Arthur Barstow wrote:
> Ian, All - during WebApps' November 1 gathering, participants expressed
> in an interest in publishing a First Public Working Draft of Web
> Messaging [1] and this is a CfC t
Microsoft supports publication as a Working Group Note.
On Saturday, November 06, 2010 5:35 PM, Arthur Barstow wrote:
> During WebApps's November 1 gathering, participants discussed the Web
> SQL Database spec:
>
> http://www.w3.org/2010/11/01-webapps-minutes.html#item09
[...]
> As such, partic
On Tuesday, September 07, 2010 11:46 AM, Chris Prince wrote:
> >> 1. Most people that I talk to dislike the name Blob, much less having
> >> it spread to things like BlobReader.
>
> I could maybe understand this if "blob" were a new term we were
> inventing. But it's not. It's a well-known compu
On Monday, August 30, 2010 1:09 PM, Jonas Sicking wrote:
> On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan
> wrote:
> > *sigh. Naming continues to be hard. Not everyone's thrilled with the
> > proliferation of Blob in the API [1] including other major implementors
> > (my co-editor included ;-
On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote:
> On Mon, Jul 12, 2010 at 9:59 AM, David Levin wrote:
> On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman
> wrote:
> I read point #5 to be only about surviving the start of a navigation. As a
> web developer, how can I tell
On Monday, July 12, 2010 9:32 AM, David Levin wrote:
> On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman
> wrote:
> The behaviour would have to be explicitly specified and not left to depend on
> indeterminate browser implementations.
>
> Yes. Unfortunately, another way of sa
On Monday, July 12, 2010 8:24 AM, David Levin wrote:
> On Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman
> wrote:
> > Making the blob url identical to the lifetime of the blob itself would
> > expose when garbage collection takes place and in general could lead to
> > easy t
On Sunday, July 11, 2010 10:40 PM, David Levin wrote:
> On Sun, Jul 11, 2010 at 10:05 PM, Adrian Bateman
> wrote:
> Hi Arun, I think the updated URL section reflects a good compromise. We
> might want to call out explicitly that "opaque string" should not include
> recog
On Monday, June 28, 2010 2:47 PM, Arun Ranganathan wrote:
> On 6/23/10 9:50 AM, Jian Li wrote:
> I think encoding the security origin in the URL allows the UAs to do
> the security origin check in place, without routing through other
> authority to get the origin information that might cause the c
On Tuesday, June 22, 2010 8:40 PM, David Levin wrote:
> I agree with you Adrian that it makes sense to let the user agent figure
> out the optimal way of implementing origin and other checks.
>
> A logical step from that premise is that the choice/format of the
> namespace specific string should b
On Tuesday, June 22, 2010 3:37 PM, Arun Ranganathan wrote:
> On 6/22/10 8:44 AM, Adrian Bateman wrote:
> > I think it makes more sense for the URL to be opaque and let user
> > agents figure
> > out the optimal way of implementing origin and other checks.
>
> I think it
On Friday, June 11, 2010 11:18 AM, Jonas Sicking wrote:
> On Fri, Jun 11, 2010 at 11:11 AM, Jonas Sicking wrote:
> > On Fri, Jun 11, 2010 at 9:09 AM, Adrian Bateman
> >> It's not clear to me the benefit of encoding the origin into the URL. Do
> >> we expect script
On Wednesday, June 02, 2010 5:35 PM, Jonas Sicking wrote:
> On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan wrote:
> > On 6/2/10 5:06 PM, Jian Li wrote:
> >> In addition,
> >> we're thinking it will probably be a good practice to encode the security
> >> origin in the blob URL scheme, like blobda
1 - 100 of 128 matches
Mail list logo
