Re: [File API] Draft for Review

[Mike Taylor]

On Thu, 26 Jan 2012 22:54:39 -0600, Glenn Maynard  wrote:


On Thu, Jan 26, 2012 at 10:45 PM, Mike Taylor  wrote:


As someone who occasionally has to look up if the 3rd argument to
XMLHttpRequest.open() means sync or async, I agree with Tab. And that's
something I've been using for years. Forget about synthetic keyboard  
events

[1]:

event.initKeyEvent("keypress", true, true, null, null, false, false,
false, false, 9, 0);



This is showing exactly my point: the null, 9 and 0 arguments are just as
mysterious as the boolean arguments.  It's hard to understand because  
there

are too many arguments, not because they're boolean.


Yes, synthetic keypress have multiple problems--which is why we all use  
libraries to not have to author them by hand.


Regardless, this doesn't change the fact that  
window.URL.createObjectURL(file, true) is more opaque (and for me, harder  
to remember) than:


window.URL.createObjectURL(file, {oneTimeOnly: true})

or something magical like window.URL.createObjectURL(file).oneTimeOnly()

Cheers,

--
Mike Taylor
Opera Software

Re: [File API] Draft for Review

[Glenn Maynard]

On Thu, Jan 26, 2012 at 10:45 PM, Mike Taylor  wrote:

> As someone who occasionally has to look up if the 3rd argument to
> XMLHttpRequest.open() means sync or async, I agree with Tab. And that's
> something I've been using for years. Forget about synthetic keyboard events
> [1]:
>
> event.initKeyEvent("keypress", true, true, null, null, false, false,
> false, false, 9, 0);
>

This is showing exactly my point: the null, 9 and 0 arguments are just as
mysterious as the boolean arguments.  It's hard to understand because there
are too many arguments, not because they're boolean.

-- 
Glenn Maynard

Re: [File API] Draft for Review

[Mike Taylor]

On Thu, 26 Jan 2012 21:23:46 -0600, Glenn Maynard  wrote:


On Thu, Jan 26, 2012 at 7:01 PM, Tab Atkins Jr. 
 wrote:


That's not necessary.  There are situations when optional arguments
make sense.  They should be avoided, though, when you expect that
*future* optional arguments will have nothing to do with the current
one, as otherwise you'll have to specify the "optional" argument every
time with some null value.

Charles gives examples of a few arguments we may want to provide in
the future, all of which have nothing to do with whether the url is
single-use or reusable.



This is all fine.  It's only the argument that booleans are so much more
opaque than other argument types (numbers, at least) that I find
unconvincing.


As someone who occasionally has to look up if the 3rd argument to  
XMLHttpRequest.open() means sync or async, I agree with Tab. And that's  
something I've been using for years. Forget about synthetic keyboard  
events [1]:


event.initKeyEvent("keypress", true, true, null, null, false, false,  
false, false, 9, 0);


[1] Example cribbed from  
http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html


--
Mike Taylor
Opera Software

Re: [File API] Draft for Review

[Glenn Maynard]

On Thu, Jan 26, 2012 at 6:54 PM, Ojan Vafai  wrote:
>
> That said, I sympathize that the overhead of creating an object or needing
> to do a string compare just for a boolean is kind of sucky.
>

I'd expect implementations to mostly optimize away string comparisons with
string interning, though.


On Thu, Jan 26, 2012 at 7:01 PM, Tab Atkins Jr. 
 wrote:

> That's not necessary.  There are situations when optional arguments
> make sense.  They should be avoided, though, when you expect that
> *future* optional arguments will have nothing to do with the current
> one, as otherwise you'll have to specify the "optional" argument every
> time with some null value.
>
> Charles gives examples of a few arguments we may want to provide in
> the future, all of which have nothing to do with whether the url is
> single-use or reusable.
>

This is all fine.  It's only the argument that booleans are so much more
opaque than other argument types (numbers, at least) that I find
unconvincing.

-- 
Glenn Maynard

Re: [File API] Draft for Review

[Tab Atkins Jr.]

On Thu, Jan 26, 2012 at 4:42 PM, Glenn Maynard  wrote:
> On Thu, Jan 26, 2012 at 6:25 PM, Tab Atkins Jr. 
> wrote:
>> As I argued in
>> ,
>> we should absolutely *not* be adding more boolean arguments to the
>> platform.  They should be exposed as boolean properties in an
>> dictionary.
>
> I don't find this compelling; you could make the same argument for any
> optional argument.  When you only have a couple arguments, the additional
> verbosity is a loss, particularly if the argument is used frequently.
>
> When to use a dictionary is a judgement call, but it doesn't have anything
> to do with the argument's type.
>
>> Naked bools are impossible to decipher without memorizing the call
>> signature of every function.
>
> Unless you're going to argue that *all* optional arguments should be moved
> to dictionaries, this doesn't make sense--you always have to know the call
> signature of functions you're calling.  That's no burden as long as you
> don't have too many arguments (like init*Event).

That's not necessary.  There are situations when optional arguments
make sense.  They should be avoided, though, when you expect that
*future* optional arguments will have nothing to do with the current
one, as otherwise you'll have to specify the "optional" argument every
time with some null value.

Charles gives examples of a few arguments we may want to provide in
the future, all of which have nothing to do with whether the url is
single-use or reusable.

Ojan clarifies the "you have to memorize the call signature" argument
I was making - many arguments are pretty obvious and easy when you see
them in use.  Naked bools almost never are.

~TJ

Re: [File API] Draft for Review

[Ojan Vafai]

On Thu, Jan 26, 2012 at 4:42 PM, Glenn Maynard  wrote:

> On Thu, Jan 26, 2012 at 6:25 PM, Tab Atkins Jr. wrote:
>
>> As I argued in <
>> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1520.html>,
>> we should absolutely *not* be adding more boolean arguments to the
>> platform.  They should be exposed as boolean properties in an
>> dictionary.
>
>
> I don't find this compelling; you could make the same argument for any
> optional argument.  When you only have a couple arguments, the additional
> verbosity is a loss, particularly if the argument is used frequently.
>

Depends on the argument type. For example, in document.createElement('div')
it's pretty obvious that the string is the tagname. Whereas in
node.cloneNode(true) it's not clear without looking at the signature of
cloneNode whether true means deep clone or shallow clone.
node.cloneNode({deep:true}) or node.cloneNode('deep') are clear without
looking up the signature.

That said, I sympathize that the overhead of creating an object or needing
to do a string compare just for a boolean is kind of sucky.

Re: [File API] Draft for Review

[Charles Pritchard]

On 1/26/12 4:39 PM, Jonas Sicking wrote:

On Thu, Jan 26, 2012 at 4:25 PM, Tab Atkins Jr.  wrote:

On Thu, Jan 26, 2012 at 1:21 PM, Arun Ranganathan
  wrote:

2. URL.createObjectURL now takes an optional boolean, following discussions on 
the listserv [oneTimeOnly].

As I argued 
in,
we should absolutely *not* be adding more boolean arguments to the
platform.  They should be exposed as boolean properties in an
dictionary.  Naked bools are impossible to decipher without memorizing
the call signature of every function.

I would be ok with that. We'll possibly want to add other optional
arguments anyway, like headers


I could see: {expires: }, {name: } and {disposition: } as useful.

I could see Allow Origin CORS as something useful too, but that's 
starting to go off the range.


-Charles

Re: [File API] Draft for Review

[Glenn Maynard]

On Thu, Jan 26, 2012 at 6:25 PM, Tab Atkins Jr. wrote:

> As I argued in <
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1520.html>,
> we should absolutely *not* be adding more boolean arguments to the
> platform.  They should be exposed as boolean properties in an
> dictionary.


I don't find this compelling; you could make the same argument for any
optional argument.  When you only have a couple arguments, the additional
verbosity is a loss, particularly if the argument is used frequently.

When to use a dictionary is a judgement call, but it doesn't have anything
to do with the argument's type.

Naked bools are impossible to decipher without memorizing the call
> signature of every function.
>

Unless you're going to argue that *all* optional arguments should be moved
to dictionaries, this doesn't make sense--you always have to know the call
signature of functions you're calling.  That's no burden as long as you
don't have too many arguments (like init*Event).

-- 
Glenn Maynard

Re: [File API] Draft for Review

[Jonas Sicking]

On Thu, Jan 26, 2012 at 4:25 PM, Tab Atkins Jr.  wrote:
> On Thu, Jan 26, 2012 at 1:21 PM, Arun Ranganathan
>  wrote:
>> 2. URL.createObjectURL now takes an optional boolean, following discussions 
>> on the listserv [oneTimeOnly].
>
> As I argued in 
> ,
> we should absolutely *not* be adding more boolean arguments to the
> platform.  They should be exposed as boolean properties in an
> dictionary.  Naked bools are impossible to decipher without memorizing
> the call signature of every function.

I would be ok with that. We'll possibly want to add other optional
arguments anyway, like headers.

/ Jonas

Re: [File API] Draft for Review

[Tab Atkins Jr.]

On Thu, Jan 26, 2012 at 1:21 PM, Arun Ranganathan
 wrote:
> 2. URL.createObjectURL now takes an optional boolean, following discussions 
> on the listserv [oneTimeOnly].

As I argued in 
,
we should absolutely *not* be adding more boolean arguments to the
platform.  They should be exposed as boolean properties in an
dictionary.  Naked bools are impossible to decipher without memorizing
the call signature of every function.

~TJ

Re: [File API] Draft for Review

[Glenn Maynard]

On Thu, Jan 26, 2012 at 3:21 PM, Arun Ranganathan
wrote:

> 2. URL.createObjectURL now takes an optional boolean, following
> discussions on the listserv [oneTimeOnly].
>

These questions weren't addressed:
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1525.html

The only response to the above message was someone saying "interop for race
conditions isn't important", which is incorrect; the entire platform
carefully designs away the very possibility of race conditions wherever
possible.

-- 
Glenn Maynard

Re: Web Forms 2 Repetition Model?please reinstate on specification

[Ian Hickson]

On Fri, 23 Sep 2011, Matthew Slyman wrote:
> Quoting Ian Hickson :
> > 
> > We took it out because it was just far too complicated a solution to 
> > solve far too narrow a set of use cases.
> > 
> > However, there is a lot of ongoing work in this area of research, 
> > especially currently in the public-webapps@w3.org group. I encourage 
> > you to bring up the suggestion there. Unfortunately, coming up with a 
> > declarative solution whose cost-to-usefulness ratio is good enough has 
> > proven over the years to be a rather elusive goal.
> 
> I find this surprising. Unless of course you're trying to create a tool 
> to do everything (in which case you're diving head-first down a 
> rabbit-warren), or otherwise, have already tried that and decided it 
> doesn't work, and therefore decided that it's not worth attempting a 
> solution to any part of this problem.

The constraint is inventing technologies that have broad appeal. There is 
a tradeoff made in all technology development between the amount of effort 
required to develop and maintain the technology, and the return on 
investment -- in the case of Web technologies, the number of pages that 
will be able to make use of the feature.

For example, one could imagine that we could add to HTML a feature 
designed to help with the creation of model railway layout control tools. 
It would certainly be possible to develop a markup language for model 
trains -- one can imagine  elements and  element and 
 elements and  elements -- but the amount of work 
that would be needed to make such a feature would be disproportionate to 
the number of people who could make use of it.

On the other end of the scale, we have elements like , which are 
relatively cheap to design and implement, and yet apply to nearly every 
HTML page on the Web.

With templating features like the repetition model, we found that the cost 
of the feature was relatively high, and the number of pages that could 
actually make use of it was relatively small. A large number of other 
proposals have also been considered in this area, but most have a similar 
cost/benefit ratio.


> ===CONCLUSIONS===: We need a declarative solution for HTML repetition, 
> the same way Chemists need a declarative solution for repetition of 
> chemical formulae.

I don't think you'll find anyone who disagrees with this. The problem is 
coming up with a solution that is generic enough that it can be used for a 
large number of classes of repetition problems such that the benefit of 
the feature is not so small relative to the cost.

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

[File API] Draft for Review

[Arun Ranganathan]

Greetings public-webapps,

I'd like to encourage some review of File API: 

http://dev.w3.org/2006/webapi/FileAPI/  

You can send comments to this listserv, or file a bug, since this spec. now has 
a Bugzilla component.

Here are some notable changes:

1. Blob is now constructable, following discussions on the listserv [Blob].  
We're not using rest params and ES6 syntactic sugar *yet* (arrays for now), but 
I still think it one-ups BlobBuilder. 

2. URL.createObjectURL now takes an optional boolean, following discussions on 
the listserv [oneTimeOnly].

3. File's immutable "snapshot" nature means that it is prudent to specify 
correctly what happens following a post-reference modification; I'd like us to 
standardize NotReadableError (thrown as NotReadableError as DOMError following 
error event). [Snapshot]

4. Portions of the blob: protocol have been removed, following discussion on 
the listserv [Protocol1].

5. String length restrictions have been relaxed [Protocol2].

6. I'd like reader.readAsText(file) to be informed by the Encodings 
Specification [Enc].  I'll catch up with annevk about this separately, but I've 
changed the encoding algorithm to be neater.

7. readAsBinaryString has been disappeared [nukeRABS].

Please review the editor's draft at: http://dev.w3.org/2006/webapi/FileAPI/

-- A*

[Blob] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html
[oneTimeOnly] 
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1499.html
[Snapshot] 
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0177.html
[Protocol1] 
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1495.html
[Protocol2] 
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1496.html
[Enc] http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html
[nukeRABS] 
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1497.html

RE: StreamBuilder threshold

[Feras Moussa]

Can you please clarify what scenario you are looking at regarding multiple 
consumers?
When designing the StreamBuilder API, we looked at it as a more primitive API 
which other abstractions (such as multiple consumers) can be built upon. 

If you can please let me know what issue you're trying to address, I'm happy to 
discuss the possibilities.

Also, For future reference, the latest draft is now located on the W3 site at 
http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm

Thanks,
Feras

> -Original Message-
> From: Stefan Hakansson LK [mailto:stefan.lk.hakans...@ericsson.com]
> Sent: Tuesday, January 17, 2012 12:28 AM
> To: Feras Moussa; Travis Leithead
> Cc: public-webapps@w3.org
> Subject: StreamBuilder threshold
> 
> I'm looking at http://html5labs.interoperabilitybridges.com/streamsapi/,
> and specifically at the StreamBuilder.
> 
> It has the possibility to generate an event if the data available falls below 
> a
> threshold. How is this supposed to work if there is more than one consumer,
> and those consumers either don't start consuming at exactly the same time
> or consume at different rates, of the Stream?
> 
> --Stefan

RE: [indexeddb] Creating transactions inside the oncomplete handler of a VERSION_CHANGE transaction

[Israel Hilerio]

It sounds like we're all in sync with this new behavior.


These are the various ways in which I see a developer getting a handle to the 
database object in order to call transaction():

1. Keeping a global reference around after one of the open method handlers is 
executed (i.e. onupgradeneeded or onsuccess).

2. Accessing it directly from the onupgradeneeded handler

3. Accessing it directly from the onsuccess handler of the open method

The way I see a developer trying to call the transaction method when no 
VERSION_CHANGE transaction is executed is by doing #1 and closing the db before 
the call.
Are there other ways I missed?

In order to accommodate this situation, I believe we can change the text to say:

"If the transaction method is called before either the VERSION_CHANGE 
transaction is committed (i.e. the "complete"

event has *started* firing), or without a database connection being opened, we 
should throw a InvalidStateError."



Would this be enough?



Israel

On Thursday, January 26, 2012 9:26 AM, Joshua Bell wrote:
On Wed, Jan 25, 2012 at 11:32 PM, Jonas Sicking 
mailto:jo...@sicking.cc>> wrote:
On Wed, Jan 25, 2012 at 5:23 PM, Israel Hilerio 
mailto:isra...@microsoft.com>> wrote:
> On Wednesday, January 25, 2012 4:26 PM, Jonas Sicking wrote:
>> On Wed, Jan 25, 2012 at 3:40 PM, Israel Hilerio 
>> mailto:isra...@microsoft.com>>
>> wrote:
>> > Should we allow the creation of READ_ONLY or READ_WRITE transactions
>> inside the oncomplete event handler of a VERSION_CHANGE transaction?
>> > IE allows this behavior today.  However, we noticed that FF's nightly
>> doesn't.
>>
>> Yeah, it'd make sense to me to allow this.
>>
>> > In either case, we should define this behavior in the spec.
>>
>> Agreed. I can't even find anything in the spec that says that calling the
>> transaction() function should fail if you call it while the VERSION_CHANGE
>> transaction is still running.
>>
>> I think we should spec that if transaction() is called before either the
>> VERSION_CHANGE transaction is committed (i.e. the "complete" event has
>> *started* firing), or the "success" event has *started* firing on the
>> IDBRequest returned from .open, we should throw a InvalidStateError.
>>
>> Does this sound good?
>>
>> / Jonas
>
> Just to make sure we understood you correctly!
>
> We looked again at the spec and noticed that the IDBDatabase.transaction 
> method says the following:
> * This method must throw a DOMException of type InvalidStateError if called 
> before the success event for an open call has been dispatched.
Ah! There it is! I thought we had something but couldn't find it as I
was just looking at the exception table. That explains Firefox
behavior then.

> This implies that we're not allowed to open a new transaction inside the 
> oncomplete event handler of the VERSION_CHANGE transaction.
> From your statement above, it seems you agree with IE's behavior which 
> negates this statement.
Yup. Though given that the spec does in fact explicitly state a
behavior we should also get an ok from Google to change that behavior.

We're fine with this spec change for Chromium; we match the IE behavior 
already. (Many of our tests do database setup in the VERSION_CHANGE transaction 
and run the actual tests starting in its oncomplete callback, creating a fresh 
READ_WRITE transaction.)

> That implies we'll need to remove this line from the spec.
Well.. I'd say we need to change it rather than remove it.

> Also, we'll have to remove the last part of your proposed statement to 
> something like:
> If the transaction method is called before the VERSION_CHANGE transaction is 
> committed (i.e. the "complete" event has *started* firing), we should throw 
> an InvalidStateError exception.  Otherwise, the method returns an 
> IDBTransaction object representing the transaction returned by the steps 
> above.
We also need to say something about the situation when no
VERSION_CHANGE transaction is run at all though. That's why I had the
other part of the statement.

/ Jonas

Re: [indexeddb] Creating transactions inside the oncomplete handler of a VERSION_CHANGE transaction

[Joshua Bell]

On Wed, Jan 25, 2012 at 11:32 PM, Jonas Sicking  wrote:

> On Wed, Jan 25, 2012 at 5:23 PM, Israel Hilerio 
> wrote:
> > On Wednesday, January 25, 2012 4:26 PM, Jonas Sicking wrote:
> >> On Wed, Jan 25, 2012 at 3:40 PM, Israel Hilerio 
> >> wrote:
> >> > Should we allow the creation of READ_ONLY or READ_WRITE transactions
> >> inside the oncomplete event handler of a VERSION_CHANGE transaction?
> >> > IE allows this behavior today.  However, we noticed that FF's nightly
> >> doesn't.
> >>
> >> Yeah, it'd make sense to me to allow this.
> >>
> >> > In either case, we should define this behavior in the spec.
> >>
> >> Agreed. I can't even find anything in the spec that says that calling
> the
> >> transaction() function should fail if you call it while the
> VERSION_CHANGE
> >> transaction is still running.
> >>
> >> I think we should spec that if transaction() is called before either the
> >> VERSION_CHANGE transaction is committed (i.e. the "complete" event has
> >> *started* firing), or the "success" event has *started* firing on the
> >> IDBRequest returned from .open, we should throw a InvalidStateError.
> >>
> >> Does this sound good?
> >>
> >> / Jonas
> >
> > Just to make sure we understood you correctly!
> >
> > We looked again at the spec and noticed that the IDBDatabase.transaction
> method says the following:
> > * This method must throw a DOMException of type InvalidStateError if
> called before the success event for an open call has been dispatched.
>
> Ah! There it is! I thought we had something but couldn't find it as I
> was just looking at the exception table. That explains Firefox
> behavior then.
>
> > This implies that we're not allowed to open a new transaction inside the
> oncomplete event handler of the VERSION_CHANGE transaction.
> > From your statement above, it seems you agree with IE's behavior which
> negates this statement.
>
> Yup. Though given that the spec does in fact explicitly state a
> behavior we should also get an ok from Google to change that behavior.


We're fine with this spec change for Chromium; we match the IE behavior
already. (Many of our tests do database setup in the VERSION_CHANGE
transaction and run the actual tests starting in its oncomplete callback,
creating a fresh READ_WRITE transaction.)


> > That implies we'll need to remove this line from the spec.
>
> Well.. I'd say we need to change it rather than remove it.
>
> > Also, we'll have to remove the last part of your proposed statement to
> something like:
> > If the transaction method is called before the VERSION_CHANGE
> transaction is committed (i.e. the "complete" event has *started* firing),
> we should throw an InvalidStateError exception.  Otherwise, the method
> returns an IDBTransaction object representing the transaction returned by
> the steps above.
>
> We also need to say something about the situation when no
> VERSION_CHANGE transaction is run at all though. That's why I had the
> other part of the statement.
>
> / Jonas
>
>

[Bug 15732] New: Specify that non-editable content shouldn't be focusable

[bugzilla]

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

   Summary: Specify that non-editable content shouldn't be
focusable
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: HTML Editing APIs
AssignedTo: a...@aryeh.name
ReportedBy: a...@aryeh.name
 QAContact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org


data:text/html,

foo
bar
baz


It should be specified that you can't move the cursor into the word "bar". 
Browsers seem to already do this in this particular case, but I received a
report that not all of them do it in all cases.

(In the long run, this needs to be solved by specifying Selection.modify() and
requiring it to behave the same as various keystrokes.)

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: CfC: to add Speech API to Charter; deadline January 24

[Charles McCathieNevile]

On Wed, 25 Jan 2012 00:47:45 +0100, Glen Shires  wrote:


Art, Charles,
We are very pleased to see the positive responses to the CfC.


Me too. FWIW Opera is happy to have this work done. We think it would  
ideally be a joint deliverable (despite the fact that we don't like those  
in general) between WebApps (where there is a lot of expertise in design  
of web APIs, plus a lot of the relevant players) and the Voice group where  
there is a lot of specific expertise, unless we can get all the relevant  
people to join one or other of those groups.


In particular, we believe this meets all the criteria that Art suggested  
in [1].


There is the outstanding question of Apple's position...


What is the next step for adding this to the charter"?


Wait for me to propose a new draft charter. As it happens, I am waiting on  
Google people (Ian Fette is the named target because he brought the  
initial proposal) to explain their IME proposal better, but I intend to  
draft a charter in the next week with whatever we have agreed as a group  
to add, and start it along the approval process (it has to be agreed by  
the W3C membership as a whole).


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com