Re: [DOM4] Remove Node.isSameNode
On Thu, Sep 15, 2011 at 12:33 AM, Anne van Kesteren wrote: > On Fri, 09 Sep 2011 19:21:53 +0200, Jonas Sicking wrote: >> >> It's a completely useless function. It just implements the equality >> operator. I believe most languages have a equality operator already. >> Except Brainfuck [1]. But the DOM isn't implementable in Brainfuck >> anyway as it doesn't have objects, so I'm ok with that. > > If you can get this removed from Gecko without it causing compatibility > issues consider it gone from the specification. I'm all for less methods, > especially useless methods. Done: https://bugzilla.mozilla.org/show_bug.cgi?id=687400 (Patch landed, bug will get marked FIXED in a day or so) / Jonas
Re: [DOM4] atomicity of DocumentFragment insertion
On Fri, Oct 28, 2011 at 2:47 PM, David Flanagan wrote:
> I think the DOM4 spec should be clearer about the atomicity (or
> non-atomicity) of DocumentFragment insertion. I assume that when a
> DocumentFragment is inserted, scripts should never be able to observe the
> document in state where some of the children of the fragment have been
> inserted and others have not. But I don't think the spec currently states
> that anywhere, and I think it should.
>
> This may be an issue for mutation events, and it also turns out to be an
> issue for HTML script tags, which execute when children are inserted. For
> example, what is the proper behavior of this code?:
>
> // s and f are global variables
> s = document.createElement("script");
> document.head.appendChild(s);
> f = document.createDocumentFragment();
> f.appendChild(document.createTextNode("alert(s.text);
> alert(f.childNodes.length);"));
> f.appendChild(document.createTextNode("alert(2);"));
> f.appendChild(document.createTextNode("alert(3);"));
> s.appendChild(f);
> alert(s.text);
>
> Firefox runs the code in all 3 text nodes and displays 5 alerts total. The
> first and last alerts both contain the concatenated text of all three text
> nodes. The second alert display 0 because there are no children left in the
> document fragment.
>
> But Chrome, Safari and Opera run only the code in the first text node and
> display 3 alerts. The first alert displays only the first text node, the
> second alert displays 2 because one child has been moved from the fragment
> into the script, and the third alert displays all 3 text nodes.
>
> So, Firefox inserts the DocumentFragment atomically and the other browsers
> (I don't have a Windows installation to test IE) insert it non-atomically
> and allow the document to be observed in a partially inserted state.
>
> I've raised this issue (with a slightly simpler example) on the whatwg.org
> list:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-October/033705.html
> but I suspect that DOM4 might actually be the right place to fix it.
>
> The DOM4 spec should either adopt language like "the document is never
> observable in a partially-inserted state" or it should simply define
> operations on document fragments using recursion so that it is clear that
> calling appendChild on a document fragment is exactly the same as
> sequentially calling appendChild on its children.
(cc'ing webapps as that's the proper list to discuss the DOM. Yes,
it's confusing).
This is very intentional behavior from Firefox side. Being able to
observe a partial insertion here creates all sorts of strange edge
cases. For example where do you insert nodes a fragment is
.insertBefore'ed and a "callback" rips out all inserted nodes as well
as any immediately surrounding nodes and insert them somewhere else in
the tree?
And what do you do if the callback adds or removes nodes in the
fragment when the fragment is half-way inserted.
It also requires defining things like are nodes inserted front-to-back
or back-to-front. And are they removed from the fragment one at a time
or all at once. Defining these cases might prevent implementations
from performing these operations in whatever order is the fastest for
them.
/ Jonas
[Bug 14592] New: EventSource should default to use "Use Credentials" set to false for CORS
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14592
Summary: EventSource should default to use "Use Credentials"
set to false for CORS
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Server-Sent Events (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: jo...@sicking.cc
QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org
In order to default to a more safe mode of operation EventSource should default
to not sending credentials in cross-origin requests. This also has the
advantage that it matches how XMLHttpRequest works.
In order to opt-in to using credentials a constructor argument should be used.
Something like the following WebIDL:
dictionary EventSourceInit {
boolean withCredentials = false;
}
[Constructor(DOMString url, optional EventSourceInit optParams)]
interface EventSource : EventTarget {
...
readonly boolean withCredentials;
...
};
This also matches the conclusion we came to during the mozilla security review
and is thus the solution we're for now planning on deploying (prefixed for now
of course).
--
Configure bugmail: http://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: A proposal for Element constructors
On Thu, Oct 27, 2011 at 12:35 AM, Kentaro Hara wrote:
>
> ...
> John-David wrote:
> > Something like Element('') is so so soo nice compared with more
> > verbose alternatives and you can still add attributes to elements via
> > a second argument. I know some prefer smth like Element('div#foo') ->
> > but that get's ugly when trying to expand that
> > syntax to an element's children.
>
> In terms of syntax sugar, I agree that Element constructors may lose
> Element.create("button", ...), new Element("button", ...) or some
> possible extension of .createElement("button", ...). However, Element
> constructors are desirable to the consistency:
>
> > (b) Consistency with other constructable DOM objects
> > new XMLHttpRequest(), new Image(), new Event(), new CustomEvent(), new
> > MessageEvent(), ...
>
> and are required for the sub-typing:
>
> > (c) Enables to subtype DOM objects in the future
> > We are planning to make DOM objects subtype-able, like this:
> >
> > function MyButton(text) {
> > HTMLButtonElement.call(this); /* (#) */
> > this.textContent = text;
> > }
> > MyButton.prototype = Object.create(HTMLButtonElement.prototype, {...});
> > var fancyButton = new MyButton("Click Me!!");
> >
> > In order to make the line (#) work, HTMLButtonElement must have a
> > constructor.
Sadly, your consistency argument has a flaw. If you try
XMLHttpRequest.call(...);
you get
TypeError: Object function XMLHttpRequest() { [native code] } has no
method 'call'
Similarly for Image and perhaps others.
This is just a trivial way of saying that the model you are promoting
as the use-model isn't current practice. I like it, I think it should
be used, but consistency with the past isn't a strong argument to
support it. Furthermore, if we want this kind of consistency we have
to change the current spec to support it.
A plus and minus you probably already discussed: A standard based on
eg HTMLButtonElement() with HTMLButtonElement.prototype would allow
library implementation of Element('button',...), but the other way
around seems hard. On the other hand, a specification for
Element('button', otherArgs) that must call eg
HTMLButtonElement(otherArgs) would be straight-forward except for
error conditions.
jjb
Re: [IndexedDB] IDBObjectStore.delete should accept a KeyRange
On Fri, Oct 28, 2011 at 9:29 AM, Israel Hilerio wrote: > On Thursday, October 27, 2011 6:00 PM, Jonas Sicking wrote: >> On Thu, Oct 27, 2011 at 9:33 AM, Israel Hilerio >> wrote: >> > On Wednesday, October 26, 2011 6:38 PM, Jonas Sicking wrote: >> >> On Wed, Oct 26, 2011 at 11:31 AM, Israel Hilerio >> >> >> >> wrote: >> >> > On Wednesday, October 26, 2011 9:35 AM, Joshua Bell wrote: >> >> >>On Tue, Oct 25, 2011 at 4:50 PM, Israel Hilerio >> >> >> >> >> wrote: >> >> >>>On Monday, October 24, 2011 7:40 PM, Jonas Sicking wrote: >> >> >> >> While I was there it did occur to me that the fact that the >> >> .delete function "returns" (through request.result in the async >> >> API) true/false depending on if any records were removed or not >> >> might be >> >> bad for performance. >> >> >> >> I suspect that this highly depends on the implementation and >> >> that in some implementations knowing if records were deleted >> >> will be free and in others it will be as costly as a .count() >> >> and then a .delete(). In yet others it could depend on if a >> >> range, rather than a key, was used, or if the objectStore has >> >> indexes which might need >> >> updating. >> >> >> >> Ultimately I don't have a strong preference either way, though >> >> it seems unfortunate to slow down implementations for what >> >> likely is a >> >> rare use case. >> >> >> >> Let me know what you think. >> >> >> >> / Jonas >> >> >> >> > >> >> >>>To clarify, removing the return value from the sync call would >> >> >>>change its >> >> return signature to void. In this case, >>successfully returning >> >> from the IDBObjectStore.delete call would mean that the information >> >> was successfully >> >> >>deleted, correct? If the information was not successfully deleted, >> >> >>would we >> >> throw an exception? >> >> >>> >> >> >>>In the async case, we would keep the same return value of >> >> >>>IDBRequest for >> >> IDBObjectStore.delete. The only change is >>that the request.result >> >> would be null, correct? If no information is deleted or if part of >> >> the keyRange data is deleted, >>should we throw an error event? It seems >> reasonable to me. >> >> > >> >> >>When you write "If no information is deleted ... should we throw an >> >> >>error >> >> event?" do you mean (1) there was no >matching key so the delete was >> >> a no- op, or (2) there was a matching key but an internal error >> >> occurred preventing the >delete? I ask because the second clause, "if >> >> part of the keyRange data is deleted, should we throw an error >> >> event?" >doesn't make sense to me in interpretation (1) since I'd expect >> sparse ranges in many cases. >> >> > >> >> > I was originally referring to (1) and (2). However, after >> >> > discussing this with >> >> a couple of folks we believe that the better approach would be to: >> >> > * continue to return true or false in the result. This will take >> >> > care of (1) and >> >> the successful deletion of all records. >> >> > * publish an error event if (2). What I meant by (2) is that if >> >> > there was a >> >> successful set of matches that were able to be returned by the >> >> keyRange, we should guarantee the deletion of all the matches or none. >> >> > >> >> > However, (2) brings up a bigger issue. We are basically saying >> >> > that if we >> >> support deletion of keyRanges we are guaranteeing that the batch >> >> operation will all happen or none of it will happen. This implies >> >> some type of inner- transaction associated only with the delete >> >> operation, which could also be rolledback as part of the >> >> outer-transaction. Otherwise, you could potentially preventDefault >> >> on any record that failed to be deleted and have your database in some >> type of inconsistent state. Was that the intent? >> >> >> >> This is already the case. For example when a inserting a value into >> >> an object store the implementation might need to go update several >> >> indexes. Updating one of these indexes might result in the violation >> >> of a 'unique' constraint at which point all changes to all indexes as >> >> well as the change to the object store must be rolled back. However >> >> no other changes done as part of the transaction should be rolled >> >> back (unless the resulting "error" event isn't canceled). >> >> >> >> This is required in step 7 of the "Steps for asynchronously executing >> >> a request" (though I now see that it's missing in the "Steps for >> >> synchronously executing a request"). >> >> >> >> dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#steps-for- >> >> asynchronously-executing-a-request >> >> >> >> In the firefox implementation we create a "mini transaction" for each >> >> database request and if any part of the request fail we just roll >> >> back the "mini transaction". >> > >> > You are correct! I forgot that we also do something similar. >> > So
RE: [IndexedDB] IDBObjectStore.delete should accept a KeyRange
Forgot some things! On Thursday, October 27, 2011 6:00 PM, Jonas Sicking wrote: > On Thu, Oct 27, 2011 at 9:33 AM, Israel Hilerio > wrote: > > On Wednesday, October 26, 2011 6:38 PM, Jonas Sicking wrote: > >> On Wed, Oct 26, 2011 at 11:31 AM, Israel Hilerio > >> > >> wrote: > >> > On Wednesday, October 26, 2011 9:35 AM, Joshua Bell wrote: > >> >>On Tue, Oct 25, 2011 at 4:50 PM, Israel Hilerio > >> >> > >> wrote: > >> >>>On Monday, October 24, 2011 7:40 PM, Jonas Sicking wrote: > >> > >> While I was there it did occur to me that the fact that the > >> .delete function "returns" (through request.result in the async > >> API) true/false depending on if any records were removed or not > >> might be > >> bad for performance. > >> > >> I suspect that this highly depends on the implementation and > >> that in some implementations knowing if records were deleted > >> will be free and in others it will be as costly as a .count() > >> and then a .delete(). In yet others it could depend on if a > >> range, rather than a key, was used, or if the objectStore has > >> indexes which might need > >> updating. > >> > >> Ultimately I don't have a strong preference either way, though > >> it seems unfortunate to slow down implementations for what > >> likely is a > >> rare use case. > >> > >> Let me know what you think. > >> > >> / Jonas > >> > >> > > >> >>>To clarify, removing the return value from the sync call would > >> >>>change its > >> return signature to void. In this case, >>successfully returning > >> from the IDBObjectStore.delete call would mean that the information > >> was successfully > >> >>deleted, correct? If the information was not successfully deleted, > >> >>would we > >> throw an exception? > >> >>> > >> >>>In the async case, we would keep the same return value of > >> >>>IDBRequest for > >> IDBObjectStore.delete. The only change is >>that the request.result > >> would be null, correct? If no information is deleted or if part of > >> the keyRange data is deleted, >>should we throw an error event? It seems > reasonable to me. > >> > > >> >>When you write "If no information is deleted ... should we throw an > >> >>error > >> event?" do you mean (1) there was no >matching key so the delete was > >> a no- op, or (2) there was a matching key but an internal error > >> occurred preventing the >delete? I ask because the second clause, "if > >> part of the keyRange data is deleted, should we throw an error > >> event?" >doesn't make sense to me in interpretation (1) since I'd expect > sparse ranges in many cases. > >> > > >> > I was originally referring to (1) and (2). However, after > >> > discussing this with > >> a couple of folks we believe that the better approach would be to: > >> > * continue to return true or false in the result. This will take > >> > care of (1) and > >> the successful deletion of all records. > >> > * publish an error event if (2). What I meant by (2) is that if > >> > there was a > >> successful set of matches that were able to be returned by the > >> keyRange, we should guarantee the deletion of all the matches or none. > >> > > >> > However, (2) brings up a bigger issue. We are basically saying > >> > that if we > >> support deletion of keyRanges we are guaranteeing that the batch > >> operation will all happen or none of it will happen. This implies > >> some type of inner- transaction associated only with the delete > >> operation, which could also be rolledback as part of the > >> outer-transaction. Otherwise, you could potentially preventDefault > >> on any record that failed to be deleted and have your database in some > type of inconsistent state. Was that the intent? > >> > >> This is already the case. For example when a inserting a value into > >> an object store the implementation might need to go update several > >> indexes. Updating one of these indexes might result in the violation > >> of a 'unique' constraint at which point all changes to all indexes as > >> well as the change to the object store must be rolled back. However > >> no other changes done as part of the transaction should be rolled > >> back (unless the resulting "error" event isn't canceled). > >> > >> This is required in step 7 of the "Steps for asynchronously executing > >> a request" (though I now see that it's missing in the "Steps for > >> synchronously executing a request"). > >> > >> dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#steps-for- > >> asynchronously-executing-a-request > >> > >> In the firefox implementation we create a "mini transaction" for each > >> database request and if any part of the request fail we just roll > >> back the "mini transaction". > > > > You are correct! I forgot that we also do something similar. > > So if we fail to remove any one record from the keyRange set, should we > throw an InvalidStateError, UnknownError, other? > > I think for fai
RE: [IndexedDB] IDBObjectStore.delete should accept a KeyRange
On Thursday, October 27, 2011 6:00 PM, Jonas Sicking wrote: > On Thu, Oct 27, 2011 at 9:33 AM, Israel Hilerio > wrote: > > On Wednesday, October 26, 2011 6:38 PM, Jonas Sicking wrote: > >> On Wed, Oct 26, 2011 at 11:31 AM, Israel Hilerio > >> > >> wrote: > >> > On Wednesday, October 26, 2011 9:35 AM, Joshua Bell wrote: > >> >>On Tue, Oct 25, 2011 at 4:50 PM, Israel Hilerio > >> >> > >> wrote: > >> >>>On Monday, October 24, 2011 7:40 PM, Jonas Sicking wrote: > >> > >> While I was there it did occur to me that the fact that the > >> .delete function "returns" (through request.result in the async > >> API) true/false depending on if any records were removed or not > >> might be > >> bad for performance. > >> > >> I suspect that this highly depends on the implementation and > >> that in some implementations knowing if records were deleted > >> will be free and in others it will be as costly as a .count() > >> and then a .delete(). In yet others it could depend on if a > >> range, rather than a key, was used, or if the objectStore has > >> indexes which might need > >> updating. > >> > >> Ultimately I don't have a strong preference either way, though > >> it seems unfortunate to slow down implementations for what > >> likely is a > >> rare use case. > >> > >> Let me know what you think. > >> > >> / Jonas > >> > >> > > >> >>>To clarify, removing the return value from the sync call would > >> >>>change its > >> return signature to void. In this case, >>successfully returning > >> from the IDBObjectStore.delete call would mean that the information > >> was successfully > >> >>deleted, correct? If the information was not successfully deleted, > >> >>would we > >> throw an exception? > >> >>> > >> >>>In the async case, we would keep the same return value of > >> >>>IDBRequest for > >> IDBObjectStore.delete. The only change is >>that the request.result > >> would be null, correct? If no information is deleted or if part of > >> the keyRange data is deleted, >>should we throw an error event? It seems > reasonable to me. > >> > > >> >>When you write "If no information is deleted ... should we throw an > >> >>error > >> event?" do you mean (1) there was no >matching key so the delete was > >> a no- op, or (2) there was a matching key but an internal error > >> occurred preventing the >delete? I ask because the second clause, "if > >> part of the keyRange data is deleted, should we throw an error > >> event?" >doesn't make sense to me in interpretation (1) since I'd expect > sparse ranges in many cases. > >> > > >> > I was originally referring to (1) and (2). However, after > >> > discussing this with > >> a couple of folks we believe that the better approach would be to: > >> > * continue to return true or false in the result. This will take > >> > care of (1) and > >> the successful deletion of all records. > >> > * publish an error event if (2). What I meant by (2) is that if > >> > there was a > >> successful set of matches that were able to be returned by the > >> keyRange, we should guarantee the deletion of all the matches or none. > >> > > >> > However, (2) brings up a bigger issue. We are basically saying > >> > that if we > >> support deletion of keyRanges we are guaranteeing that the batch > >> operation will all happen or none of it will happen. This implies > >> some type of inner- transaction associated only with the delete > >> operation, which could also be rolledback as part of the > >> outer-transaction. Otherwise, you could potentially preventDefault > >> on any record that failed to be deleted and have your database in some > type of inconsistent state. Was that the intent? > >> > >> This is already the case. For example when a inserting a value into > >> an object store the implementation might need to go update several > >> indexes. Updating one of these indexes might result in the violation > >> of a 'unique' constraint at which point all changes to all indexes as > >> well as the change to the object store must be rolled back. However > >> no other changes done as part of the transaction should be rolled > >> back (unless the resulting "error" event isn't canceled). > >> > >> This is required in step 7 of the "Steps for asynchronously executing > >> a request" (though I now see that it's missing in the "Steps for > >> synchronously executing a request"). > >> > >> dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#steps-for- > >> asynchronously-executing-a-request > >> > >> In the firefox implementation we create a "mini transaction" for each > >> database request and if any part of the request fail we just roll > >> back the "mini transaction". > > > > You are correct! I forgot that we also do something similar. > > So if we fail to remove any one record from the keyRange set, should we > throw an InvalidStateError, UnknownError, other? > > I think for failed reads/writes like
Re: A proposal for Element constructors
Rick has a point.
I used Prototype's Element constructor for years and have moved
towards the jQuery approach in my own API.
Something like Element('') is so so soo nice compared with more
verbose alternatives and you can still add attributes to elements via
a second argument. I know some prefer smth like Element('div#foo') ->
but that get's ugly when trying to expand that
syntax to an element's children. Also the `new` operator should be
optional as it is with others like `Array`, `RegExp`, and `Function`.
http://api.jquery.com/jQuery/#jQuery2
Also these mods should be safe for libs like Prototype because they
pave the Element class with their own custom Element constructor.
- John-David Dalton
[indexeddb] 'raises' statements in IDL
Hi all, I noticed that the IDB spec still uses 'getraises' and 'raises' statements in the IDL code. These were removed in bug 13866 [1]. HTH Ms2ger [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13866
