[whatwg] Gapless playback problems with web audio standards

Hi, http://w3.org/mid/10b10a1d-8b84-4015-8d49-a45b87e4b...@dpk.io dpk

Re: [whatwg] Gapless playback problems with web audio standards

On 27 Oct 2014, at 12:08, Robert O'Callahan rob...@ocallahan.org wrote: Web Audio should be usable for this. If it doesn't work due to brower bugs, we should fix the browser bugs. I know we've fixed bugs related to this in Firefox this year so I'd like to know if obvious techniques still

[whatwg] Proposal: element

I would like to propose a new element for the HTML standard, . The element is a phrasing element representing a label or tag. Semantically, it attaches the label to the nearest enclosing , , , , , or to the entire document if there is no such enclosing element. Example uses for the proposed

[whatwg] Accessing local files with JavaScript portably and securely

Moin, Over the last few years there has been a gradual downgrading of support in browsers for running pages from the file: protocol. Most browsers now have restrictions on the ability of JavaScript in such pages to access other files. Both Firefox and Chrome seem to have removed this support

Re: [whatwg] Accessing local files with JavaScript portably and securely

On 9 Apr 2017, at 20:36, Jan Tosovsky <jan.tosovsky...@gmail.com> wrote: > On 2017-04-09 David Kendal wrote: > > > ... there are many possible uses for local static files accessing > > other local static files: the one I have in mind is shipping static > >

Re: [whatwg] Accessing local files with JavaScript portably and securely

On 9 Apr 2017, at 14:48, Philipp Serafin wrote: > Note also that the HTTP server solution requires you to ship a binary > (the server) with your files, therefore sacrificing platform > independence and requiring the user to run an untrusted binary, all > just to show some HTML

Re: [whatwg] Accessing local files with JavaScript portably and securely

On 11 Apr 2017, at 12:55, Patrick Dark wrote: > I can't see this being addressed. The only good reason to distribute > an application this way is because you want it to be confidential and > there's no incentive to accommodate what one might call "walled

Re: [whatwg] Accessing local files with JavaScript portably and securely

On 11 Apr 2017, at 17:01, Domenic Denicola wrote: > Bingo. This mailing list is for developing technology for the world > wide web, not for peoples' local computers. The World Wide Web includes peoples' own computers. file:// is a URI scheme for exactly that reason. Every

Re: [whatwg] Accessing local files with JavaScript portably and securely

On 15 Apr 2017, at 01:09, Patrick Dark wrote: > So if you put this file in the Windows Downloads directory, then it > has read access to all download files even though they aren't related? > And it grants access to all of those files—some of which may

Re: [whatwg] Accessing local files with JavaScript portably and securely

On 15 Apr 2017, at 14:07, Roger Hågensen wrote: > Patrick makes a good point. > > For example asking a user if it' sok for the HTML document to access > stuff in "C:\Users\Username\AppData\Local\Temp\" what do you think most > uses will do? > Just click OK, after all

Re: [whatwg] Accessing local files with JavaScript portably and securely

On 14 Apr 2017, at 18:30, Domenic Denicola wrote: > > You are continuing to dodge this problem by redefining the WHAT WG's > > responsibilities. Please don't do that. > > I don't intend to take direction on how I spend my time from you. Fine; you don't personally have to work

Re: [whatwg] Accessing local files with JavaScript portably and securely

To set aside the previous thread, I'd like to make a renewed call for input on my actual proposal, including counter-proposals, potential flaws in my design, etc. Then perhaps we can make some progress here. dpk On 9 Apr 2017, at 10:51, David Kendal <m...@dpk.io> wrote: > Moin,

Re: [whatwg] Accessing local files with JavaScript portably and securely

On 11 Apr 2017, at 19:50, Patrick Dark wrote: > The "world wide web" is the user-facing portion of the Internet. Files > on a CD or USB drive are not part of that. You are continuing to dodge this problem by redefining the WHAT WG's responsibilities.