Re: [whatwg] Dirty Property (Was: Markup-related feedback)

2014-10-28 Thread Smylers
Ian Hickson writes:

 On Thu, 10 Jul 2014, Garrett Smith wrote:
  
  1.  Form `dirty` property. Set to false, initially. Set to true when
  the user has interacted with any of the form's controls to make them
  dirty.
 
 What's the use case?

Situations where I could have used something like this:

• A content management system where the user is previewing their content
  and can either publish it as it is or make further changes and preview
  it again. The ‘Publish’ button needs to check that no changes have
  been made (so that all content gets previewed before publishing).

• An application which involves editing records (such as an address
  book), where closing the page without saving should throw warning that
  the changes will be lost, unless there haven't been any changes.

 Can you work around this by just catching 'input' events on the
 form?

Yes.

Though on a form with many fields, a mixture of different types of
controls, it can be tedious to get it right, and I'm not sure if it's
possible to follow the behaviour of some native apps (such as Vim) where
making a change and then pressing ‘undo’ unsets the ‘dirty’ flag.

(Note I'm not arguing that the feature is, on balance, worth including,
merely answering the questions you asked.)

Smylers
-- 
http://twitter.com/Smylers2


[whatwg] Fwd: Range.createContextualFragment in SVG contexts

2014-10-28 Thread Daniel Trebbien
(My apologies if you get this twice.  I haven't seen my message on the public
archives http://lists.w3.org/Archives/Public/public-whatwg-archive/, so I
suspect that it was dropped.)

On Sat, Dec 28, 2013 at 5:29 AM, Cameron McCormack c...@mcc.id.au wrote:

 Hi Victor,

 Victor Costan wrote:

 I'm trying to re-implement Range.createContextualFragment in Blink
 following this whatwg spec:
 http://domparsing.spec.whatwg.org/#extensions-to-the-range-interface

 There are two issues I'd like to discuss, related to the use of
 createContextualFragment in SVG contexts.

 1) If a Range's context is ansvg  element, I think the XML parsing
 algorithm should be selected, so the elements in the resulting
 DocumentFragment would get the SVG namespace. This way, inserting the
 fragment in ansvg  tree would have the intended effect.

 Examples:
 https://bug711821.bugzilla.mozilla.org/attachment.cgi?id=582654
 (the red circle should be completely covered by a black circle)

 https://codereview.chromium.org/115693010/diff/70001/
 LayoutTests/fast/dom/Range/create-contextual-fragment-
 from-svg-element-range.html


 I think it would be unexpected that XML parsing is used here, when HTML
 parsing was used to get the SVG fragment in the document in the first
 place.  Maybe the HTML fragment parsing algorithm should be changed to push
 the svg element on to the stack of open elements so that the parser will
 interpret the circle .../ as foreign content?



Issues related to Range.createContextualFragment() in SVG contexts are
starting to come up in bug reports:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1087715
- https://code.google.com/p/chromium/issues/detail?id=426400

Should Cameron's idea for changing the HTML fragment parsing algorithm be
implemented?

One other idea is to change the in body insertion mode spec so that there
are 'A start tag whose tag name is one of: defs, g, svg' steps, but I
personally think that Cameron's idea is much better.

Daniel


Re: [whatwg] Fwd: Range.createContextualFragment in SVG contexts

2014-10-28 Thread Anne van Kesteren
On Tue, Oct 28, 2014 at 1:35 PM, Daniel Trebbien dtrebb...@gmail.com wrote:
 Issues related to Range.createContextualFragment() in SVG contexts are
 starting to come up in bug reports:
 - https://bugzilla.mozilla.org/show_bug.cgi?id=1087715
 - https://code.google.com/p/chromium/issues/detail?id=426400

 Should Cameron's idea for changing the HTML fragment parsing algorithm be
 implemented?

Now Firefox' fragment parsing is fixed, it seems it behaves the same
as Chrome. Not sure what's going on.


-- 
https://annevankesteren.nl/


Re: [whatwg] Fwd: Range.createContextualFragment in SVG contexts

2014-10-28 Thread Daniel Trebbien
On Tue, Oct 28, 2014 at 8:45 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Oct 28, 2014 at 1:35 PM, Daniel Trebbien dtrebb...@gmail.com
 wrote:
  Issues related to Range.createContextualFragment() in SVG contexts are
  starting to come up in bug reports:
  - https://bugzilla.mozilla.org/show_bug.cgi?id=1087715
  - https://code.google.com/p/chromium/issues/detail?id=426400
 
  Should Cameron's idea for changing the HTML fragment parsing algorithm be
  implemented?

 Now Firefox' fragment parsing is fixed, it seems it behaves the same
 as Chrome. Not sure what's going on.



I linked to the Firefox bug report mainly for context.  Firefox' behavior
seems correct now, and I can confirm that the modified jsFiddle
http://jsfiddle.net/hfvz7srp/1/ is working correctly in Firefox Nightly
36.0a1 (2014-10-28).

The issue that I am referring to is the behavior of
Range.createContextualFragment() when the context node is not an SVG svg
element, but some other SVG element such as an SVG defs or g element.


Re: [whatwg] Fwd: Range.createContextualFragment in SVG contexts

2014-10-28 Thread Anne van Kesteren
On Tue, Oct 28, 2014 at 2:29 PM, Daniel Trebbien dtrebb...@gmail.com wrote:
 The issue that I am referring to is the behavior of
 Range.createContextualFragment() when the context node is not an SVG svg
 element, but some other SVG element such as an SVG defs or g element.

If you change the range's start node to e.g. the defs element,
you'll find Firefox reports two child nodes, just like Chrome.

I think given https://www.w3.org/Bugs/Public/show_bug.cgi?id=17924 and
https://html5.org/r/7768 we were probably reading the specification
wrong.


-- 
https://annevankesteren.nl/


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

2014-10-28 Thread Ashley Gullen
Can this be used for gapless looping of the same track? This is a common
request for game developers looking to seamlessly loop a music or ambience
track: https://code.google.com/p/chromium/issues/detail?id=353072

Ashley


On 27 October 2014 20:09, Dale Curtis dalecur...@chromium.org wrote:

 Hi,

 Chrome developer here, gapless playback should work with both WebAudio and
 Media Source Extensions (MSE). I've fixed bugs in both implementations, so
 if you have some test cases in Chrome that fail, I'd love to see them. As
 luck has it, I've recently put an article together on how to use MSE for
 gapless playback:

 http://dalecurtis.github.io/llama-demo/index.html

 We'll be posting it to HTML5Rocks in the near future. Feel free to contact
 me if you have any questions. You also note that setTimeout() is not
 precise enough for your usage; you should take a look at the WebAudio
 scheduler or using WebWorkers:

 http://www.html5rocks.com/en/tutorials/audio/scheduling/
 https://github.com/chrisguttandin/worker-timers

 If you only need your project to work in the foreground using
 requestAnimationFrame is also an option. I'd first try to schedule as much
 as you can in advance though.

 - dale



Re: [whatwg] Shared storage

2014-10-28 Thread Ian Hickson
On Sat, 15 Feb 2014, Brett Zamir wrote:
 
 The desktop PC thankfully evolved into allowing third-party software 
 which could create and edit files shareable by other third-party 
 software which would have the same rights to do the same. The importance 
 of this can hardly be overestimated.
 
 Yet today, on the web, there appears to be no standard way to create 
 content in such an agnostic manner whereby users have full, built-in, 
 locally-controlled portability of their data.

Why can't you just do the same as used to be done? Download the resource 
locally (save, using a href download), then upload it to the new site 
(open, using input type=file)?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


Re: [whatwg] New feature: better integration with browser find interface

2014-10-28 Thread Ian Hickson
On Sun, 23 Feb 2014, Mitar wrote:
 
 If you open a long document in Google Docs not whole
 document is rendered immediately so DOM does not contain whole
 document. If [...]
 you invoke find through browser menu you get browser's original find
 interface which does not really work and does not find anything on
 page not yet rendered. [...]

 Mozilla pdf.js HTML5 PDF library [...] Rendering whole PDF would consume 
 too much resources so only pages visible to the user are added to DOM. 
 Browser thus cannot find content on pages not visible. [...] Have same 
 workaround of intercepting a ctrl-f keystroke.

 [...other similar use cases...]
 
 - styling of how matched text looks, and how highlighted text looks
 (when user selects to highlight all matches in UAs that support
 that) - some browsers reuse selection style (Firefox), some browsers
 have special style you cannot style with CSS (Chrome)

The various use cases you gave didn't seem to be derived from this need. 
How much of a need is this?


 - telling to the web application that search is being in progress and
 what is being searched for

That does seem to be something that is necessary.

I've filed a bug to track it:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=27186


 - telling UA that it should retry the search because content has been 
 changed/rendered/modified

 The last is important because for web application which dynamically 
 render the content, after search has already find matches on the page, 
 if content is changed, browsers do not retry the search. This is the 
 most evident with browsers which allow highlight all feature, like 
 Google Chrome.

This is just a bug in the browsers.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


Re: [whatwg] Shared storage

2014-10-28 Thread Tobie Langel
On Tue, Oct 28, 2014 at 6:33 PM, Ian Hickson i...@hixie.ch wrote:

 On Sat, 15 Feb 2014, Brett Zamir wrote:
 
  The desktop PC thankfully evolved into allowing third-party software
  which could create and edit files shareable by other third-party
  software which would have the same rights to do the same. The importance
  of this can hardly be overestimated.
 
  Yet today, on the web, there appears to be no standard way to create
  content in such an agnostic manner whereby users have full, built-in,
  locally-controlled portability of their data.

 Why can't you just do the same as used to be done? Download the resource
 locally (save, using a href download), then upload it to the new site
 (open, using input type=file)?


Because that's a terrible user experience?

--tobie


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

2014-10-28 Thread Dale Curtis
Yes, both WebAudio and MSE can do that, though I'd probably lean towards
WebAudio for anything game related. Using WebAudio just create a buffer
source and set the loop attribute:

https://developer.mozilla.org/en-US/docs/Web/API/AudioBufferSourceNode.loop

The way you could do it with MediaSource would be to double buffer the
track such that you're creating an infinite stream. I.e. append a new copy
of the track as time reaches the end of the previously appended track. To
avoid unnecessary memory usage you would remove stale copies of the data
once played.

- dale

On Tue, Oct 28, 2014 at 9:55 AM, Ashley Gullen ash...@scirra.com wrote:

 Can this be used for gapless looping of the same track? This is a common
 request for game developers looking to seamlessly loop a music or ambience
 track: https://code.google.com/p/chromium/issues/detail?id=353072

 Ashley


 On 27 October 2014 20:09, Dale Curtis dalecur...@chromium.org wrote:

 Hi,

 Chrome developer here, gapless playback should work with both WebAudio and
 Media Source Extensions (MSE). I've fixed bugs in both implementations, so
 if you have some test cases in Chrome that fail, I'd love to see them. As
 luck has it, I've recently put an article together on how to use MSE for
 gapless playback:

 http://dalecurtis.github.io/llama-demo/index.html

 We'll be posting it to HTML5Rocks in the near future. Feel free to contact
 me if you have any questions. You also note that setTimeout() is not
 precise enough for your usage; you should take a look at the WebAudio
 scheduler or using WebWorkers:

 http://www.html5rocks.com/en/tutorials/audio/scheduling/
 https://github.com/chrisguttandin/worker-timers

 If you only need your project to work in the foreground using
 requestAnimationFrame is also an option. I'd first try to schedule as much
 as you can in advance though.

 - dale





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

2014-10-28 Thread Ashley Gullen
Web Audio is unsuitable for music tracks due to needing to download and
fully decompress in to memory the entire track before starting playback. It
would be nice if this could just work with the HTML5 audio loop tag.

Ashley


On 28 October 2014 18:06, Dale Curtis dalecur...@chromium.org wrote:

 Yes, both WebAudio and MSE can do that, though I'd probably lean towards
 WebAudio for anything game related. Using WebAudio just create a buffer
 source and set the loop attribute:

 https://developer.mozilla.org/en-US/docs/Web/API/AudioBufferSourceNode.loop

 The way you could do it with MediaSource would be to double buffer the
 track such that you're creating an infinite stream. I.e. append a new copy
 of the track as time reaches the end of the previously appended track. To
 avoid unnecessary memory usage you would remove stale copies of the data
 once played.

 - dale

 On Tue, Oct 28, 2014 at 9:55 AM, Ashley Gullen ash...@scirra.com wrote:

 Can this be used for gapless looping of the same track? This is a common
 request for game developers looking to seamlessly loop a music or ambience
 track: https://code.google.com/p/chromium/issues/detail?id=353072

 Ashley


 On 27 October 2014 20:09, Dale Curtis dalecur...@chromium.org wrote:

 Hi,

 Chrome developer here, gapless playback should work with both WebAudio
 and
 Media Source Extensions (MSE). I've fixed bugs in both implementations,
 so
 if you have some test cases in Chrome that fail, I'd love to see them. As
 luck has it, I've recently put an article together on how to use MSE for
 gapless playback:

 http://dalecurtis.github.io/llama-demo/index.html

 We'll be posting it to HTML5Rocks in the near future. Feel free to
 contact
 me if you have any questions. You also note that setTimeout() is not
 precise enough for your usage; you should take a look at the WebAudio
 scheduler or using WebWorkers:

 http://www.html5rocks.com/en/tutorials/audio/scheduling/
 https://github.com/chrisguttandin/worker-timers

 If you only need your project to work in the foreground using
 requestAnimationFrame is also an option. I'd first try to schedule as
 much
 as you can in advance though.

 - dale






Re: [whatwg] Shared storage

2014-10-28 Thread Nils Dagsson Moskopp
Tobie Langel tobie.lan...@gmail.com writes:

 On Tue, Oct 28, 2014 at 6:33 PM, Ian Hickson i...@hixie.ch wrote:

 On Sat, 15 Feb 2014, Brett Zamir wrote:
 
  The desktop PC thankfully evolved into allowing third-party software
  which could create and edit files shareable by other third-party
  software which would have the same rights to do the same. The importance
  of this can hardly be overestimated.
 
  Yet today, on the web, there appears to be no standard way to create
  content in such an agnostic manner whereby users have full, built-in,
  locally-controlled portability of their data.

 Why can't you just do the same as used to be done? Download the resource
 locally (save, using a href download), then upload it to the new site
 (open, using input type=file)?


 Because that's a terrible user experience?

If that is indeed the case, the terrible user experience is likely a
feature of your user agent. Many mobile UAs currently offer several
alternatives to the standard file-picker, no change in HTML needed.

-- 
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net


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

2014-10-28 Thread Dale Curtis
Unfortunately, making loop in the bare audio tag sample accurate in Chrome
is non-trivial for a variety of reasons, so it's unlikely to happen anytime
soon. The MSE based approach should work great in the meantime; I've used
the approach described above for seamless audio+video looping.

- dale

On Tue, Oct 28, 2014 at 11:59 AM, Ashley Gullen ash...@scirra.com wrote:

 Web Audio is unsuitable for music tracks due to needing to download and
 fully decompress in to memory the entire track before starting playback. It
 would be nice if this could just work with the HTML5 audio loop tag.

 Ashley


 On 28 October 2014 18:06, Dale Curtis dalecur...@chromium.org wrote:

 Yes, both WebAudio and MSE can do that, though I'd probably lean towards
 WebAudio for anything game related. Using WebAudio just create a buffer
 source and set the loop attribute:


 https://developer.mozilla.org/en-US/docs/Web/API/AudioBufferSourceNode.loop

 The way you could do it with MediaSource would be to double buffer the
 track such that you're creating an infinite stream. I.e. append a new copy
 of the track as time reaches the end of the previously appended track. To
 avoid unnecessary memory usage you would remove stale copies of the data
 once played.

 - dale

 On Tue, Oct 28, 2014 at 9:55 AM, Ashley Gullen ash...@scirra.com wrote:

 Can this be used for gapless looping of the same track? This is a common
 request for game developers looking to seamlessly loop a music or ambience
 track: https://code.google.com/p/chromium/issues/detail?id=353072

 Ashley


 On 27 October 2014 20:09, Dale Curtis dalecur...@chromium.org wrote:

 Hi,

 Chrome developer here, gapless playback should work with both WebAudio
 and
 Media Source Extensions (MSE). I've fixed bugs in both implementations,
 so
 if you have some test cases in Chrome that fail, I'd love to see them.
 As
 luck has it, I've recently put an article together on how to use MSE for
 gapless playback:

 http://dalecurtis.github.io/llama-demo/index.html

 We'll be posting it to HTML5Rocks in the near future. Feel free to
 contact
 me if you have any questions. You also note that setTimeout() is not
 precise enough for your usage; you should take a look at the WebAudio
 scheduler or using WebWorkers:

 http://www.html5rocks.com/en/tutorials/audio/scheduling/
 https://github.com/chrisguttandin/worker-timers

 If you only need your project to work in the foreground using
 requestAnimationFrame is also an option. I'd first try to schedule as
 much
 as you can in advance though.

 - dale







Re: [whatwg] Shared storage

2014-10-28 Thread Katelyn Gadd
A smarter file-picker is not going to address the significant UX and
performance issues with save-open for moving files between
applications.

Many common workflows involve having files open in multiple editors at
once, saving in one app, reloading in others. Some applications have
built in affordances for this, like text editors and IDEs that
automatically reload when the content has changed on disk. One
real-world example: Unity's project management lets you pull various
resources into your game, then live-edit the resources in Maya,
Photoshop, etc with the IDE automatically pulling in the changes and
running builds to update the content.

If this kind of interchange and interaction requires literally doing
save-confirm save-open-pick saved file from wherever it went *every
time* nobody will use these applications. The applications that get
used will be ones that figure out a clever set of workarounds like the
postmessage/blessed domain one mentioned in the original post. That
sort of approach is something that will easily lead to a walled garden
library that 'solves the problem' and becomes widely adopted, when
HTML5 itself could probably tackle the issue without a bunch of new
scaffolding or significant new APIs.

Mind you, I'm not saying this is an easy problem to solve - just that
it's worth solving and that save-open is not a solution.

One idea: 'transferable' support for indexedDB such that a blessed
domain can postMessage an indexedDB database over to another domain,
to allow shared access to storage for a specific database. This
doesn't address all the problems in the original post, but simplifies
the task of sharing content between applications. This would probably
also pay dividends for web workers.
(Actually, is this already specced? I only know that worker access to
indexedDB wasn't available in Gecko or Blink the last time I checked
and didn't seem to be a planned addition.)

Another option: Some simple protocol for creating 'shared' databases
using a special token in the name you pass to indexedDB.open? I can
see how this might be a compat problem, but it would be a pretty
low-overhead way to expose basic support for this. Perhaps the unique
token you pass would be created by a feature-detectable API, sort of
like how createObjectURL works. That would give you a single point
where you can insert approval/feedback UI and do any necessary I/O to
set up sharing, while the rest of the database flow remains unchanged.

Synchronization between two processes mutually touching the DB is hard
but you could just punt on that like is currently done with typed
arrays - neutering or equivalent. Alternately, a single database-wide
lock would probably cover things - that's the approach SQLite used for
a long time.

-kg


On 28 October 2014 12:17, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
 Tobie Langel tobie.lan...@gmail.com writes:

 On Tue, Oct 28, 2014 at 6:33 PM, Ian Hickson i...@hixie.ch wrote:

 On Sat, 15 Feb 2014, Brett Zamir wrote:
 
  The desktop PC thankfully evolved into allowing third-party software
  which could create and edit files shareable by other third-party
  software which would have the same rights to do the same. The importance
  of this can hardly be overestimated.
 
  Yet today, on the web, there appears to be no standard way to create
  content in such an agnostic manner whereby users have full, built-in,
  locally-controlled portability of their data.

 Why can't you just do the same as used to be done? Download the resource
 locally (save, using a href download), then upload it to the new site
 (open, using input type=file)?


 Because that's a terrible user experience?

 If that is indeed the case, the terrible user experience is likely a
 feature of your user agent. Many mobile UAs currently offer several
 alternatives to the standard file-picker, no change in HTML needed.

 --
 Nils Dagsson Moskopp // erlehmann
 http://dieweltistgarnichtso.net


Re: [whatwg] Shared storage

2014-10-28 Thread Melvin Carvalho
On 15 February 2014 03:04, Brett Zamir bret...@yahoo.com wrote:

 *The opportunity and current obstacles*

 The desktop PC thankfully evolved into allowing third-party software which
 could create and edit files shareable by other third-party software which
 would have the same rights to do the same. The importance of this can
 hardly be overestimated.

 Yet today, on the web, there appears to be no standard way to create
 content in such an agnostic manner whereby users have full, built-in,
 locally-controlled portability of their data.

 *Workarounds*

 Sure, there is postMessage or CORS requests which can be used to allow one
 site to be the arbiter of this data.

 And one could conceivably create a shared data store built upon even
 postMessage alone, even one which can work fully offline through cache
 manifests and localStorage or IndexedDB (I have begun some work on this
 concept at https://gist.github.com/brettz9/8876920 ), but this can only
 work if:

 1. A site or set of domains is trusted to host the shared content.
 2. Instead of being built into the browser, it requires that the shared
 storage site be visited at least one time.

 *Proposal*

 1. Add support for sharedStorage (similar to globalStorage but requiring
 approval), SharedIndexedDB, and SharedFileWriter/SharedFileSystem which,
 when used, would cause the browser to prompt the user to require user
 approval whenever storing or retrieving from such data stores (with an
 option to remember the choice for a particular site/domain), informing
 users of potential risks depending on how the data might be used, and
 potentially allowing them to view, on the spot, the specific data that was
 being stored.

 Optional API methods could deter XSS by doing selective escaping, but the
 potential for abuse should not be used as an excuse for preventing
 arbitrary shared storage, since again, it is worked well on the desktop,
 despite risks there, and as works with postMessage despite it also having
 risks.

 2. Add support for corresponding ReadonlyShared storage mechanisms,
 namespaced by the origin site of the data. A site, http://example.com
 might add such shared storage under example.com which
 http://some-other-site.example could retrieve but not alter or delete
 (unless perhaps a grave warning were given to users about the fact that
 this was not the same domain). This would have the benefit above
 postMessage in that if the origin site goes down, third party sites would
 still be able to have access to the data.

 3. Encourage browsers to allow direct editing of this stored data in a
 human-readable manner (with files at least being ideally directly viewable
 from the OS desktop).

 I proposed something similar earlier, and received a reply about doing
 this through shared workers, but as I understood it, I did not like that
 possibility because:

 a. it would limit the neutrality of the storage, creating one site as
 an unchallengeable arbiter of the data
 b. it would increase complexity for developers
 c. it would presumably depend on the setting of CORS directives to
 distinguish it from same-domain shared workers.

 While https://wiki.mozilla.org/WebAPI/DeviceStorageAPI appears to meet a
 subset of these needs, it does not meet all.


+1



 Thank you,
 Brett




Re: [whatwg] Shared storage

2014-10-28 Thread Melvin Carvalho
On 28 October 2014 21:32, Nils Dagsson Moskopp 
n...@dieweltistgarnichtso.net wrote:

 Melvin Carvalho melvincarva...@gmail.com writes:

  On 15 February 2014 03:04, Brett Zamir bret...@yahoo.com wrote:
 
  *The opportunity and current obstacles*
 
  The desktop PC thankfully evolved into allowing third-party software
 which
  could create and edit files shareable by other third-party software
 which
  would have the same rights to do the same. The importance of this can
  hardly be overestimated.
 
  Yet today, on the web, there appears to be no standard way to create
  content in such an agnostic manner whereby users have full, built-in,
  locally-controlled portability of their data.
 
  *Workarounds*
 
  Sure, there is postMessage or CORS requests which can be used to allow
 one
  site to be the arbiter of this data.
 
  And one could conceivably create a shared data store built upon even
  postMessage alone, even one which can work fully offline through cache
  manifests and localStorage or IndexedDB (I have begun some work on this
  concept at https://gist.github.com/brettz9/8876920 ), but this can only
  work if:
 
  1. A site or set of domains is trusted to host the shared content.
  2. Instead of being built into the browser, it requires that the shared
  storage site be visited at least one time.
 
  *Proposal*
 
  1. Add support for sharedStorage (similar to globalStorage but requiring
  approval), SharedIndexedDB, and SharedFileWriter/SharedFileSystem which,
  when used, would cause the browser to prompt the user to require user
  approval whenever storing or retrieving from such data stores (with an
  option to remember the choice for a particular site/domain), informing
  users of potential risks depending on how the data might be used, and
  potentially allowing them to view, on the spot, the specific data that
 was
  being stored.
 
  Optional API methods could deter XSS by doing selective escaping, but
 the
  potential for abuse should not be used as an excuse for preventing
  arbitrary shared storage, since again, it is worked well on the desktop,
  despite risks there, and as works with postMessage despite it also
 having
  risks.
 
  2. Add support for corresponding ReadonlyShared storage mechanisms,
  namespaced by the origin site of the data. A site, http://example.com
  might add such shared storage under example.com which
  http://some-other-site.example could retrieve but not alter or delete
  (unless perhaps a grave warning were given to users about the fact that
  this was not the same domain). This would have the benefit above
  postMessage in that if the origin site goes down, third party sites
 would
  still be able to have access to the data.
 
  3. Encourage browsers to allow direct editing of this stored data in a
  human-readable manner (with files at least being ideally directly
 viewable
  from the OS desktop).
 
  I proposed something similar earlier, and received a reply about doing
  this through shared workers, but as I understood it, I did not like that
  possibility because:
 
  a. it would limit the neutrality of the storage, creating one site
 as
  an unchallengeable arbiter of the data
  b. it would increase complexity for developers
  c. it would presumably depend on the setting of CORS directives to
  distinguish it from same-domain shared workers.
 
  While https://wiki.mozilla.org/WebAPI/DeviceStorageAPI appears to meet
 a
  subset of these needs, it does not meet all.
 
 
  +1

 Stop doing this.


Excuse me?



 --
 Nils Dagsson Moskopp // erlehmann
 http://dieweltistgarnichtso.net



Re: [whatwg] Shared storage

2014-10-28 Thread Nils Dagsson Moskopp
Melvin Carvalho melvincarva...@gmail.com writes:

 On 28 October 2014 21:32, Nils Dagsson Moskopp 
 n...@dieweltistgarnichtso.net wrote:

 Melvin Carvalho melvincarva...@gmail.com writes:

  On 15 February 2014 03:04, Brett Zamir bret...@yahoo.com wrote:
 
  *The opportunity and current obstacles*
 
  The desktop PC thankfully evolved into allowing third-party software
 which
  could create and edit files shareable by other third-party software
 which
  would have the same rights to do the same. The importance of this can
  hardly be overestimated.
 
  Yet today, on the web, there appears to be no standard way to create
  content in such an agnostic manner whereby users have full, built-in,
  locally-controlled portability of their data.
 
  *Workarounds*
 
  Sure, there is postMessage or CORS requests which can be used to allow
 one
  site to be the arbiter of this data.
 
  And one could conceivably create a shared data store built upon even
  postMessage alone, even one which can work fully offline through cache
  manifests and localStorage or IndexedDB (I have begun some work on this
  concept at https://gist.github.com/brettz9/8876920 ), but this can only
  work if:
 
  1. A site or set of domains is trusted to host the shared content.
  2. Instead of being built into the browser, it requires that the shared
  storage site be visited at least one time.
 
  *Proposal*
 
  1. Add support for sharedStorage (similar to globalStorage but requiring
  approval), SharedIndexedDB, and SharedFileWriter/SharedFileSystem which,
  when used, would cause the browser to prompt the user to require user
  approval whenever storing or retrieving from such data stores (with an
  option to remember the choice for a particular site/domain), informing
  users of potential risks depending on how the data might be used, and
  potentially allowing them to view, on the spot, the specific data that
 was
  being stored.
 
  Optional API methods could deter XSS by doing selective escaping, but
 the
  potential for abuse should not be used as an excuse for preventing
  arbitrary shared storage, since again, it is worked well on the desktop,
  despite risks there, and as works with postMessage despite it also
 having
  risks.
 
  2. Add support for corresponding ReadonlyShared storage mechanisms,
  namespaced by the origin site of the data. A site, http://example.com
  might add such shared storage under example.com which
  http://some-other-site.example could retrieve but not alter or delete
  (unless perhaps a grave warning were given to users about the fact that
  this was not the same domain). This would have the benefit above
  postMessage in that if the origin site goes down, third party sites
 would
  still be able to have access to the data.
 
  3. Encourage browsers to allow direct editing of this stored data in a
  human-readable manner (with files at least being ideally directly
 viewable
  from the OS desktop).
 
  I proposed something similar earlier, and received a reply about doing
  this through shared workers, but as I understood it, I did not like that
  possibility because:
 
  a. it would limit the neutrality of the storage, creating one site
 as
  an unchallengeable arbiter of the data
  b. it would increase complexity for developers
  c. it would presumably depend on the setting of CORS directives to
  distinguish it from same-domain shared workers.
 
  While https://wiki.mozilla.org/WebAPI/DeviceStorageAPI appears to meet
 a
  subset of these needs, it does not meet all.
 
 
  +1

 Stop doing this.


 Excuse me?


If I am not mistaken, you full-quoted an entire Email just to add „+1“.

If you would have done similar in the Google+ Ghetto or on Facebook, I
would have no problem with your behaviour. However, on a mailing list,
you are annoying people, probably the few hundred or thousand who are
subscribed in this case. You are wasting their time – and yours, if I
might add … since the WHATWG was not a democracy last time I checked.

-- 
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net