Re: File API: reading a Blob

[Arun Ranganathan]

On Jul 3, 2014, at 10:50 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Thu, Jul 3, 2014 at 4:29 PM, Arun Ranganathan a...@mozilla.com wrote:
 OK, this is fixable. I’ll ensure that the read operation’s synchronous
 component does return the results thus far, but that FIleReaderSync itself
 ignores them in case of a midstream error, unless we collectively agree that
 it SHOULD return partial instead of “all or nothing” as an API. My
 understanding of the FileReaderSync requirement is all or nothing, but I’m
 open to being wrong via bug filing.
 
 That would mean you would get different results between using
 FileReaderSync and XMLHttpRequest. That does not seem ideal



The implementation train has already left the station on this. The movitation 
of an “ideal match-up with XMLHttpRequest doesn’t seem strong enough to 
revisit this by filing browser bugs across implementations (but Cc’ing K. Huey 
also).

We agreed some time ago to not have partial data.


 
 The tasks are still a bit of a concern as a normal implementation
 would not queue tasks. E.g. it's not even clear what task loop Fetch
 would retrieve this from as fetch is itself a different process.


Then let’s have a different read operation that doesn’t use the FileReader Task 
Source. The primary API in File API uses the event loop (FileReader), so for 
that purpose, the existing read operation is important. Early discussions about 
this made me feel that a task queue based system to asynchronously read blobs 
could be reusable by Fetch, and by future Promise-based APIs. 

Since it’s not reusable for Fetch, let’s not try and force it. We’ll do a new 
one along the lines you described at the start of this email.

— A*

Re: Editing with native UI

[Piotr Koszuliński]

On Tue, Jul 1, 2014 at 1:19 AM, Ryosuke Niwa rn...@apple.com wrote:


 On Jun 24, 2014, at 3:44 AM, Robin Berjon ro...@w3.org wrote:


 Second, it doesn't address the point made below about native UI exposing a
 likely non-natural subset of the commands I wish to support.


 That presumes an opt-out mechanism to enable native UI.  If we had used
 opt-in instead, then we wouldn't have this issue.


I think that it may happen in both cases. Developer won't know if on
platform X there's native UI for all commands that he/she wants to enable.
Mobile Safari displays numbered and bulleted lists buttons, but browser Y
may support only bold, italic and underline and in such case content
created on Safari will not be fully editable on browser Y.

That's why I can't imagine using native UI for more than a really simplest
use cases (e.g. comments on blog). But if native UI will stay, opt-in
mechanism is definitely the way to go.




 There is a list of problems with the current editing API:

- Undo/redo menu doesn't get enabled/disabled in accordance with the
app's intrernal undo stack.


Yes. It would be great if native undo/redo options were controllable. I'm
also hesitating whether cut and paste options should not be controllable.
That would give us similar control as we have over drag and drop.



BTW. It struck me recently that we're writing here about disabling commands
in order to remove them from native UI. But enabling/disabling command is
something different than removing (hiding/showing) option from native
toolbar or context menu.

For example - I may decide that inline styling (i.e. bold, italic) should
not be available in my editor. There's no point in having them in the
toolbar, so I want to remove them. On the other hand, my app has an
internal undo stack, so if it's empty I want to disable undo and redo
buttons. I don't want to hide them. I just want to change their state.

Similarly, different rules regarding what content is allowed may apply in
editable areas within one editor (having one toolbar). This is a very
popular scenario in CKEditor (see e.g. how toolbar behaves when moving
selection from main editing area to image's caption in [1]). In such case I
want to be able to disable some commands without hiding them, because
that's less confusing for users.

Therefore, I believe that we need two methods - one to control commands'
states and one to enable/disable features (meaning - showing/hiding). Also,
a feature isn't necessarily the same as command. We may have different set
of features that can be enabled and commands which states are controllable.


[1]
http://cdn.ckeditor.com/4.4.2/standard-all/samples/plugins/image2/image2.html

-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer