Leaving Mozilla

Hi All, A little over a month ago I got married. My wife and I are planning on doing an extended honeymoon, starting now and ending sometime early next year. I'm not certain where we'll end up after the honeymoon, or what either of us will work with. Because of this, my last day at Mozilla was We

Re: [XHR]

On Wed, Mar 16, 2016 at 10:29 AM, Tab Atkins Jr. wrote: > No, streams do not solve the problem of "how do you present a > partially-downloaded JSON object". They handle chunked data *better*, > so they'll improve "text" response handling, Also binary handling should be improved with streams. >

Re: [XHR]

On Wed, Mar 16, 2016 at 1:54 PM, Gomer Thomas wrote: > but I need a cross-browser solution in the near future Another solution that I think would work cross-browser is to use "text/plain;charset=ISO-8859-15" as content-type. That way I *think* you can simply read xhr.responseText to get an ever

Re: [XHR]

Sounds like you want access to partial binary data. There's some propitiatory features in Firefox which lets you do this (added ages ago). See [1]. However for a cross-platform solution we're still waiting for streams to be available. Hopefully that should be soon, but of course cross-browser sup

Re: File API - where are the missing parts?

On Tue, Feb 23, 2016 at 10:06 AM, Joshua Bell wrote: > I'm also very interested in hearing from other browser implementers; Chrome > is in the odd position of having made investments in related areas > (FileSystem API and FileWriter API) that did not see adoption in other > browsers, which is a di

Re: File API - where are the missing parts?

On Tue, Feb 23, 2016 at 7:12 AM, Florian Bösch wrote: > On Tue, Feb 23, 2016 at 2:48 AM, Jonas Sicking wrote: >> >> Is the last bullet here really accurate? How can you use existing APIs to >> listen to file modifications? > > I have not tested this on all UAs, but in

Re: File API - where are the missing parts?

On Sun, Feb 21, 2016 at 3:32 AM, Florian Bösch wrote: > > *What this covers* > >- Read one or many files in their entirety in one go (in python that >would be open('foobar').read()) >- Save a completed binary string in its entirety in one go to the >download folder (no overwrite)

Re: Art steps down - thank you for everything

On Thu, Jan 28, 2016 at 7:45 AM, Chaals McCathie Nevile wrote: > Thanks Art for everything you've done for the group for so long. Hi Art, Yes, thank you very much for chairing the WG for so long. This group has under your chairing been one of the W3C WGs that has moved the web forward the most.

Re: [Editing] [DOM] Adding static range API

On Sat, Jan 9, 2016 at 6:55 PM, Ryosuke Niwa wrote: > >> On Jan 9, 2016, at 6:25 PM, Olli Pettay wrote: >> >> Hard to judge this proposal before seeing an API using StaticRange objects. >> >> One thing though, if apps were to create an undo stack of their own, they >> could easily have their own

Re: Callback when an event handler has been added to a custom element

On Fri, Nov 6, 2015 at 12:44 PM, Olli Pettay wrote: > On 11/06/2015 09:28 PM, Justin Fagnani wrote: >> >> You can also override addEventListener/removeEventListener on your >> element. My concern with that, and possibly an event listener change >> callback, is >> that it only works reliably for no

Re: Indexed DB + Promises

On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola wrote: > This seems ... reasonable, and quite possibly the best we can do. It has a > several notable rough edges: > > - The need to remember to use .promise, instead of just having functions > whose return values you can await directly One way

Re: The key custom elements question: custom constructors?

On Thu, Jul 16, 2015 at 12:16 PM, Domenic Denicola wrote: > From: Jonas Sicking [mailto:jo...@sicking.cc] > >> Like Anne says, if it was better defined when the callbacks should happen, >> and that it was defined that they all happen after all internal >> datastructures

Re: The key custom elements question: custom constructors?

On Thu, Jul 16, 2015 at 9:49 AM, Domenic Denicola wrote: > From: Anne van Kesteren [mailto:ann...@annevk.nl] > >> I think the problem is that nobody has yet tried to figure out what >> invariants >> that would break and how we could solve them. I'm not too worried about >> the parser as it alread

Re: [WebIDL] T[] migration

On Thu, Jul 16, 2015 at 8:45 AM, Travis Leithead wrote: > Recommendations: > ·HTML5 > ·Web Messaging > > Other references: > ·CSS OM > ·Web Sockets > ·WebRTC Note that in practice I would think that most implementations return objects which have a .item() f

Re: Cross-page locking mechanism for indexedDB/web storage/FileHandle ?

Yeah, I think a standalone primitive for "asynchronous atomics". The big risk is of course that deadlocks can occur, but there's no real way to completely avoid that while keeping a flexible platform. These deadlocks would be asynchronous, so no thread will hang, but you can easily end up with two

Re: Directory Upload Proposal

On Wed, May 13, 2015 at 11:51 PM, Jonas Sicking wrote: > One important question though is what would directories> do on platforms that don't have a directory UI concept? > Like most mobile platforms? Err.. that should say: What would do on platforms that don't have a d

Re: Directory Upload Proposal

On Wed, May 13, 2015 at 11:39 PM, Jonas Sicking wrote: > >> On that note, there is actually a 5th option that we can entertain. We could >> have three different kinds of file inputs: one type for files, another for >> directories, and yet another for handling both files

Re: Directory Upload Proposal

he file-or-directory picker is available? / Jonas > Thanks, > Ali > > On Friday, May 8, 2015 at 3:29 PM, Jonas Sicking wrote: > >>On Tue, May 5, 2015 at 10:50 AM, Ali Alabbas wrote: >>> I recommend that we change the "dir" attribute to "directories"

Re: Directory Upload Proposal

On Tue, May 5, 2015 at 10:50 AM, Ali Alabbas wrote: > I recommend that we change the "dir" attribute to "directories" and keep > "directory" the same as it is now to avoid clashing with the existing "dir" > attribute on the HTMLInputElement. All in favor? There's no current "directory" attribut

Re: Shadow DOM: state of the distribution API

On Wed, May 6, 2015 at 11:07 AM, Anne van Kesteren wrote: > On Wed, May 6, 2015 at 7:57 PM, Jonas Sicking wrote: >> Has at-end-of-microtask been debated rather than 1/2? Synchronous >> always has the downside that the developer has to deal with >> reentrancy. > &g

Re: Permissions API vs local APIs

On Wed, May 6, 2015 at 9:00 AM, Doug Turner wrote: > The way I would look at this is based on timeframe -- if we're not > implementing the Permissions API until 2017 or something, i'd just leave the > functionality in the PushAPI spec. If the Permission API is right around the > corner, I woul

Re: Shadow DOM: state of the distribution API

On Wed, May 6, 2015 at 2:05 AM, Anne van Kesteren wrote: > > 1) Synchronous, no flattening of . A host element's shadow > tree has a set of slots each exposed as a single element to > the outside. Host elements nested inside that shadow tree can only > reuse slots from the outermost host element.

Re: Permissions API vs local APIs

I think mozilla would be fine with taking the permission API as a dependency and implement that at the same time. Implementing the permission API should be fairly trivial for us. But we should verify this with the people actually working on the push API. / Jonas On Wed, May 6, 2015 at 3:13 AM, M

Re: Permissions API vs local APIs

On Mon, May 4, 2015 at 10:42 PM, Anne van Kesteren wrote: > Over in > https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0006.html > Jonas pointed out that having two APIs for doing the same thing is > "nuts". We should probably decide whether we go ahead with the > Permissions AP

Re: :host pseudo-class

On Sun, Apr 26, 2015 at 8:37 PM, L. David Baron wrote: > On Saturday 2015-04-25 09:32 -0700, Anne van Kesteren wrote: >> I don't understand why :host is a pseudo-class rather than a >> pseudo-element. My mental model of a pseudo-class is that it allows >> you to match an element based on a boolean

Re: Directory Upload Proposal

On Mon, Apr 27, 2015 at 9:45 PM, Jonas Sicking wrote: > On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas wrote: >> Hello WebApps Group, > > Hi Ali, > > Yay! This is great to see a formal proposal for! Definitely something > that mozilla is very interested in working on. >

Re: Directory Upload Proposal

On Tue, Apr 28, 2015 at 4:28 PM, Travis Leithead wrote: >>> Aaron opened an issue for this on GitHub [1] and I agree that it is a >>> problem and we should definitely rename it to something else! One option >>> might be to change dir to directory, but we would need a different name for >>> dire

Re: Directory Upload Proposal

On Tue, Apr 28, 2015 at 4:26 PM, Travis Leithead wrote: >>> Second, rather than adding a .directory attribute, I think that we should >>> simply add any selected directories to the .files list. My experience is >>> that having a direct mapping between what the user does, and what we expose >>>

Re: Directory Upload Proposal

On Thu, Apr 23, 2015 at 5:45 PM, Anne van Kesteren wrote: > On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas wrote: >> If there is sufficient interest, I would like to work on this within the >> scope of the WebApps working group. > > It seems somewhat better to just file a bug against the HTML Sta

Re: Directory Upload Proposal

On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas wrote: > Hello WebApps Group, Hi Ali, Yay! This is great to see a formal proposal for! Definitely something that mozilla is very interested in working on. > If there is sufficient interest, I would like to work on this within the > scope of the Web

Re: Exposing structured clone as an API?

On Thu, Apr 23, 2015 at 6:31 PM, Kyle Huey wrote: > On Thu, Apr 23, 2015 at 6:06 PM, Boris Zbarsky wrote: >> On 4/23/15 6:34 PM, Elliott Sprehn wrote: >>> >>> Have you benchmarked this? I think you're better off just writing your >>> own clone library. >> >> >> That requires having a list of all

Re: Why is querySelector much slower?

On Mon, Apr 27, 2015 at 1:57 AM, Glen Huang wrote: > Intuitively, querySelector('.class') only needs to find the first matching > node, whereas getElementsByClassName('.class')[0] needs to find all matching > nodes and then return the first. The former should be a lot quicker than the > latter. Wh

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

s WG. I'll leave that discussion to others. / Jonas On Wed, Apr 1, 2015 at 8:47 PM, Jonas Sicking wrote: > On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola wrote: >> From: Boris Zbarsky [mailto:bzbar...@mit.edu] >> >>> This particular example sets of alarm bells

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola wrote: > From: Boris Zbarsky [mailto:bzbar...@mit.edu] > >> This particular example sets of alarm bells for me because of virtual >> hosting. > > Eek! Yeah, OK, I think it's best I refrain from trying to come up with > specific examples. Let's for

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

On Wed, Apr 1, 2015 at 6:37 PM, Florian Bösch wrote: > On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking wrote: >> >> Not saying that we can use CORS to solve this, or that we should >> extend CORS to solve this. My point is that CORS works because it was >> specified and

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

On Wed, Apr 1, 2015 at 4:30 PM, Anne van Kesteren wrote: > On Wed, Apr 1, 2015 at 4:27 PM, Domenic Denicola wrote: >> I think it's OK for different browsers to experiment with different >> non-interoperable conditions under which they fulfill or reject the >> permissions promise. That's already

Re: File Save As

On Sun, Mar 29, 2015 at 1:25 PM, Florian Bösch wrote: > It's been over 2 years since I raised this issue the first time. The > specification has not been http://www.w3.org/TR/file-writer-api/ updated in > a year and it states that: > >> Work on this document has been discontinued and it should not

Re: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

On Sat, Mar 21, 2015 at 5:52 AM, Arthur Barstow wrote: > > 2. ; this test > failure (which passes on IE) is considered an implementation bug > (MessageChannel and MessagePort are supposed to be exposed to Worker) that > is expected to be

Re: template namespace attribute proposal

On Fri, Mar 13, 2015 at 2:15 PM, Tab Atkins Jr. wrote: > On Fri, Mar 13, 2015 at 2:09 PM, Jonas Sicking wrote: >> Unless the SVG WG is willing to drop support for >> <![CDATA[...]]>. But that seems like it'd break a lot >> of content. > > Like, on the sa

Re: template namespace attribute proposal

On Fri, Mar 13, 2015 at 1:57 PM, Tab Atkins Jr. wrote: > On Fri, Mar 13, 2015 at 1:48 PM, Jonas Sicking wrote: >> On Fri, Mar 13, 2015 at 1:16 PM, Tab Atkins Jr. wrote: >>> On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren wrote: >>>> On Thu, Mar 12, 2015 at

Re: template namespace attribute proposal

On Fri, Mar 13, 2015 at 1:16 PM, Tab Atkins Jr. wrote: > On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren wrote: >> On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh wrote: >>> What are your thoughts on this idea? >> >> I think it would be more natural (HTML-parser-wise) if we >> special-cased SV

Re: CORS performance

On Tue, Feb 24, 2015 at 3:25 AM, Anne van Kesteren wrote: >> If that's the case then I think we'd get most of the functionality, >> with essentially none of the risk, by only allowing server-wide >> cookie-less preflights. > > If we only do it for this, could we combine that feature with the > exi

Re: CORS performance

On Mon, Feb 23, 2015 at 11:06 AM, Anne van Kesteren wrote: > On Mon, Feb 23, 2015 at 7:55 PM, Jonas Sicking wrote: >> A lot websites accidentally enabled cross-origin requests with >> cookies. Not realizing that that enabled attackers to make requests >> that had side-ef

Re: CORS performance proposal

On Fri, Feb 20, 2015 at 11:43 PM, Anne van Kesteren wrote: > On Fri, Feb 20, 2015 at 9:38 PM, Jonas Sicking wrote: >> On Fri, Feb 20, 2015 at 1:05 AM, Anne van Kesteren wrote: >>> An alternative is that we attempt to introduce >>> Access-Control-Policy-Path again

Re: CORS performance proposal

On Sat, Feb 21, 2015 at 11:18 PM, Anne van Kesteren wrote: > On Sat, Feb 21, 2015 at 10:17 AM, Martin Thomson > wrote: >> On 21 February 2015 at 20:43, Anne van Kesteren wrote: >>> High-byte of what? A URL is within ASCII range when it reaches the >>> server. This is the first time I hear of thi

Re: CORS performance

On Mon, Feb 23, 2015 at 7:15 AM, Henri Sivonen wrote: > On Tue, Feb 17, 2015 at 9:31 PM, Brad Hill wrote: >> I think it is at least worth discussing the relative merits of using a >> resource published under /.well-known for such use cases, vs. sending >> "pinned" headers with every single resour

Re: CORS performance proposal

On Fri, Feb 20, 2015 at 1:05 AM, Anne van Kesteren wrote: > On Thu, Feb 19, 2015 at 9:22 PM, Jonas Sicking wrote: >> Would this be allowed for both requests with credentials and requests >> without credentials? The security implications of the two are very >> different. &g

Re: CORS performance

On Thu, Feb 19, 2015 at 12:38 PM, Brad Hill wrote: > I think that POSTing JSON would probably expose to CSRF a lot of things that > work over HTTP but don't expect to be interacted with by web browsers in > that manner. That's why the recent JSON encoding for forms mandates that it > be same-orig

Re: CORS performance proposal

Would this be allowed for both requests with credentials and requests without credentials? The security implications of the two are very different. / Jonas On Thu, Feb 19, 2015 at 5:29 AM, Anne van Kesteren wrote: > When the user agent is about to make its first preflight to an origin > (timeout

Re: CORS performance

On Thu, Feb 19, 2015 at 4:49 AM, Dale Harvey wrote: >> so presumably it is OK to set the Content-Type to text/plain > > Thats not ok, but may explain my confusion, is Content-Type considered a > Custom Header that will always trigger a preflight? if so then none of the > caching will apply, CouchD

Re: CORS performance

On Thu, Feb 19, 2015 at 3:30 AM, Anne van Kesteren wrote: > On Thu, Feb 19, 2015 at 12:17 PM, Dale Harvey wrote: >> With Couch / PouchDB we are working with an existing REST API wherein every >> request is to a different url (which is unlikely to change), the performance >> impact is significant

Re: do not deprecate synchronous XMLHttpRequest

On Tue, Feb 10, 2015 at 12:51 PM, Marc Fawzi wrote: > i agree that it's not a democratic process and even though some W3C/TAG > people will engage you every now and then the end result is the browser > vendors and even companies like Akamai have more say than the users and > developers Developers

Re: do not deprecate synchronous XMLHttpRequest

On Tue, Feb 10, 2015 at 12:43 PM, Michaela Merz wrote: > Blobs are immutable but it would be cool to have blob > 'pipes' or FIFOs allowing us to stream from those pipes by feeding them > via AJAX. Since it sounds like you want to help with this, there's good news! There's an API draft available.

Re: oldNode.replaceWith(...collection) edge case

On Jan 27, 2015 4:51 AM, "Anne van Kesteren" wrote: > > On Thu, Jan 22, 2015 at 11:43 AM, Jonas Sicking wrote: > > In general I agree that it feels unintuitive that you can't replace a node > > with a collection which includes the node itself. So the extra line

Re: oldNode.replaceWith(...collection) edge case

On Jan 17, 2015 8:20 PM, "Glen Huang" wrote: > > Oh crap. Just realized saving index won't work if context node's previous siblings are passed as arguments. Looks like inserting transient node is still the best way. The simplest way to write this method would seem to me to be something like: Nod

Re: PSA: Indexed Database API is a W3C Recommendation

\o/ On Thu, Jan 8, 2015 at 12:20 PM, Arthur Barstow wrote: > Congratulations All! This was a job very well done. > > On 1/8/15 2:37 PM, Coralie Mercier wrote: >> >> It is my pleasure to announce that Indexed Database API is published as >> a W3C Recommendation >> http://www.w3.org/TR/2015/REC-Ind

Re: Interoperability vs file: URLs

On Thu, Dec 4, 2014 at 7:50 AM, Sam Ruby wrote: > On 12/02/2014 02:22 AM, Jonas Sicking wrote: >> To be clear, I'm proposing to remove any and all normative definition >> of file:// handling from the spec. Because I don't think there is >> interoperability, nor do

Re: Interoperability vs file: URLs (was: URL Spec WorkMode)

On Mon, Dec 1, 2014 at 7:58 PM, Sam Ruby wrote: > On 12/01/2014 10:22 PM, Jonas Sicking wrote: >> >> On Mon, Dec 1, 2014 at 7:11 PM, Domenic Denicola wrote: >>> >>> What we really need to do is get some popular library or website to take >>> a >>

Re: URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec)

to depend on the behavior of file:// parsing, even if they were to intentionally try. / Jonas > ________ > From: Jonas Sicking > Sent: 2014-12-01 22:07 > To: Sam Ruby > Cc: Webapps WG > Subject: Re: URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL

Re: URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec)

Just in case I haven't formally said this elsewhere: My personal feeling is that it's probably better to stay away from speccing the behavior of file:// URLs. There's very little incentive for browsers to align on how to handle file:// handling. The complexities of different file system behaviors

Re: What I am missing

On Tue, Nov 18, 2014 at 9:38 PM, Florian Bösch wrote: >> or direct file access > > http://www.html5rocks.com/en/tutorials/file/filesystem/ This is no more "direct file access" than IndexedDB is. IndexedDB also allow you to store File objects, but also doesn't allow you to access things like your

Re: What I am missing

On Tue, Nov 18, 2014 at 7:40 PM, Boris Zbarsky wrote: > On 11/18/14, 10:26 PM, Michaela Merz wrote: >> >> First: We need signed script code. > > For what it's worth, Gecko supported this for a while. See > . > In pra

Re: Push API change for permissions UX

On Sat, Oct 25, 2014 at 11:42 PM, Jake Archibald wrote: > This discussion is about how often push may be processed silently (without > showing a notification), not if a push notification may *only* show a > notification. Ok. I think this comes back to the old problem of that different UAs have d

Re: Push API change for permissions UX

On Fri, Oct 24, 2014 at 9:39 AM, Owen Campbell-Moore wrote: >> I think it might make sense to ask for permission to display >> notifications/UI at the same time as you ask for permission to "run in the >> background". > > I hope the above explains why we believe that while some sites may want to >

Re: Push API and Service Workers

On Thu, Oct 23, 2014 at 2:27 PM, Tab Atkins Jr. wrote: > On Tue, Oct 21, 2014 at 7:25 AM, Erik Corry wrote: >> * Push doesn't actually need SW's ability to intercept network >> communications on behalf of a web page. >> * You can imagine a push-handling SW that does all sorts of >> complicated pr

Re: Push API change for permissions UX

Hi John, I think it *might* make sense to ask for permission to display notifications/UI at the same time as you ask for permission to "run in the background". Though someone would definitely need to check with mozilla's security team to see how they feel since I know they've generally wanted to

Re: FileSystem API Comments

David is correct. There certainly are use cases for having Webapps share data. Not just data in filesystem's, but also structured data stored in something like localStorage or IndexedDB. However this filesystem API proposal does not address those use cases. If someone would like to come up with

Re: FileSystem API Comments

On Tue, Oct 21, 2014 at 1:36 PM, Ali Alabbas wrote: > Hello, > > I'm with the IE Platform team at Microsoft. We have a few comments on the > latest editor's draft of the newly proposed FileSystem API [1]. Hi Ali! Thanks for looking at the spec. I'm glad you've been able to understand the API as w

Re: Push API and Service Workers

On Wed, Oct 15, 2014 at 3:07 PM, Shijun Sun wrote: > My understanding here is that we want to leverage the "push client" in the > OS. That will provide new capabilities without dependency on a direct > connection between the app and the app server. Yes, this is how the spec is defined. The spe

Re: Push API and Service Workers

The hard question is: What do you do if there's an incoming push message for a given website, but the user doesn't have the website currently open. Service Workers provide the primitive needed to enable launching a website "in the background" to handle the incoming push message. Another solution

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

On Mon, Oct 6, 2014 at 3:34 PM, wrote: >> That said, it is theoretically possible. But that seems to be true for >> *any* normative change of a spec. > > Right. That's why normative changes require returning to Last Call. :( My understanding is that W3C policy is that LC is only required for lar

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

On Sun, Oct 5, 2014 at 2:28 PM, wrote: > So the question turns on whether the changes would invalidate a patent > review, and my quick guess is that the answer is "yes" ;( Really? I would have made the opposite conclusion. Changing the event source makes a very small difference in behavior. I w

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

On Sun, Oct 5, 2014 at 7:05 AM, Arthur Barstow wrote: > On 10/2/14 2:44 PM, Jonas Sicking wrote: >> >> Though I also agree with Mounir. Changing the event source doesn't >> seem like a change that's substantial enough that we'd need to go back >> to WD/LC

Re: Service worker popup (rich notification)

On Thu, Oct 2, 2014 at 11:31 AM, Anne van Kesteren wrote: > On Thu, Oct 2, 2014 at 8:27 PM, John Mellor wrote: >> This seems to either require a somewhat stronger trust signal from the user, >> or a very easy mechanism for revoking the permission if the website does >> spam you; and probably in e

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

Though I also agree with Mounir. Changing the event source doesn't seem like a change that's substantial enough that we'd need to go back to WD/LCWD. Does any implementation actually feel that it would be? / Jonas On Thu, Oct 2, 2014 at 4:15 AM, Mounir Lamouri wrote: > Can we at least publish a

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

On Fri, Sep 12, 2014 at 8:07 AM, Mounir Lamouri wrote: > On Fri, 12 Sep 2014, at 08:52, Jonas Sicking wrote: >> It's somewhat inconsistent that we use the term "natural" to indicate >> "the most natural direction based on hardware", but we use the ter

Re: [clipboard] Semi-Trusted Events Alternative

On Mon, Sep 15, 2014 at 1:42 PM, Hallvord R. M. Steen wrote: >> 2. Allow reading data from the clipboard at any time if the data there >> originated from the current origin. Thereby making the API as helpful >> as possible for the case when data is copied within a website. > > So, I'm not yet "sol

Re: [clipboard] Semi-Trusted Events Alternative

On Mon, Sep 15, 2014 at 1:42 PM, Hallvord R. M. Steen wrote: > It's an interesting idea that partly fixes the main drawback with the current > proposal: that to read clipboard contents, "paste" must be triggered from the > browser's own UI, not the website's. The current proposal makes it possib

Re: [clipboard] Semi-Trusted Events Alternative

On Sun, Sep 14, 2014 at 5:54 AM, Dale Harvey wrote: > websites can already trivially build editors that use copy and paste within > the site itself, the entire problem is that leads to confusing behaviour > when the user copies and pastes outside the website, which is a huge use > case of the clip

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

On Thu, Sep 11, 2014 at 3:52 PM, Jonas Sicking wrote: > Also, I can't find any normative definition of if orientation.angle > should increase or decrease if the user rotates a device 90 degrees > clockwise? My bad, I see it now. Given how easy this is to get wrong, it might be wor

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

On Thu, Sep 11, 2014 at 2:19 PM, Arthur Barstow wrote: > Mounir and Marcos would like to publish a LCWD of The Screen Orientation API > and this is a Call for Consensus to do using the latest ED (not yet in the > LCWD template) as the basis: > > Sorry

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 2:01 PM, Tab Atkins Jr. wrote: > On Wed, Sep 3, 2014 at 12:45 PM, Glenn Maynard wrote: >> My only issue is the wording: it doesn't make sense to have normative >> language saying "you must not use this feature". This should be a >> non-normative note warning that this shou

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 10:49 AM, Anne van Kesteren wrote: > On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson wrote: >> Hear hear. Indeed, a large part of moving to a "living standard" model is >> all about maintaining the agility to respond to changes to avoid having to >> make this very kind of asser

Re: Proposal for a Permissions API

On Tue, Sep 2, 2014 at 6:51 AM, Mounir Lamouri wrote: > # Straw man proposal # > > This proposal is on purpose minimalistic and only contains features that > should have straight consensus and strong use cases, the linked document > [1] contains ideas of optional additions and list of retired idea

Re: Screen Orientation Feedback

Yup. Well.. sounds like people, including you, pointed out these problems. No idea why it was ignored since I wasn't there. / Jonas On Wed, Aug 13, 2014 at 11:28 PM, Lars Knudsen wrote: > If only someone had pointed out these problems earlier ;) > > On Aug 5, 2014 11:17 PM,

Re: Screen Orientation Feedback

On Wed, Aug 13, 2014 at 1:38 AM, Rich Tibbett wrote: > > Do you have any thoughts on providing screen-adjusted devicemotion > event data also (i.e. acceleration, accelerationIncludingGravity, > rotationRate) It's not something I've thought about, but yeah, it sounds like that would make sense. /

Re: Proposal for a credential management API.

On Tue, Aug 12, 2014 at 9:33 AM, Mike West wrote: >> * Enable a login flow which is less "jarring" UX-wise than today's >> redirects. >> * Don't increase the number of clicks needed to log in. Today two >> clicks are usually enough, we shouldn't be worse than that since then >> websites won't adop

Re: Screen Orientation Feedback

On Tue, Aug 12, 2014 at 5:35 AM, Rich Tibbett wrote: > On Mon, Aug 11, 2014 at 11:33 PM, Jonas Sicking wrote: >> I'm not arguing that we remove the relative angle that's in the spec >> right now. I'm arguing that for device orientation events, we should >>

Re: Proposal for a credential management API.

Hi Mike, I'm very interested in improving the login experience on websites. In particular I'd like to create a better flow when federated logins are used, with at least the following goals: * Make it easier for websites to use federated login as to discourage passwords. * Ensure that the designed

Re: Screen Orientation Feedback

On Fri, Aug 8, 2014 at 6:44 AM, Mounir Lamouri wrote: > Maybe this feedback should be more for DeviceOrientation than Screen > Orientation. There has been a few discussions there > (public-geolocation). This is the type of procedural issues that I'd really rather not get caught in. I think it's f

Screen Orientation Feedback

Hi All, I think the current interaction between the screen orientation and device orientation specs is really unfortunate. Any time that you use the device orientation in order to render something on screen, you have to do non-obvious math in order to get coordinates which are usable. Same thing

Re: [push-api] Moving "PushManager push" onto ServiceWorkerRegistration

On Fri, Jul 11, 2014 at 8:17 AM, Jake Archibald wrote: > navigator.serviceWorker.ready.then(function(reg) { > reg.push.register(...) > }); I agree this looks good. Though maybe reg.registerPush(...) instead? / Jonas

Re: IDBObjectStore/IDBIndex.exists(key)

e that require synchronous IO which is really bad for perf. It's also different from all other database operations. So if that's your request then the answer is definitely no. / Jonas > Sent from my iPhone > >> On Jun 23, 2014, at 1:28 PM, Jonas Sicking wrote: >>

Re: IDBObjectStore/IDBIndex.exists(key)

On Mon, Jun 23, 2014 at 1:03 PM, Marc Fawzi wrote: > Having said that, and speaking naively here, a synchronous .exists() or > .contains() would be useful as "existence" checks shouldn't have to be > exclusively asynchronous as that complicates how we'd write: "if this exists > and that other t

Re: IDBObjectStore/IDBIndex.exists(key)

On Mon, Jun 23, 2014 at 9:59 AM, Joshua Bell wrote: > On Sat, Jun 21, 2014 at 9:45 PM, ben turner wrote: >> >> I think this sounds like a fine idea. >> >> -Ben Turner >> >> >> On Sat, Jun 21, 2014 at 5:39 PM, Jonas Sicking wrote: >>> >

IDBObjectStore/IDBIndex.exists(key)

Hi all, I found an old email with notes about features that we might want to put in v2. Almost all of them was recently brought up in the recent threads about IDBv2. However there was one thing on the list that I haven't seen brought up. It might be a nice perf improvement to add support for a I

Re: Indexed DB Transactions vs. Microtasks

On Thu, Jun 19, 2014 at 8:44 AM, Adam Klein wrote: > While I agree that the original microtask intent would suggest we change > this, and I concur that it seems unlikely to break content, I worry about > the spec and implementation complexity that would be incurred by having to > support the notio

Re: Indexed DB Transactions vs. Microtasks

On Thu, Jun 5, 2014 at 12:59 PM, Joshua Bell wrote: > case 1: > > var tx; > Promise.resolve().then(function() { > tx = db.transaction(storeName); > // tx should be active here... > }).then(function() { > // is tx active here? > }); > > For case 1, ISTM that "yes" matches the ID

Re: Fetch API

On Fri, Jun 6, 2014 at 12:33 AM, Domenic Denicola wrote: > It seems to me that for both the HeaderMap constructor and any object-literal > processing, the best solution for now is to just do things in prose... I think the first thing we should decide on is what syntax we want JS authors to be ab

Re: Fetch API

On Wed, Jun 4, 2014 at 2:46 AM, Anne van Kesteren wrote: > On Wed, Jun 4, 2014 at 9:49 AM, Jonas Sicking wrote: >> On Wed, Jun 4, 2014 at 12:31 AM, Anne van Kesteren wrote: >>> Does ES define the order of { "x": "a", "y": "b" } btw? &

  1   2   3   4   5   6   7   8   9   10   >