Re: jar protocol

On Thu, May 9, 2013 at 9:36 AM, Marcos Caceres wrote: > On Wednesday, May 8, 2013 at 2:05 PM, Robin Berjon wrote: >> How do you figure out media types? Is it just sniffing, or do you have >> some sort of file extensions mapping as well? > > Sniffing would probably sufficient. The types on the web

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Tue, May 7, 2013 at 2:54 PM, Jonas Sicking wrote: > I'd be worried about letting any resolved URL to hold a reference to > the Blob. We are playing very fast and loose with URLs in Gecko and > it's never been intended that they hold on to any resources of > significant

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Tue, May 7, 2013 at 9:45 AM, Anne van Kesteren wrote: >> >> On Mon, May 6, 2013 at 11:11 PM, Jonas Sicking wrote: >> > The only thing that's different about XHR is that the first step in my >> > list lives in one function, and the other steps live in another &

Re: jar protocol (was: ZIP archive API?)

On Tue, May 7, 2013 at 7:29 AM, Robin Berjon wrote: > On 06/05/2013 20:42 , Jonas Sicking wrote: >> >> The only things that implementations can do that JS can't is: >> * Implement new protocols. I definitely agree that we should specify a >> jar: or archive: pr

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Mon, May 6, 2013 at 5:57 PM, Anne van Kesteren wrote: > On Mon, May 6, 2013 at 5:45 PM, Jonas Sicking wrote: >> On Mon, May 6, 2013 at 4:28 PM, Anne van Kesteren wrote: >>> Okay. So that fails for XMLHttpRequest :-( >> >> What do you mean? Those are the step

Re: ZIP archive API?

On Mon, May 6, 2013 at 6:36 PM, Glenn Maynard wrote: > On Mon, May 6, 2013 at 8:01 PM, Jonas Sicking wrote: >> >> On Mon, May 6, 2013 at 5:15 PM, Glenn Maynard wrote: >> > I'm not aware of any optimized inflate implementation in JS to compare >> > aga

Re: ZIP archive API?

On Mon, May 6, 2013 at 5:15 PM, Glenn Maynard wrote: > I'm not aware of any optimized inflate implementation in JS to compare > against, and it's a complex algorithm, so nobody is likely to jump forward > to spend a lot of time implementing and heavily optimizing it just to show > how slow it is.

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Mon, May 6, 2013 at 4:28 PM, Anne van Kesteren wrote: > On Sun, May 5, 2013 at 5:37 PM, Jonas Sicking wrote: >> What we do is that we >> >> 1. Resolve the URL against the current base URL >> 2. Perform some security checks >> 3. Kick off a network fetch >

Re: ZIP archive API?

On Mon, May 6, 2013 at 4:27 AM, Robin Berjon wrote: > On 03/05/2013 21:05 , Florian Bösch wrote: >> >> It can be implemented by a JS library, but the three reasons to let the >> browser provide it are Convenience, speed and integration. > > Also, one of the reasons we compress things is because th

Re: Fetch: HTTP authentication and CORS

On Mon, May 6, 2013 at 10:45 AM, Hallvord Reiar Michaelsen Steen wrote: >> I had a discussion with Hallvord on IRC about the exact semantics we >> want for HTTP authentication in the context of CORS (and in particular >> for XMLHttpRequest, though it would also affect e.g. > crossorigin>). > > So

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Fri, May 3, 2013 at 6:55 AM, Anne van Kesteren wrote: > On Thu, May 2, 2013 at 12:53 AM, Jonas Sicking wrote: >> It actually has turned out to be surprisingly easy in Gecko. But I >> realize the same might not be true everywhere. > > Can we have a description of this (an

Re: Fetch: HTTP authentication and CORS

ically for credential-less CORS requests. Sorry I can't be more precise. I'm happy to point people to the relevant code if needed. / Jonas On Sat, May 4, 2013 at 3:58 PM, Bjoern Hoehrmann wrote: > * Jonas Sicking wrote: >>On May 4, 2013 1:29 AM, "Anne van Kesteren" wr

Re: Fetch: HTTP authentication and CORS

On May 4, 2013 1:29 AM, "Anne van Kesteren" wrote: > > On Fri, May 3, 2013 at 7:00 PM, Jonas Sicking wrote: > > In the Gecko implementation they aren't. Assuming that you mean when with > > credentials is set to false? > > Right, when it's set to f

Re: ZIP archive API?

On May 3, 2013 4:20 PM, "Charles Pritchard" wrote: > > On May 3, 2013, at 3:18 PM, Jonas Sicking wrote: > > >> platforms, but it matters a great deal > >> on underpowered devices such as mobiles. > > > > Show me some numbers to back this up and

Re: ZIP archive API?

On Fri, May 3, 2013 at 12:12 PM, Paul Bakaus wrote: > > > From: Florian Bösch > Date: Fri, 3 May 2013 21:05:17 +0200 > To: Jonas Sicking > Cc: Paul Bakaus , Anne van Kesteren , > Webapps WG , Charles McCathie Nevile > , Andrea Marchesini > > Subject: Re:

Re: ZIP archive API?

The big question we kept running up against at Mozilla is "why couldn't this simply be implemented as a JS library?" If performance is the argument we need to back that up with data. / Jonas On May 3, 2013 10:51 AM, "Paul Bakaus" wrote: > Hi Anne, Florian, > > I think the first baby step, or

Re: Fetch: HTTP authentication and CORS

In the Gecko implementation they aren't. Assuming that you mean when with credentials is set to false? We also don't reuse keep-alive http connections. / Jonas On May 3, 2013 10:34 AM, "Adam Barth" wrote: > How does withCredentials interact with TLS client certificates? Ideally > they wouldn't

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Wed, May 1, 2013 at 4:25 PM, Eric U wrote: > On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan wrote: >> Switching the default to "false" would enable IE, Chrome, andFirefox to have >> interoperability with URL.createObjectURL(blobArg), though such a default >> places burdens on web developer

Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

On Wed, May 1, 2013 at 12:15 PM, Dimitri Glazkov wrote: > On Wed, May 1, 2013 at 11:49 AM, Ryosuke Niwa wrote: >> On Apr 30, 2013, at 12:07 PM, Daniel Freedman wrote: >> >>> I'm concerned that if the spec shipped as you described, that it would not >>> be useful enough to developers to bother u

Re: [Shadow DOM] Simplifying level 1 of Shadow DOM

My proposal is to allow for multiple insertion points, and use selectors to filter the insertion points. However restrict the set of selectors such that only an elements intrinsic state affects which insertion point it is inserted in. I.e. only an elements name, attributes and possibly a few state

Re: Fixing appcache: a proposal to get us started

On Mon, Apr 8, 2013 at 12:17 AM, Mark Nottingham wrote: > Hi Jonas, > > I don't get a good sense from this proposal (and NavigationController) about > what the scope of an application is. E.g., if both > http://example.com/fooApp > and > http://example.com/barApp > say that they both grab the

Re: Fixing appcache: a proposal to get us started

On Wed, Apr 3, 2013 at 5:50 AM, Robin Berjon wrote: > On 29/03/2013 21:08 , Jonas Sicking wrote: >> >> * Cache both files (poor bandwidth) >> * We could enable some way of flagging which context different URLs >> are expected to be used in. That way the UA can

Re: Fixing appcache: a proposal to get us started

On Mon, Apr 1, 2013 at 4:03 AM, Glenn Jones wrote: > I think this outline for improving AppCache is a really good start, but I > can see one major problem with it. As you point out AppCache was initially > designed for building simple single page web apps. > > >> The appcache appears to be aimed a

Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)

On Apr 18, 2013 6:19 PM, "Paul Bakaus" wrote: > > Hi Jonas, > > Thanks for this ­ I feel this is heading somewhere, finally! I still need > to work on submitting my full feedback, but I'd like to mention this: Why > did nobody so far in this thread include real world use cases? > > For a highly co

Re: InedxedDB events : misconception?

On Mon, Apr 22, 2013 at 9:56 AM, Michaël Rouges wrote: > > Hum ... thank you for this answer, but ... > > Are you sure there is no possibility that the application is completed > before adding events? > > I find it hard to perceive how it couldn't happen. Do you also worry that if you wrote: x =

Re: File API: auto-revoking blob URLs

On Wed, Apr 17, 2013 at 11:58 AM, Anne van Kesteren wrote: > On Mon, Apr 15, 2013 at 7:49 PM, Anne van Kesteren wrote: >> So blob URLs are auto-revoked by default ... > > In https://www.w3.org/Bugs/Public/show_bug.cgi?id=19594 roc suggests > the default cannot be changed from no auto-revoking to

Re: Futures and transactions

On Mon, Apr 15, 2013 at 12:50 PM, Anne van Kesteren wrote: > On Mon, Apr 15, 2013 at 2:07 AM, Jonas Sicking wrote: >> So I guess the current solution is fine as longs as either >> * No JS libraries will want to implement APIs that uses locks, or >> * Such libraries are

Re: Futures and transactions

The issue isn't actually with Futures and transactions, but rather between Futures and *locks*. Any time you have a set of values protected by a lock, reading and writing those values while holding the lock raises a set of tricky issues. For example if you allow someone to hold a lock while at the

Re: Screen Orientation API: Feedback

On Sun, Apr 7, 2013 at 10:44 AM, Lars Knudsen wrote: > Hi, > > Having some background in both webapps and actual browser development > (webkit, Nokia N9), I see a few issues with the current proposal (some > already mentioned in the mozilla thread about this last year). > > 1. whatever terminology

Re: [dom-futures] Making ProgressFuture use real events

On Wed, Apr 3, 2013 at 10:43 AM, Tab Atkins Jr. wrote: > The ProgressFuture strawman at > > augments a future with an analog of progress events. > > Why isn't this just using actual events? That is, make ProgressFuture > an

Re: File API: why is there same-origin restriction on blob URLs?

On Mar 29, 2013 4:09 PM, "Glenn Maynard" wrote: > > On Fri, Mar 29, 2013 at 10:17 AM, Jonas Sicking wrote: >> >> What I'm saying if that different browsers behave differently here. >> >> Requiring the crossorigin attribute might be your opinion on

Re: Fixing appcache: a proposal to get us started

On Tue, Mar 26, 2013 at 10:03 PM, Emerson Estrella wrote: > I'm writing a web application that uses the AppCache API for offline > browsing. But I'm also using the Audio API to play back-ground music and a > few audio effects. > > > For audio support in different browsers I'm delivering each sound

Re: Fixing appcache: a proposal to get us started

On Tue, Mar 26, 2013 at 7:40 PM, Alec Flett wrote: > >> This is a tricky problem indeed. >> >> The current appcache actually has the behavior that you're advocating, >> but that's something that a lot of developers has complained about. In >> fact, that's the second biggest complaint that I've hea

Re: File API: why is there same-origin restriction on blob URLs?

On Mar 28, 2013 7:36 AM, "Glenn Maynard" wrote: > > On Wed, Mar 27, 2013 at 1:35 PM, Jonas Sicking wrote: >> >> Same question applies if you create an and then >> drawImage it into a canvas, does the canvas get tainted? Again, I >> think different bro

Re: File API: why is there same-origin restriction on blob URLs?

On Tue, Mar 26, 2013 at 5:30 PM, Jonas Sicking wrote: > However we'd still need to nail down what the new behavior should be. > Should it behave like data: URLs? The main advantage of those is that > implementations still don't agree on how those should behave. I meant to say

Re: File API: why is there same-origin restriction on blob URLs?

On Wed, Mar 27, 2013 at 2:41 AM, Anne van Kesteren wrote: >> However we'd still need to nail down what the new behavior should be. >> Should it behave like data: URLs? The main advantage of those is that >> implementations still don't agree on how those should behave. > > I'm not sure what that me

Re: Fixing appcache: a proposal to get us started

background for the next iteration. > On Tue, Mar 26, 2013 at 3:02 AM, Jonas Sicking wrote: >> >> (snip) >> >> >> First we need a way to get at AppCache objects: > > > No mention of installAppCache, removeAppCache or getAppCacheList anywhere > else in t

Re: File API: why is there same-origin restriction on blob URLs?

On Tue, Mar 26, 2013 at 2:17 PM, Anne van Kesteren wrote: > Hi, > > Is there any particular reason why we restrict blob URLs to the same > origin as the script that created them? In effect they are pretty much > like capability URLs (containing an unguessable token). So if someone > decides to sha

Re: Fixing appcache: a proposal to get us started

On Tue, Mar 26, 2013 at 1:48 AM, James Graham wrote: > On 03/26/2013 08:02 AM, Jonas Sicking wrote: > >> Another "feature" that we are proposing is to drop the current >> manifest format and instead use a JSON based one. The most simple >> reason for this is th

Re: Fixing appcache: a proposal to get us started

On Tue, Mar 26, 2013 at 3:21 AM, Jake Archibald wrote: > On 26 March 2013 07:02, Jonas Sicking wrote: >> >> { >> "expiration": 300, >> "cache": ["index.html", "index.js", "index.css"] >> } >> >>

Fixing appcache: a proposal to get us started

Hi WebApps! Apologies in advance for a long email. This is a complex subject and I wanted to present a coherent proposal. Please don't be shy about starting separate threads when providing feedback. There has been a lot of debating about "fixing appcache". Last year mozilla got a few people toget

Re: IndexedDB, what were the issues? How do we stop it from happening again?

ead. > On Tue, Mar 19, 2013 at 1:52 PM, Jonas Sicking wrote: >> >> >> var a; >> trans = db.transaction(); >> trans.get("a").onsuccess = function(e) { >> a = e.target.result; >> } >> trans.get("b").onsuccess = function(e) { &g

Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Tue, Mar 19, 2013 at 2:25 PM, Robert Ginda wrote: > One option that will probably never happen: Stop making jank-inducing API's > available on the main thread. I think we're already doing this. As far as I know all browser vendors are on board with the idea of not having APIs which run on the

Re: [webcomponents]: Re-imagining shadow root as Element

On Tue, Mar 19, 2013 at 12:05 AM, Roland Steiner wrote: > AFAICT this has several ramifications: > > .) Being an element, you now have a render box for each , in > addition to the render box for the host element. That's not a requirement. We can define that the element doesn't show up in the fla

Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Mon, Mar 18, 2013 at 5:42 PM, Alec Flett wrote: >> transactions - Also should be optional. Vital to complex apps, but totally >> >> > not necessary for many.. there should be a default transaction, like >> > db.objectStore("foo").get("bar") >> >> I disagree. This would have made it too trivial

Re: [IndexedDB] Closing connection in a versionchange transaction

On Fri, Nov 30, 2012 at 3:26 PM, Joshua Bell wrote: > A spec oddity that we noticed - if you explicitly close a connection during > an upgradeneeded handler (or elsewhere in the transaction), the transaction > should complete (not abort) yet the connection fails (error), upgrading the > database b

Re: [IndexedDB] Attributes with undefined vs. null

On Wed, Nov 7, 2012 at 10:53 AM, Joshua Bell wrote: > Various atttributes in IndexedDB signal "no value" with |undefined|: > > IDBKeyRange.lowerBound (if not set) > IDBKeyRange.upperBound (if not set) > IDBRequest.result (on error, or on successful deleteDatabase/get with no > value/delete/clear)

Re: [IndexedDB] better way of deleting records

On Tue, Jan 15, 2013 at 7:19 PM, Kyaw Tun wrote: > From developer point of view, IDBObjectStore.delete method cannot be used > directly in most use case, since IDBObjectStore.delete returns undefined. > IDBObjectStore.delete(random_key) always receives onsuccess event, but > nothing happen. Curren

Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Wed, Mar 6, 2013 at 10:14 AM, Alec Flett wrote: > My primary takeaway from both working on IDB and working with IDB for some > demo apps is that IDB has just the right amount of complexity for really > large, robust database use.. but for a "welcome to noSQL in the browser" it > is way too comp

Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Wed, Mar 6, 2013 at 6:01 AM, Alex Russell wrote: > I've avoided weighing in on this thread until I had more IDB experience. > I've been wrestling with it on two fronts of late: > > A re-interpretation of the API based on Futures: > https://github.com/slightlyoff/DOMFuture/tree/master/reworked_A

Re: Streams and Blobs

On Fri, Mar 15, 2013 at 2:36 PM, Glenn Maynard wrote: >> I guess we could always make the Stream object immediately produce an >> error if .responseType is changed to something other than "stream". > > Specifically, I'd recommend that when readyState isn't UNSENT, setting > responseType to "stream

Re: Streams and Blobs

On Mar 15, 2013 5:33 AM, "Anne van Kesteren" wrote: > > On Fri, Mar 15, 2013 at 10:07 AM, Jonas Sicking wrote: > > For a sync XHR in Workers, if .responseType is set to "stream" when > > XHR.send() is called, we block until the HEADERS_RECEIVED state is >

Re: Streams and Blobs

After pondering this over for a few days, here's what I propose. For an async XHR, if .responseType is set to "stream", then when we reach the HEADERS_RECEIVED state .response is set to a Stream object. (See more about this below) As data is being downloaded, we add the data to the end of the Str

Re: [webcomponents]: What callbacks do custom elements need?

On Mon, Mar 11, 2013 at 5:45 PM, Boris Zbarsky wrote: > On 3/11/13 5:18 PM, Elliott Sprehn wrote: >> >> "inserted" and "removed" can probably be end of micro task, but >> attributeChanged definitely needs to be synchronous to model the >> behavior of where changing it from X to Y has an immediate

Re: Streams and Blobs

On Sat, Mar 9, 2013 at 8:03 AM, Glenn Maynard wrote: > On Fri, Mar 8, 2013 at 10:40 PM, Jonas Sicking wrote: >> > - You could set up an async XHR in one worker, then read it >> > synchronously >> > with XHR in another worker. This means the first worker could b

Re: Streams and Blobs

On Fri, Mar 8, 2013 at 7:52 AM, Glenn Maynard wrote: > On Thu, Mar 7, 2013 at 9:40 PM, Jonas Sicking wrote: >> >> On Thu, Mar 7, 2013 at 4:42 PM, Glenn Maynard wrote: >> > The alternative argument is that XHR should represent the data source, >> > reading data f

Re: Persistent Storage vs. Database

On Fri, Mar 8, 2013 at 2:27 PM, Andrew Fedoniouk wrote: > On Fri, Mar 8, 2013 at 11:30 AM, Kyle Huey wrote: >> On Fri, Mar 8, 2013 at 11:02 AM, Andrew Fedoniouk >> wrote: >>> >>> On Thu, Mar 7, 2013 at 10:36 PM, Kyle Huey wrote: >>> > On Thu, Mar 7, 2013 at 10:20 PM, Andrew Fedoniouk >>> > wro

The .shadowRoot property and WebComponents

Related to the ongoing discussion about whether to expose the shadow tree of web components by default or not, but somewhat orthogonal to it, I think there is a question of *how* to expose the web component shadow tree. If I understand things correct, the .shadowRoot property and the createShadowR

Re: [webcomponents]: Custom element constructors are pinocchios

It seems to me like you might be trying to solve a set of contradictory requirements: 1. We want to enable implementing existing "complex" elements using WebComponents 2. Running scripts in the middle of parsing is unsafe. 3. Exiting parsing for any "complex" element is slow. 4. We don't want to b

Re: [webcomponents]: What callbacks do custom elements need?

On Mar 6, 2013 2:07 PM, "Dimitri Glazkov" wrote: > > Here are all the callbacks that we could think of: > > * readyCallback (artist formerly known as "create") -- called when the > element is instantiated with generated constructor, createElement/NS > or shortly after it was instantiated and place

Re: The need to re-subscribe to requestAnimationFrame

On Mar 2, 2013 6:32 AM, "Florian Bösch" wrote: > > You can also wrap your own requestAnimationFrameInterval like so: > > var requestAnimationFrameInterval = function(callback){ > var runner = function(){ > callback(); > requestAnimationFrame(runner); > }; > runner(); > } > > This wil

Re: Streams and Blobs

On Thu, Mar 7, 2013 at 4:42 PM, Glenn Maynard wrote: > The alternative argument is that XHR should represent the data source, > reading data from the network and pushing it to Stream. I think this is the approach I'd take. At least in Gecko this would allow the XHR code to generally do the same t

Re: Streams and Blobs

On Tue, Feb 26, 2013 at 2:56 AM, Anne van Kesteren wrote: > So currently Mozilla has these extensions to XMLHttpRequest: > > * moz-blob > * moz-chunked-text > * moz-chunked-arraybuffer > > The first offers incremental read. The latter two offer chunked read > (data can be discarded as soon as i

Re: [webcomponents]: Building HTML elements with custom elements

On Feb 19, 2013 3:54 PM, "Dimitri Glazkov" wrote: > 2) Custom element constructor runs at the time of parsing HTML, as the > tree is constructed. > > PROBLEM: Several implementers let me know that allowing to run JS > while parsing HTML is not something they can accommodate in a > reasonable timef

Re: [webcomponents] Making the shadow root an Element

On Tue, Feb 19, 2013 at 12:24 PM, Rafael Weinstein wrote: > On Mon, Feb 18, 2013 at 12:06 PM, Jonas Sicking wrote: >> >> On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren >> wrote: >> > On Sat, Feb 16, 2013 at 5:23 PM, Dimitri Glazkov >> > wrote: >&g

Re: [webcomponents] Making the shadow root an Element

On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren wrote: > On Sat, Feb 16, 2013 at 5:23 PM, Dimitri Glazkov wrote: >> We were thinking of adding innerHTML to DocumentFragments anyway... right, >> Anne? > > Well I thought so, but that plan didn't work out at the end of the day. > > https://www.w

Re: [webcomponents] Making the shadow root an Element

On Sat, Feb 16, 2013 at 9:23 AM, Dimitri Glazkov wrote: > Thank you for enumerating the list, Jonas! > > On Thu, Feb 14, 2013 at 11:12 PM, Jonas Sicking wrote: > >> >> I chatted with Blake about this today and had some thoughts. >> >> There is definitely no

Re: [webcomponents] Making the shadow root an Element

On Mon, Feb 11, 2013 at 3:49 PM, Tab Atkins Jr. wrote: > Right now, the shadow root inside a component isn't an element, so it > can't host styles, etc. This makes a few things weird, though. > > For example, it means that it's non-trivial to get at the style of > text nodes directly inside the s

Re: File API for Review

On Feb 6, 2013 8:59 PM, "Arun Ranganathan" wrote: > > Greetings WebApps WG! > > Review on the File API is encouraged: > > http://dev.w3.org/2006/webapi/FileAPI/ > > A few substantial changes that might need particular attention before we initiate a call for LCWD or something comparably official: >

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

On Fri, Jan 18, 2013 at 2:35 AM, Anne van Kesteren wrote: > On Fri, Jan 18, 2013 at 4:34 AM, Jonas Sicking wrote: >> On Thu, Jan 10, 2013 at 1:28 PM, Anne van Kesteren wrote: >>> I think HTML should maintain the registry and policy for on* >>> attributes insofar t

Re: [File API] About Partial Blob Data

On Thu, Jan 17, 2013 at 1:56 AM, Cyril Concolato wrote: > Hi all, > > Reading the File API, it is not clear to me what the behavior is when > reading partial Blob data. The spec says: > " Partial Blob data is the part of the File or Blob that has been read into > memory currently; > when processin

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

On Thu, Jan 10, 2013 at 1:28 PM, Anne van Kesteren wrote: > On Thu, Jan 10, 2013 at 7:19 PM, Vincent Scheib wrote: >> Pending agreement to add properties to the fullscreen specification, I agree >> this should be included in the specification. > > I think HTML should maintain the registry and pol

Re: File Save As

On Sat, Jan 5, 2013 at 11:22 PM, Florian Bösch wrote: > On Sun, Jan 6, 2013 at 1:33 AM, Boris Zbarsky wrote: >> >> This, I agree is a problem. > > The semantic used by countless applications and which is an extremely well > established UX pattern is: > > - First "Save" -> Open Save As dialog > -

Re: File Save As

I think what we need here is the concept of "open for editing". I.e. allow a page to open a file not just for reading (like ), but also for writing. I think there are three questions here: 1. What should the API look like for triggering the "open for editing" action. E.g. is it some sort of exten

Re: Review of the spec

On Fri, Dec 14, 2012 at 1:32 AM, Simon Pieters wrote: > On Fri, 14 Dec 2012 00:04:20 +0100, Jonas Sicking wrote: > >> On Tue, Dec 11, 2012 at 5:00 AM, Henri Sivonen wrote: >>>> >>>> 1. If DOCUMENT does not have a browsing context, Let TEMPLATE CONTENTS &g

Re: Review of the spec

On Tue, Dec 11, 2012 at 5:00 AM, Henri Sivonen wrote: >> 1. If DOCUMENT does not have a browsing context, Let TEMPLATE CONTENTS OWNER >> be DOCUMENT and abort these steps. >> 2. Otherwise, Let TEMPLATE CONTENTS OWNER be a new Document node that does >> not have a browsing context. > > Is there a

Re: CfC: publish WD of XHR; deadline November 29

On Sun, Nov 25, 2012 at 12:38 PM, Ian Hickson wrote: > On Sun, 25 Nov 2012, David Bruant wrote: >> >> The intent is clear: the WHATWG publishes documents in the public domain >> for very good reason. Anyone (W3C included!) can reuse them under close >> to no condition, not even credit. > > I can s

Re: CfC: publish Candidate Recommendation of Widget Updates; deadline May 2

I don't object to this, but I note that mozilla currently has no plans to implement this specification. Including in environments where we have apps that need updating. Instead we are planning on sending a proposal to the SysApps WG for an app runtime which will have support for application updati

Re: [screen-orient] Updated editor draft

On Mon, Nov 5, 2012 at 9:19 AM, Lars Knudsen wrote: > Why not use the existing definitions in the orientation change event? > > http://developer.apple.com/library/ios/#documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html#//apple_ref/doc/uid/TP40006511-SW16

Re: [webcomponents] More backward-compatible templates

On Thu, Nov 1, 2012 at 3:14 PM, Adam Barth wrote: > > > > On Thu, Nov 1, 2012 at 6:33 AM, Maciej Stachowiak wrote: >> >> >> On Nov 1, 2012, at 1:57 PM, Adam Barth wrote: >> >>> >> >>> (5) The nested template fragment parser operates like the template >>> fragment parser, but with the following a

Re: [IDB] Lifetime of IDB objects

On Sun, Oct 21, 2012 at 5:01 PM, João Eiras wrote: > > Hi ! > > The specification does not specify in detail what happens to several of the > object types once they have reached their purpose. > > For instance, IDBTransaction's abort and objectStore methods dispatch > InvalidStateError. > > Howeve

Re: Scheduling multiple types of end-of-(micro)task work

On Thu, Oct 18, 2012 at 3:34 PM, James Robinson wrote: > On Thu, Oct 18, 2012 at 3:19 PM, Alan Stearns wrote: >> On 10/18/12 2:51 PM, "Olli Pettay" wrote: >> >On 10/19/2012 12:08 AM, Rafael Weinstein wrote: >> >> CSS Regions regionLayoutUpdate brings up an issue I think we need to >> >> get ahea

Re: Scheduling multiple types of end-of-(micro)task work

On Thu, Oct 18, 2012 at 2:08 PM, Rafael Weinstein wrote: > CSS Regions regionLayoutUpdate brings up an issue I think we need to > get ahead of: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=16391 > > For context: > > Mutation Observers are currently spec'd in DOM4 > > http://do

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Tue, Oct 16, 2012 at 4:48 PM, Carr, Wayne wrote: >> Chrome supports Fullscreen with keyboard enabled. We use a notification >> that persists until a user notices and >> dismisses it. We may modify it in the future to make this more noticeable, >> e.g. dimming page contents similar to FireFox. >

Re: IndexedDB: undefined parameters

On Oct 11, 2012 5:51 PM, "Boris Zbarsky" wrote: > > On 10/11/12 8:43 PM, Jonas Sicking wrote: >> >> Even for an API like: >> >> void bar(optional int x); >> void bar(MyInterface? x); >> >> with or without the "treat undefined as not-p

Re: IndexedDB: undefined parameters

On Thu, Oct 11, 2012 at 12:15 PM, Boris Zbarsky wrote: > On 10/11/12 3:06 PM, Jonas Sicking wrote: >> >> Make the overload resolution treat a passed 'undefined' value the same >> as not passing the argument. > > > That's not sufficient to just say; we

Re: IndexedDB: undefined parameters

On Wed, Oct 10, 2012 at 10:57 PM, Boris Zbarsky wrote: >>> (As a side note, the IDL for openCursor is not valid WebIDL, because >>> "any?" >>> is not a valid WebIDL type.) >> >> >> That sounds like a WebIDL bug. > > It's a bug in the IDL for openCursor, since "any" already allows null as a > value

Re: IndexedDB: undefined parameters

On Thu, Oct 11, 2012 at 9:36 AM, Allen Wirfs-Brock wrote: > > On Oct 10, 2012, at 10:57 PM, Jonas Sicking wrote: > >> On Wed, Oct 10, 2012 at 7:15 PM, Brendan Eich wrote: >>> Boris Zbarsky wrote: >>>> >>>> Should "undefined", when pro

Re: IndexedDB: undefined parameters

On Wed, Oct 10, 2012 at 7:15 PM, Brendan Eich wrote: > Boris Zbarsky wrote: >> >> Should "undefined", when provided for a dictionary entry, also be treated >> as "not present"? That is, should passing a dictionary like so: >> >> { a: undefined } >> >> be equivalent to passing a dictionary that

Re: IndexedDB: undefined parameters

On Wed, Oct 10, 2012 at 7:03 PM, Boris Zbarsky wrote: > On 10/10/12 9:55 PM, Brendan Eich wrote: >> >> undefined is the one value that acts as the default-triggering sentinel, > > > ... > > >>> Think about all this from the point of view of an ES impl of foo() >>> above. How would you represent,

Re: IndexedDB: undefined parameters

On Wed, Oct 10, 2012 at 6:12 PM, Boris Zbarsky wrote: > On 10/10/12 6:51 PM, Jonas Sicking wrote: >> >> FWIW, ES6 is going to treat the undefined value as "not passing a >> parameter" when it comes to functions that have default values. > > > When there

Re: IndexedDB: undefined parameters

On Wed, Oct 10, 2012 at 4:10 PM, Joshua Bell wrote: > On Wed, Oct 10, 2012 at 3:58 PM, Jonas Sicking wrote: >> >> On Wed, Oct 10, 2012 at 11:15 AM, Odin Hørthe Omdal >> wrote: >> > Last time I looked at it, WebIDL said [TreatUndefinedAs=Missing] is >> >

Re: IndexedDB: undefined parameters

On Wed, Oct 10, 2012 at 11:15 AM, Odin Hørthe Omdal wrote: > Last time I looked at it, WebIDL said [TreatUndefinedAs=Missing] is meant to > be for legacy API's, and not new ones. I think that a bit strange and > counter productive. Why? [TreatUndefinedAs] is only intended for arguments that take

Re: IndexedDB: undefined parameters

On Tue, Oct 9, 2012 at 3:04 PM, Robert Ginda wrote: > On Tue, Oct 9, 2012 at 2:51 PM, Alec Flett wrote: >> >> >> >> On Tue, Oct 9, 2012 at 11:37 AM, Alec Flett >> wrote: >>> >>> >>> >>> On Tue, Oct 9, 2012 at 11:12 AM, Boris Zbarsky wrote: On 10/9/12 1:52 PM, Joshua Bell wrote: >

Re: CfC: publish FPWD of Push API; deadline October 12

Hi All, As usual, this is not the official mozilla position, as there is no such thing. Several of us at at mozilla has been looking at push quite a bit lately. We still don't have a clear idea of exactly what we think a push system should look like. However we are concerned that a system like th

Re: [IndexedDB] Implementation Discrepancies on 'prevunique' and 'nextunique' on index cursor

On Wed, Oct 3, 2012 at 9:48 AM, Joshua Bell wrote: > On Wed, Oct 3, 2012 at 1:13 AM, Odin Hørthe Omdal wrote: >> >> So, at work and with the spec in front of me :-) >> >> >> Odin claimed: >> >>> There is a note near the algorithm saying something to that point, but >>> the definite text is up in

Re: [IndexedDB] blocked event could be an error

On Mon, Oct 1, 2012 at 11:25 AM, David Grogan wrote: > > > On Thu, Sep 27, 2012 at 9:31 AM, Jonas Sicking wrote: >> >> On Thu, Sep 27, 2012 at 6:47 AM, João Eiras wrote: >> > >> >>> http://odinho.html5.org/IndexedDB/spec/Overview.html >>

Re: [XHR] chunked

On Thu, Sep 27, 2012 at 9:26 AM, Anne van Kesteren wrote: > On Thu, Sep 27, 2012 at 6:23 PM, Jonas Sicking wrote: >> I do somewhat agree that if we had a full "stream" solution in the >> form of a Stream primitive and .responseType="stream", then a better

Re: [IndexedDB] blocked event could be an error

On Thu, Sep 27, 2012 at 6:47 AM, João Eiras wrote: > >>> http://odinho.html5.org/IndexedDB/spec/Overview.html >> >> >> Like I said, I think it's too late to make such a big change. I >> believe it's much too late to make such a change in IE10, and we have >> been shipping Firefox with the cu

Re: [XHR] chunked

On Thu, Sep 27, 2012 at 6:27 AM, Anne van Kesteren wrote: > On Thu, Jun 7, 2012 at 11:48 AM, Wenbo Zhu wrote: >> On Thu, Jun 7, 2012 at 2:34 AM, Anne van Kesteren wrote: >>> Can I take this as Chrome being interested in implementing the chunked >>> proposal as well? >> >> Will have to get back t

<    1   2   3   4   5   6   7   8   9   10   >