[clipops] still not clear about event loop

[Anne van Kesteren]

I think I still have outstanding comments on this specification, but
I'll raise this one again. It's not at all clear how this
specification interacts with the event loop. E.g. pasting is clearly
an operation that queues a task to dispatch the event, but does
inserting the data happen in the same task, what about the events this
causes to be dispatched?

Seems there is some kind of desire for an afterpaste event too:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19414


-- 
http://annevankesteren.nl/

Re: IndexedDB: undefined parameters

[Boris Zbarsky]

On 10/11/12 1:43 AM, Jonas Sicking wrote:

I agree that it's not explicitly the same thing as what we have here.
But I think the general idea is "for optional arguments, treat
'undefined' as if a value wasn't passed at all".


OK.  I can live with that, as long as everyone else gets on that page too.


Note that openCursor, which I think is where this thread started, does NOT
define default values for its arguments.  Should it?


Probably yes. I think explicitly making 'null' the default value would
clear things up.


That would help, yes.  As would defining null and undefined explicitly 
to be missing key values.



(As a side note, the IDL for openCursor is not valid WebIDL, because "any?"
is not a valid WebIDL type.)


That sounds like a WebIDL bug.


It's a bug in the IDL for openCursor, since "any" already allows null as 
a value so "any?" is nonsensical just like "Node??" would be nonsensical.


-Boris

Re: IndexedDB: undefined parameters

[Jonas Sicking]

On Wed, Oct 10, 2012 at 7:15 PM, Brendan Eich  wrote:
> Boris Zbarsky wrote:
>>
>> Should "undefined", when provided for a dictionary entry, also be treated
>> as "not present"?  That is, should passing a dictionary like so:
>>
>>   { a: undefined }
>>
>> be equivalent to passing a dictionary that does not contain "a" at all?
>
> ES6 says no. That's a bridge too far. Parameter lists are not objects!

I thought the idea was that for something like:

function f({ a = 42 }) {
  console.log(a);
}
obj = {};
f({ a: obj.prop });

that that would log 42.

What is the reason for making this different from:

function f(a = 42) {
  console.log(a);
}
obj = {};
f(obj.prop);

It seems to me that the same "it'll do the right thing in all
practical contexts" argument applied equally to both cases?

I might very well be missing something though?

/ Jonas

Re: IndexedDB: undefined parameters

[Jonas Sicking]

On Wed, Oct 10, 2012 at 7:03 PM, Boris Zbarsky  wrote:
> On 10/10/12 9:55 PM, Brendan Eich wrote:
>>
>> undefined is the one value that acts as the default-triggering sentinel,
>
>
> ...
>
>
>>> Think about all this from the point of view of an ES impl of foo()
>>> above.  How would you represent, in an ES function that expects its
>>> first argument to be an int and the second argument to be an int but
>>> makes them optional, the concept of "second int passed, but first not
>>> passed"?  However you'd do that, that's probably what WebIDL should
>>> aim for.
>>
>>
>> undefined as first actual, int as second.
>
>
> OK, so it sounds like there are two proposals for changes to WebIDL here:
>
> 1)  If undefined is passed for an optional value that has a default value,
> the default value should be used.

I think we should do this in order to align with ES6.

> 2)  If undefined is passed for an optional value that does NOT have a
> default value, the value should be considered as "not present" (similar to
> the equivalent concept for dictionaries).

I think we should do this in order to align with what I'd say is the
spirit of ES6.

The reason for making 'undefined' get the default value is that it
makes expressions like:

foo(obj.prop);

not have to be written as:

if ("prop" in obj) {
  foo(obj.prop);
}
else {
  foo();
}

In order to keep with that goal we should for these purposes also
treat undefined as "not passed".

/ Jonas

Re: IndexedDB: undefined parameters

[Jonas Sicking]

On Wed, Oct 10, 2012 at 6:12 PM, Boris Zbarsky  wrote:
> On 10/10/12 6:51 PM, Jonas Sicking wrote:
>>
>> FWIW, ES6 is going to treat the undefined value as "not passing a
>> parameter" when it comes to functions that have default values.
>
>
> When there are default values, yes.  But what about cases when there are no
> default values?

I agree that it's not explicitly the same thing as what we have here.
But I think the general idea is "for optional arguments, treat
'undefined' as if a value wasn't passed at all".

> Note that openCursor, which I think is where this thread started, does NOT
> define default values for its arguments.  Should it?

Probably yes. I think explicitly making 'null' the default value would
clear things up.

> (As a side note, the IDL for openCursor is not valid WebIDL, because "any?"
> is not a valid WebIDL type.)

That sounds like a WebIDL bug.

>> In anticipation of ES6 formally defining this, WebIDL has already
>> switched to this
>
> It certainly hasn't so far, though I agree it may be a good idea to do this.

Yeah. It seems like I'm misremembering. We need to get WebIDL updated here.

/ Jonas

Re: IndexedDB: undefined parameters

[Cameron McCormack]

Rick Waldron:

Explicit undefined will trigger default values. (see:
https://mail.mozilla.org/pipermail/es-discuss/2012-July/024207.html)


Great, thanks for the pointer.

Re: IndexedDB: undefined parameters

[Rick Waldron]

On Wed, Oct 10, 2012 at 11:32 PM, Cameron McCormack  wrote:

> Joshua Bell:
>
>> To match ES6 semantics (which I think everyone on this thread agrees is a
>>> Good Thing), then the above paragraph is redundant (and the overload
>>> resolution algorithm step 4 can be simplified?).
>>>
>>
> Jonas Sicking:
>
>> Indeed. I had read that as only applying to DOMString arguments, but
>> on rereading I agree that that's probably not the right
>> interpretation.
>>
>> So yes, I think the WebIDL spec is out-of-date here. I can't actually
>> find where it defines that undefined is treated as "was not passed".
>> I'm not sure if this is an oversight or if this isn't agreed upon
>> behavior. I was under the impression that it was, but I could be
>> wrong.
>>
>
> Trailing undefineds are treated as "not passed" in the overload resolution
> algorithm (step 4).  There is still a note just below the overload
> resolution algorithm mentioning the fact that ES6 might have been going to
> change to treat all explicit undefined values as missing.  Has the ES6
> change been made?
>


Explicit undefined will trigger default values. (see:
https://mail.mozilla.org/pipermail/es-discuss/2012-July/024207.html)

Rick

Re: IndexedDB: undefined parameters

[Cameron McCormack]

Cameron McCormack:

Trailing undefineds are treated as "not passed" in the overload
resolution algorithm (step 4).


Boris Zbarsky:

Only if explicit [TreatUndefinedAs=Missing] is being used, no?


Yes.  If we do as the note says, IIUC, it would mean that
[TreatUndefinedAs=Missing] would be normal behaviour, and that explicit
undefined values even in the middle of a list of actual arguments would
get treated as the argument's default value, if it has one.  Is that right?

Re: IndexedDB: undefined parameters

[Boris Zbarsky]

On 10/10/12 11:32 PM, Cameron McCormack wrote:

Trailing undefineds are treated as "not passed" in the overload
resolution algorithm (step 4).


Only if explicit [TreatUndefinedAs=Missing] is being used, no?

-Boris

Re: IndexedDB: undefined parameters

[Cameron McCormack]

Joshua Bell:

To match ES6 semantics (which I think everyone on this thread agrees is a
Good Thing), then the above paragraph is redundant (and the overload
resolution algorithm step 4 can be simplified?).


Jonas Sicking:

Indeed. I had read that as only applying to DOMString arguments, but
on rereading I agree that that's probably not the right
interpretation.

So yes, I think the WebIDL spec is out-of-date here. I can't actually
find where it defines that undefined is treated as "was not passed".
I'm not sure if this is an oversight or if this isn't agreed upon
behavior. I was under the impression that it was, but I could be
wrong.


Trailing undefineds are treated as "not passed" in the overload 
resolution algorithm (step 4).  There is still a note just below the 
overload resolution algorithm mentioning the fact that ES6 might have 
been going to change to treat all explicit undefined values as missing. 
 Has the ES6 change been made?

Re: IndexedDB: undefined parameters

[Boris Zbarsky]

On 10/10/12 10:15 PM, Brendan Eich wrote:

Boris Zbarsky wrote:

Should "undefined", when provided for a dictionary entry, also be
treated as "not present"?  That is, should passing a dictionary like so:

  { a: undefined }

be equivalent to passing a dictionary that does not contain "a" at all?


ES6 says no. That's a bridge too far. Parameter lists are not objects!


Well, the thing is, dictionaries can have default values.  So given this 
IDL:


  dictionary Dict {
long a = 2;
  };
  void foo(Dict arg);

and then a call like so:

  foo({ a: undefined });

should the callee see the value of "a" as 2 or 0?

Note that this is not quite the same question as this one:

Given this IDL:

  dictionary Dict {
long a;
  };
  void foo(Dict arg);

and then a call like so:

  foo({ a: undefined });

should the callee see the value of "a" as 0 or "nor present"?

Right now WebIDL says "0" for both of these cases.  I'm fine with that, 
generally; just wanted to make sure that was what we really wanted.


-Boris

Re: IndexedDB: undefined parameters

[Brendan Eich]

Boris Zbarsky wrote:
Should "undefined", when provided for a dictionary entry, also be 
treated as "not present"?  That is, should passing a dictionary like so:


  { a: undefined }

be equivalent to passing a dictionary that does not contain "a" at all?


ES6 says no. That's a bridge too far. Parameter lists are not objects!

/be

Re: IndexedDB: undefined parameters

[Boris Zbarsky]

On 10/10/12 9:55 PM, Brendan Eich wrote:

undefined is the one value that acts as the default-triggering sentinel,


...


Think about all this from the point of view of an ES impl of foo()
above.  How would you represent, in an ES function that expects its
first argument to be an int and the second argument to be an int but
makes them optional, the concept of "second int passed, but first not
passed"?  However you'd do that, that's probably what WebIDL should
aim for.


undefined as first actual, int as second.


OK, so it sounds like there are two proposals for changes to WebIDL here:

1)  If undefined is passed for an optional value that has a default 
value, the default value should be used.


2)  If undefined is passed for an optional value that does NOT have a 
default value, the value should be considered as "not present" (similar 
to the equivalent concept for dictionaries).


Should "undefined", when provided for a dictionary entry, also be 
treated as "not present"?  That is, should passing a dictionary like so:


  { a: undefined }

be equivalent to passing a dictionary that does not contain "a" at all?

How should #2 above interact with the overload resolution algorithm?  Or 
does it not affect it at all?


-Boris

Re: IndexedDB: undefined parameters

[Brendan Eich]

Boris Zbarsky wrote:
In fact, WebIDL doesn't even do what you want here with 
[TreatUndefinedAs=Missing].  All that does is that if it's present on 
an argument and all arguments after it, and if all the values passed 
for all those arguments are undefined, then the effective overload 
used is the one with all those arguments omitted.  So if you have this 
IDL:


  void foo([TreatUndefinedAs=Missing] optional int foo,
   [TreatUndefinedAs=Missing] optional int bar);

and you make this call:

  foo(undefined, 5)

this will behave the same as foo(0, 5).

Basically, TreatUndefinedAs=Missing is meant to let you pretend like 
trailing undefined values don't affect arguments.length, in ES terms.


This is all consistent with draft ES6, per Ecma TC39 and its Editor, @awbjs.

http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts

undefined is the one value that acts as the default-triggering sentinel, 
whether trailing or not. This supports composition by delegation, where 
f(a,b,c) and f calls g(a,b,c) and g has default parameters triggers 
defaulting no matter how many or few actual arguments f receives -- 
without f having to specialize on arguments.length and call g with 0, 1, 
or 2 actuals.


Think about all this from the point of view of an ES impl of foo() 
above.  How would you represent, in an ES function that expects its 
first argument to be an int and the second argument to be an int but 
makes them optional, the concept of "second int passed, but first not 
passed"?  However you'd do that, that's probably what WebIDL should 
aim for.


undefined as first actual, int as second.

ccing public-script-coord here, because it seems like there's some 
serious lack of clarity about what WebIDL does now and what behavior 
people want out of it.


ES6 draft on default parameters is now clear.

/be

Re: IndexedDB: undefined parameters

[Boris Zbarsky]

On 10/10/12 9:12 PM, Boris Zbarsky wrote:

Note that all this affects openCursor and the like only tangentially,
because those take an "any" type and hence have to do type introspection
anyway.


And in particular, "any" can represent undefined directly, so the callee 
can simply look to see whether undefined was passed.


-Boris

Re: IndexedDB: undefined parameters

[Boris Zbarsky]

On 10/10/12 6:51 PM, Jonas Sicking wrote:

FWIW, ES6 is going to treat the undefined value as "not passing a
parameter" when it comes to functions that have default values.


When there are default values, yes.  But what about cases when there are 
no default values?


Note that openCursor, which I think is where this thread started, does 
NOT define default values for its arguments.  Should it?


(As a side note, the IDL for openCursor is not valid WebIDL, because 
"any?" is not a valid WebIDL type.)



In anticipation of ES6 formally defining this, WebIDL has already
switched to this


It certainly hasn't so far, though I agree it may be a good idea to do this.

In fact, WebIDL doesn't even do what you want here with 
[TreatUndefinedAs=Missing].  All that does is that if it's present on an 
argument and all arguments after it, and if all the values passed for 
all those arguments are undefined, then the effective overload used is 
the one with all those arguments omitted.  So if you have this IDL:


  void foo([TreatUndefinedAs=Missing] optional int foo,
   [TreatUndefinedAs=Missing] optional int bar);

and you make this call:

  foo(undefined, 5)

this will behave the same as foo(0, 5).

Basically, TreatUndefinedAs=Missing is meant to let you pretend like 
trailing undefined values don't affect arguments.length, in ES terms.


Think about all this from the point of view of an ES impl of foo() 
above.  How would you represent, in an ES function that expects its 
first argument to be an int and the second argument to be an int but 
makes them optional, the concept of "second int passed, but first not 
passed"?  However you'd do that, that's probably what WebIDL should aim for.


ccing public-script-coord here, because it seems like there's some 
serious lack of clarity about what WebIDL does now and what behavior 
people want out of it.


Note that all this affects openCursor and the like only tangentially, 
because those take an "any" type and hence have to do type introspection 
anyway.  They can define whatever behavior is desired for null or 
undefined or whatnot.



As for null, the intent was that 'null' would be interpreted as 'not
defined' and thus the same as undefined. Though this isn't very clear
in the spec.


It's not just not clear, it's not present at all, as far as I can tell.

-Boris

[Bug 18796] HTTP 204 not specified

[bugzilla]

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

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution|--- |INVALID

--- Comment #2 from Ian 'Hixie' Hickson  ---
Failing the connection is exactly what 204 does, which is what the intro
section says it does... I don't understand the problem here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: IndexedDB: undefined parameters

[Jonas Sicking]

On Wed, Oct 10, 2012 at 4:10 PM, Joshua Bell  wrote:
> On Wed, Oct 10, 2012 at 3:58 PM, Jonas Sicking  wrote:
>>
>> On Wed, Oct 10, 2012 at 11:15 AM, Odin Hørthe Omdal 
>> wrote:
>> > Last time I looked at it, WebIDL said [TreatUndefinedAs=Missing] is
>> > meant to
>> > be for legacy API's, and not new ones. I think that a bit strange and
>> > counter productive. Why?
>>
>> [TreatUndefinedAs] is only intended for arguments that take DOMString
>> or DOMString?.
>>
>> http://dev.w3.org/2006/webapi/WebIDL/#TreatUndefinedAs
>
>
> I think we're confused by the following text at the above link (a couple
> paragraphs down), which contrasts with the first use case (DOMString):
>
>> The second use for [TreatUndefinedAs] is to control how undefined values
>> passed to a function corresponding to an operation are treated. If it is
>> specified as[TreatUndefinedAs=Missing] on an optional operation argument,
>> then an explicit undefined value will cause the function call to be treated
>> as if the argument had been omitted.
>
>
> To match ES6 semantics (which I think everyone on this thread agrees is a
> Good Thing), then the above paragraph is redundant (and the overload
> resolution algorithm step 4 can be simplified?).

Indeed. I had read that as only applying to DOMString arguments, but
on rereading I agree that that's probably not the right
interpretation.

So yes, I think the WebIDL spec is out-of-date here. I can't actually
find where it defines that undefined is treated as "was not passed".
I'm not sure if this is an oversight or if this isn't agreed upon
behavior. I was under the impression that it was, but I could be
wrong.

/ Jonas

Re: IndexedDB: undefined parameters

[Joshua Bell]

On Wed, Oct 10, 2012 at 3:58 PM, Jonas Sicking  wrote:

> On Wed, Oct 10, 2012 at 11:15 AM, Odin Hørthe Omdal 
> wrote:
> > Last time I looked at it, WebIDL said [TreatUndefinedAs=Missing] is
> meant to
> > be for legacy API's, and not new ones. I think that a bit strange and
> > counter productive. Why?
>
> [TreatUndefinedAs] is only intended for arguments that take DOMString
> or DOMString?.
>
> http://dev.w3.org/2006/webapi/WebIDL/#TreatUndefinedAs


I think we're confused by the following text at the above link (a couple
paragraphs down), which contrasts with the first use case (DOMString):

The second use for [TreatUndefinedAs] is to control how undefined values
> passed to a function corresponding to an operation are treated. If it is
> specified as[TreatUndefinedAs=Missing] on an optional operation argument,
> then an explicit undefined value will cause the function call to be treated
> as if the argument had been omitted.


If this behavior should indeed be the default to match ES6 semantics (which
I think practically everyone on this thread agrees is a Good Thing), then
the above paragraph is redundant and the overload resolution algorithm step
4 can be simplified.

Re: [Server-Sent Events] Infinite reconnection clarification

[Ian Hickson]

FYI, I've updated the EventSource spec to do reconnection in the case of 
certain 5xx errors, DNS errors, and connection failures, as per a thread 
earlier this year.

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

Re: IndexedDB: undefined parameters

[Jonas Sicking]

On Wed, Oct 10, 2012 at 11:15 AM, Odin Hørthe Omdal  wrote:
> Last time I looked at it, WebIDL said [TreatUndefinedAs=Missing] is meant to
> be for legacy API's, and not new ones. I think that a bit strange and
> counter productive. Why?

[TreatUndefinedAs] is only intended for arguments that take DOMString
or DOMString?.

http://dev.w3.org/2006/webapi/WebIDL/#TreatUndefinedAs

/ Jonas

[Bug 15495] Update EventSource model to do automatic reconnect even in the face of network errors

[bugzilla]

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

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: IndexedDB: undefined parameters

[Jonas Sicking]

On Tue, Oct 9, 2012 at 3:04 PM, Robert Ginda  wrote:
> On Tue, Oct 9, 2012 at 2:51 PM, Alec Flett  wrote:
>>
>>
>>
>> On Tue, Oct 9, 2012 at 11:37 AM, Alec Flett 
>> wrote:
>>>
>>>
>>>
>>> On Tue, Oct 9, 2012 at 11:12 AM, Boris Zbarsky  wrote:

 On 10/9/12 1:52 PM, Joshua Bell wrote:
>
> The IDB spec does not have [TreatUndefinedAs=Missing] specified on
> openCursor()'s arguments (or anywhere else), so I believe Chrome's
> behavior here is correct.


 It looks correct as the spec is currently written.

 It's not clear to me why the spec is written the way it is.  It could
 just as easily define that if the "any" value is undefined, it's ignored.
 Or it could use [TreatUndefinedAs=Missing], indeed.
>>>
>>>
>>> I have to say, as a developer it can be really frustrating to write
>>> abstractions on top of APIs that behave this way, when you want to say
>>> something like:
>>
>>
>> Someone asked me to clarify: by "this way" I meant "where passing
>> undefined is different than calling without the parameter" - meaning that in
>> general, APIs should behave the same if you call foo(undefined) as if you
>> called foo(). Otherwise it's notoriously hard to write anything functional
>> (in the CS sense) around it.
>>
>
> I completely agree here.  But I never, ever use the symbol-known-as
> "undefined" in script, since it's actually a write-able variable.  I'd
> suggest also treating null as missing if possible.

FWIW, ES6 is going to treat the undefined value as "not passing a
parameter" when it comes to functions that have default values. So all
of the following functions will log 42:

function f1(a = 42) {
   console.log(a);
}
function f2({ a = 42 }) {
  console.log(a);
}
f1();
f1(undefined);
f2();
f2({});
f2({ a: undefined });

In anticipation of ES6 formally defining this, WebIDL has already
switched to this and so the IndexedDB spec actually already defines
that passing 'undefined' as the first argument to openCursor should
behave the same as not passing a first argument at all.

As for null, the intent was that 'null' would be interpreted as 'not
defined' and thus the same as undefined. Though this isn't very clear
in the spec.

/ Jonas

[Bug 19450] New: [IndexedDB] Key path segments should permit reserved words

[bugzilla]

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

  Priority: P2
Bug ID: 19450
CC: m...@w3.org, public-webapps@w3.org
  Assignee: dave.n...@w3.org
   Summary: [IndexedDB] Key path segments should permit reserved
words
QA Contact: public-webapps-bugzi...@w3.org
  Severity: minor
Classification: Unclassified
OS: All
  Reporter: jsb...@chromium.org
  Hardware: All
Status: NEW
   Version: unspecified
 Component: Indexed Database API
   Product: WebAppsWG

In the IDB spec the definition of a valid key path is built around:

A DOMString containing a JavaScript identifier [ECMA-262].

... plus dotted combinations of identifiers and arrays thereof.

ECMA-262 gives:

Identifier ::
  IdentifierName but not ReservedWord

IdentifierName ::
  IdentifierStart
  IdentifierName IdentifierPart
(etc)

And defines ReservedWord as:

ReservedWord ::
  Keyword
  FutureReservedWord
  NullLiteral
  BooleanLiteral

Keyword :: one of
  break do instanceof typeof case else new var ...
(etc)

This would appear to preclude key paths such as:

"foo.delete.bar"
"my.public.data"
"response.true.details"
"options.null"

Neither FF nor Chrome appear to reject such key paths.

I suggest the IDB spec be updated to refer specifically to the IdentifierName
production in ECMA-262.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: IndexedDB: undefined parameters

[Odin Hørthe Omdal]

On Tue, 09 Oct 2012 19:52:27 +0200, Joshua Bell   
wrote:
We were looking at Opera's w3c-test submissions, and noticed that  
several of them use a pattern like:


request = index.openCursor(undefined, 'prev');

or:

opts = {};
request = index.openCursor(opts.range, opts.direction);

In Chrome, these throw DataError per our interpretation of the spec: "If  
the range parameter is specified but is not a valid key or a key range,  
this method throws a DOMException of type DataError." [1]


Yes. You are correct.

Some of the first tests I wrote had that pattern, and since the testcases  
came before the implementation, the implementation followed the testcases  
:P  Firefox, which I used to sanity check at the time I wrote them,  
allowed it (and still do).


I did check and change a few other tests that I wrote more recently when  
checked up against IE10 (and now Chromium), but I didn't go through older  
ones.


The tests are meant to follow the spec so they should be fixed. :-)



But I am quite convinced that not having TreatUndefinedAs=Missing is a  
painful API design though, for just the reasons others have brought up in  
this thread.


I have written one like that for open. In supports.js, there is something  
like


# function createdb(name, version) {
#   if (!name) name = generate_name()
#
#   if (!version) return indexedDB.open(name)
#   else return indexedDB.open(name, version)
# }

Where that last if-tests feel very redundant.

Last time I looked at it, WebIDL said [TreatUndefinedAs=Missing] is meant  
to be for legacy API's, and not new ones. I think that a bit strange and  
counter productive. Why?


--
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com

Re: Proposal to add USB keycodes to the current DOM3 key events

[Mounir Lamouri]

On 09/06/2012 11:58 PM, Gary Kacmarcik (Кошмарчик) wrote:
> Hi all,
> 
> I've written up a brief proposal to enhance the current DOM Level 3
> key events by adding USB keycodes.
> 
> Here is a link to the proposal document:
> https://docs.google.com/document/d/1eJvlUaTBsWa71hIc0X4s6SrCopX9LCPs1YOAuVluxBs/edit

Given that the proposal is about modifying DOM Level 3 Events, I have
replied (with a counter-proposal) to the thread that has been created in
that mailing-list.

If you are interested:
http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0030.html

To avoid cross-posting, I think the discussion should happen in www-dom.

Cheers,
--
Mounir

RE: IndexedDB: undefined parameters

[Aaron Powell]

I believe it was part of the ES5 changes that brought this in, testing in both 
Chrome (23) and IE 10 with the following code snippet:

var bar = function () {
undefined = 42;

var foo;

console.assert(foo == undefined);
}

bar();

That will always return true, meaning that undefined wasn't modified. This 
means that it's safe to assume that undefined is undefined when passed into the 
IDB API (as all browsers supporting IDB already implement ES5).

Aaron Powell
MVP - Internet Explorer (Development) | FunnelWeb Team 
Member

http://apowell.me | http://twitter.com/slace | Skype: 
aaron.l.powell | Github | 
BitBucket

From: rgi...@google.com [mailto:rgi...@google.com] On Behalf Of Robert Ginda
Sent: Wednesday, 10 October 2012 9:19 AM
To: Boris Zbarsky
Cc: Alec Flett; public-webapps
Subject: Re: IndexedDB: undefined parameters

On Tue, Oct 9, 2012 at 3:11 PM, Boris Zbarsky 
mailto:bzbar...@mit.edu>> wrote:
On 10/9/12 6:04 PM, Robert Ginda wrote:
But I never, ever use the symbol-known-as
"undefined" in script, since it's actually a write-able variable.

For what it's worth, it's not anymore.  It used to be, but current ES makes it 
a readonly non-configurable property of the global.  Not sure to what extent 
UAs have caught up with the spec on that.

Oh, I wasn't aware of that.  I'd still avoid using undefined values to mean "I 
intentionally don't want to provide a value".  Null is more trustworthy for 
that, because it's not going to show up "on accident".  In my own private 
coding guidelines in my head, I only *test* for undefined.  It only appears as 
an rvalue in very rare cases, and when it does it appears as "(void 0)".

Of course in cases like this:

  function foo(undefined) {
// Code using "undefined" here loses
  }

you still have a problem

I'd suggest also treating null as missing if possible.

In general, or for the specific IDB case?

Well my own personal opinion would be in general, but I don't know what kind of 
repercussions that would have on other specifications and implementations.


Rob.



-Boris

RE: IndexedDB: undefined parameters

[Aaron Powell]

I'll agree that it is a bit on the confusing side, I'm pretty sure that there's 
a point in the spec that it indicates that 'null' is how to represent a not 
provided key but supporting 'undefined' would make it simpler to work with the 
API. The problem I can see with that is there are several shipped 
implementations of the spec that this would break for (if I recall correctly 
IE10 will raise a DataError on undefined but not null).

Aaron Powell
MVP - Internet Explorer (Development) | FunnelWeb Team 
Member

http://apowell.me | http://twitter.com/slace | Skype: 
aaron.l.powell | Github | 
BitBucket

From: alecfl...@google.com [mailto:alecfl...@google.com] On Behalf Of Alec Flett
Sent: Wednesday, 10 October 2012 8:52 AM
To: Boris Zbarsky
Cc: public-webapps@w3.org
Subject: Re: IndexedDB: undefined parameters


On Tue, Oct 9, 2012 at 11:37 AM, Alec Flett 
mailto:alecfl...@chromium.org>> wrote:

On Tue, Oct 9, 2012 at 11:12 AM, Boris Zbarsky 
mailto:bzbar...@mit.edu>> wrote:
On 10/9/12 1:52 PM, Joshua Bell wrote:
The IDB spec does not have [TreatUndefinedAs=Missing] specified on
openCursor()'s arguments (or anywhere else), so I believe Chrome's
behavior here is correct.

It looks correct as the spec is currently written.

It's not clear to me why the spec is written the way it is.  It could just as 
easily define that if the "any" value is undefined, it's ignored.  Or it could 
use [TreatUndefinedAs=Missing], indeed.

I have to say, as a developer it can be really frustrating to write 
abstractions on top of APIs that behave this way, when you want to say 
something like:

Someone asked me to clarify: by "this way" I meant "where passing undefined is 
different than calling without the parameter" - meaning that in general, APIs 
should behave the same if you call foo(undefined) as if you called foo(). 
Otherwise it's notoriously hard to write anything functional (in the CS sense) 
around it.

Alec


var direction;
var range;

if (condition1)
   direction = 'prev';
else if (condition2)
   direction = 'prevuniq';

if (condition3) {
  range = range1;
else if (condition4)
  range = range2;

return source.openCursor(range, direction);

Alec

[Bug 16304] DONE != DONE

[bugzilla]

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

Glenn Adams  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #7 from Glenn Adams  ---
(In reply to comment #6)
> That note is misleading. Those events will be dispatched precisely because
> all is DONE. readystatechange is just one of the things signaling that,
> don't attach too much meaning to its name.

That's just the problem. I do attach a meaning to its name. DONE. And since,
there are events delivered in this state, it doesn't really seem like DONE, it
seems like ALMOST_DONE. I'm sure you can craft a simple note that addresses my
concern and satisfies your intention. Try harder. If you don't wish to do so,
I'll propose another version of the note. But it seems like it's in your court
to propose a counter-proposal, and not simply reject my request.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: IndexedDB: undefined parameters

[João Eiras]

On Tue, 09 Oct 2012 20:37:36 +0200, Alec Flett   
wrote:



On Tue, Oct 9, 2012 at 11:12 AM, Boris Zbarsky  wrote:


On 10/9/12 1:52 PM, Joshua Bell wrote:


The IDB spec does not have [TreatUndefinedAs=Missing] specified on
openCursor()'s arguments (or anywhere else), so I believe Chrome's
behavior here is correct.



It looks correct as the spec is currently written.

It's not clear to me why the spec is written the way it is.  It could  
just
as easily define that if the "any" value is undefined, it's ignored.   
Or it

could use [TreatUndefinedAs=Missing], indeed.



I have to say, as a developer it can be really frustrating to write
abstractions on top of APIs that behave this way, when you want to say
something like:

var direction;
 var range;

if (condition1)
   direction = 'prev';
else if (condition2)
   direction = 'prevuniq';

if (condition3) {
  range = range1;
else if (condition4)
  range = range2;

return source.openCursor(range, direction);



According to the issue here, it would have to be written as

$ if (range && direction) return source.openCursor(range, direction);
$ else if(range) return source.openCursor(range);
$ else return source.openCursor(range);

which is a bit annoying, specially if the parameters are being already  
passed to a wrapper function, e.g.:


$ function open_cursor(range){
$  return os.openCursor(range, 'next');
$ }
$ open_cursor();