Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 19:54, Jonas Sicking wrote: > Sure. Though you could also just do > > var b = new Blob(); > b = new Blob([b, data]); > b = new Blob([b, moreData]); That works for me. -- erik
[Bug 13104] Enable keepalive on WebSocket API
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13104 Ian 'Hixie' Hickson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #26 from Ian 'Hixie' Hickson 2011-10-25 04:38:18 UTC --- Done. -- 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.
[Bug 14513] WebSocket API: Missing reference for definition of MessageEvent
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14513 Ian 'Hixie' Hickson changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||FIXED --- Comment #1 from Ian 'Hixie' Hickson 2011-10-25 03:10:28 UTC --- You're better off using the full spec: http://whatwg.org/html I've added a reference to the spec that defines it, anyway. -- 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: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 10:49 PM, Erik Arvidsson wrote:
> I think the point is that with the old one you could generate lots of
> data, add that to the blob, generate a lot more data and add that to
> the blob. After every add it might be safe to gc that data. With this
> proposal all that data needs to be in memory at the point of
> construction.
>
It doesn't. Each individual "low-level" Blob can be swapped to disk, and
stay there; you don't need to read it into memory to construct new Blobs
containing it.
Repeating my earlier example:
var b = new Blob();
ongotdataevent = function(blobToAppend) { b = new Blob(b, blobToAppend); }
You don't need to have any of the previous Blobs in memory when you create
each new compound Blob; you only need to know where to get them later, and
their size.
> Could we add a concat like method to Blob that returns a new "larger" blob?
>
> var bb = new BlobBuilder();
> bb.append(data);
> bb.append(moreData);
> var b = bb.getBlob();
>
This is the same as the above: new Blob(data, moreData). There's no need
for a special method for this.
--
Glenn Maynard
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 7:49 PM, Erik Arvidsson wrote: > On Mon, Oct 24, 2011 at 19:23, Jonas Sicking wrote: >>> On the topic of getting rid of BlobBuilder, do you have thoughts on losing >>> the ability to back it by an on-disk file? >> >> I'm not sure I understand the problem. A Blob can also be backed by a >> on-disk file. >> >> Could you elaborate? > > I think the point is that with the old one you could generate lots of > data, add that to the blob, generate a lot more data and add that to > the blob. After every add it might be safe to gc that data. With this > proposal all that data needs to be in memory at the point of > construction. > > Could we add a concat like method to Blob that returns a new "larger" blob? > > var bb = new BlobBuilder(); > bb.append(data); > bb.append(moreData); > var b = bb.getBlob(); > > var b = new Blob(); > b = b.concat(data); > b = b.concat(moreData); Sure. Though you could also just do var b = new Blob(); b = new Blob([b, data]); b = new Blob([b, moreData]); I don't really have a strong preference for we should have .concat as well or not. Array and String both have a lot of redundant methods for concatenating and splitting data. / Jonas
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 7:49 PM, Erik Arvidsson wrote: > On Mon, Oct 24, 2011 at 19:23, Jonas Sicking wrote: > >> On the topic of getting rid of BlobBuilder, do you have thoughts on > losing > >> the ability to back it by an on-disk file? > > > > I'm not sure I understand the problem. A Blob can also be backed by a > > on-disk file. > > > > Could you elaborate? > > I think the point is that with the old one you could generate lots of > data, add that to the blob, generate a lot more data and add that to > the blob. After every add it might be safe to gc that data. With this > proposal all that data needs to be in memory at the point of > construction. > > Could we add a concat like method to Blob that returns a new "larger" blob? > If concat also took an array and/or varargs, then I'd be happy with this and getting rid of BlobBuilder. > var bb = new BlobBuilder(); > bb.append(data); > bb.append(moreData); > var b = bb.getBlob(); > > var b = new Blob(); > b = b.concat(data); > b = b.concat(moreData); > > -- > erik >
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 19:23, Jonas Sicking wrote: >> On the topic of getting rid of BlobBuilder, do you have thoughts on losing >> the ability to back it by an on-disk file? > > I'm not sure I understand the problem. A Blob can also be backed by a > on-disk file. > > Could you elaborate? I think the point is that with the old one you could generate lots of data, add that to the blob, generate a lot more data and add that to the blob. After every add it might be safe to gc that data. With this proposal all that data needs to be in memory at the point of construction. Could we add a concat like method to Blob that returns a new "larger" blob? var bb = new BlobBuilder(); bb.append(data); bb.append(moreData); var b = bb.getBlob(); var b = new Blob(); b = b.concat(data); b = b.concat(moreData); -- erik
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 16:46, Tab Atkins Jr. wrote:
> Easy. The destructuring stuff proposed for ES lets you easily say things
> like:
>
> function(blobparts..., keywordargs) {
> // blobparts is an array of all but the last arg
> // keywordargs is the last arg
> }
>
> or even:
>
> function(blobparts..., {contenttype, lineendings}) {
> // blobparts is an array of all but the last arg
> // contenttype and lineendings are pulled from the
> // last arg, if it's an object with those properties
> }
Nope. The rest parameter must be the last parameter.
This is already in the latest draft for edition 6.
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
See "13 Function Definition".
Re: [IndexedDB] IDBObjectStore.delete should accept a KeyRange
On Mon, Oct 24, 2011 at 11:28 AM, Jonas Sicking wrote: > On Mon, Oct 24, 2011 at 10:17 AM, Israel Hilerio > wrote: >> On Wednesday, October 12, 2011 2:28 PM, Jonas Sicking wrote: >>> Currently IDBObjectStore.count/get/openCursor and >>> IDBIndex.count/get/openCursor/openKeyCursor all take a key or a KeyRange. >>> However IDBObjectStore.delete only accepts keys. We should fix this to allow >>> .delete to accept a KeyRange as well. >>> >>> / Jonas >>> >> >> This makes sense to me. Is this something we still want to do? > > Yup, I think so. I was just waiting to hear back from others. I'll go > ahead and make that change to the spec right away. I made this change. I still kept the difference that .delete(null) does not work. I.e. it doesn't match, and delete, all records in the store. It simply seems like it would make it too easy to accidentally nuke all the data from an object store. We also already have the .clear() function to do that. 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
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 7:11 PM, Ojan Vafai wrote:
> On Mon, Oct 24, 2011 at 6:40 PM, Jonas Sicking wrote:
>>
>> On Mon, Oct 24, 2011 at 4:46 PM, Tab Atkins Jr.
>> wrote:
>> > On Mon, Oct 24, 2011 at 4:33 PM, Eric U wrote:
>> >> The only things that this lacks that BlobBuilder has are the endings
>> >> parameter for '\n' conversion in text and the content type. The
>> >> varargs constructor makes it awkward to pass in flags of any
>> >> sort...any thoughts on how to do that cleanly?
>> >
>> > Easy. The destructuring stuff proposed for ES lets you easily say
>> > things like:
>> >
>> > function(blobparts..., keywordargs) {
>> > // blobparts is an array of all but the last arg
>> > // keywordargs is the last arg
>> > }
>> >
>> > or even:
>> >
>> > function(blobparts..., {contenttype, lineendings}) {
>> > // blobparts is an array of all but the last arg
>> > // contenttype and lineendings are pulled from the
>> > // last arg, if it's an object with those properties
>> > }
>>
>> The problem is that if the caller has an array, because this is a
>> constructor, this will get *very* awkward to do until ES6 is actually
>> implemented.
>
> We should pressure ecmascript to stabilize this part of ES6 early so that we
> can implement it. That way we can start designing the APIs we want now
> instead of almost the APIs we want. That said, I'm not opposed to the array
> argument for now. We can always add the destructured version in addition
> later.
That's the route I would prefer to go yeah.
> On the topic of getting rid of BlobBuilder, do you have thoughts on losing
> the ability to back it by an on-disk file?
I'm not sure I understand the problem. A Blob can also be backed by a
on-disk file.
Could you elaborate?
>> You can't simply do:
>>
>> new Blob.apply(blobarray.concat("text/plain"));
>>
>> I *think* this is what you'd have to do in a ES5 compliant engine:
>>
>> new Blob.bind([null].concat(blobarray, "text/plain));
>>
>> In ES3 I don't even think that there's a way to do it. Though that
>> might not matter assuming everyone gets .bind correctly implemented
>> before they implement |new Blob|.
>>
>> I don't think the complexity is worth it for a dubious gain. I.e. it's
>> not entirely clear to me that the following:
>>
>> new Blob(blob1, blob2, mybuffer, blob3, "somestring", "text/plain");
>
>
> Could we make the first argument be the contenttype? That makes the vararg
> version work better. As it is, "text/plain" could, theoretically be part of
> the content. I guess that's an argument for only doing the array version.
> Then the contenttype could come second and be optional. As I said, I don't
> feel strongly about this.
That only changes
new Blob.bind([null].concat(blobarray, "text/plain"));
to
new Blob.bind([null].concat("text/plain", blobarray));
So I'm not sure it's a lot better :-)
/ Jonas
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 6:40 PM, Jonas Sicking wrote:
> On Mon, Oct 24, 2011 at 4:46 PM, Tab Atkins Jr.
> wrote:
> > On Mon, Oct 24, 2011 at 4:33 PM, Eric U wrote:
> >> The only things that this lacks that BlobBuilder has are the endings
> >> parameter for '\n' conversion in text and the content type. The
> >> varargs constructor makes it awkward to pass in flags of any
> >> sort...any thoughts on how to do that cleanly?
> >
> > Easy. The destructuring stuff proposed for ES lets you easily say things
> like:
> >
> > function(blobparts..., keywordargs) {
> > // blobparts is an array of all but the last arg
> > // keywordargs is the last arg
> > }
> >
> > or even:
> >
> > function(blobparts..., {contenttype, lineendings}) {
> > // blobparts is an array of all but the last arg
> > // contenttype and lineendings are pulled from the
> > // last arg, if it's an object with those properties
> > }
>
> The problem is that if the caller has an array, because this is a
> constructor, this will get *very* awkward to do until ES6 is actually
> implemented.
>
We should pressure ecmascript to stabilize this part of ES6 early so that we
can implement it. That way we can start designing the APIs we want now
instead of almost the APIs we want. That said, I'm not opposed to the array
argument for now. We can always add the destructured version in addition
later.
On the topic of getting rid of BlobBuilder, do you have thoughts on losing
the ability to back it by an on-disk file?
> You can't simply do:
>
> new Blob.apply(blobarray.concat("text/plain"));
>
> I *think* this is what you'd have to do in a ES5 compliant engine:
>
> new Blob.bind([null].concat(blobarray, "text/plain));
>
> In ES3 I don't even think that there's a way to do it. Though that
> might not matter assuming everyone gets .bind correctly implemented
> before they implement |new Blob|.
>
> I don't think the complexity is worth it for a dubious gain. I.e. it's
> not entirely clear to me that the following:
>
> new Blob(blob1, blob2, mybuffer, blob3, "somestring", "text/plain");
>
Could we make the first argument be the contenttype? That makes the vararg
version work better. As it is, "text/plain" could, theoretically be part of
the content. I guess that's an argument for only doing the array version.
Then the contenttype could come second and be optional. As I said, I don't
feel strongly about this.
> is significantly better than
>
> new Blob([blob1, blob2, mybuffer, blob3, "somestring"], "text/plain");
> / Jonas
>
>
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 4:46 PM, Tab Atkins Jr. wrote:
> On Mon, Oct 24, 2011 at 4:33 PM, Eric U wrote:
>> The only things that this lacks that BlobBuilder has are the endings
>> parameter for '\n' conversion in text and the content type. The
>> varargs constructor makes it awkward to pass in flags of any
>> sort...any thoughts on how to do that cleanly?
>
> Easy. The destructuring stuff proposed for ES lets you easily say things
> like:
>
> function(blobparts..., keywordargs) {
> // blobparts is an array of all but the last arg
> // keywordargs is the last arg
> }
>
> or even:
>
> function(blobparts..., {contenttype, lineendings}) {
> // blobparts is an array of all but the last arg
> // contenttype and lineendings are pulled from the
> // last arg, if it's an object with those properties
> }
The problem is that if the caller has an array, because this is a
constructor, this will get *very* awkward to do until ES6 is actually
implemented.
You can't simply do:
new Blob.apply(blobarray.concat("text/plain"));
I *think* this is what you'd have to do in a ES5 compliant engine:
new Blob.bind([null].concat(blobarray, "text/plain));
In ES3 I don't even think that there's a way to do it. Though that
might not matter assuming everyone gets .bind correctly implemented
before they implement |new Blob|.
I don't think the complexity is worth it for a dubious gain. I.e. it's
not entirely clear to me that the following:
new Blob(blob1, blob2, mybuffer, blob3, "somestring", "text/plain");
is significantly better than
new Blob([blob1, blob2, mybuffer, blob3, "somestring"], "text/plain");
/ Jonas
Re: [IndexedDB] Passing an empty array to IDBDatabase.transaction
On Mon, Oct 24, 2011 at 5:28 PM, Israel Hilerio wrote:
> On Monday, October 17, 2011 9:14 PM, Cameron McCormack wrote:
>> On 17/10/11 7:19 PM, Jonas Sicking wrote:
>> > I sort of like the short-cut since it seems like a very common case
>> > for web developers to want to create a transaction which only uses a
>> > single objectStore.
>> >
>> > But I agree it's not a huge win for developers as far as typing goes
>> > (two characters).
>> >
>> > I *think* we can move the validation into the IDL binding these days.
>> > Something like:
>> >
>> > interface IDBDatabase {
>> > ...
>> > transaction(DOMStringList storeNames, optional unsigned short mode);
>> > transaction(DOMString[] storeNames, optional unsigned short mode);
>> > transaction(DOMString storeNames, optional unsigned short mode);
>> > ...
>> > }
>> >
>> > The WebSocket constructor does something similar.
>> >
>> > cc'ing Cameron to confirm that this is valid. It *might* even be the
>> > case that DOMStringList passes as a DOMString[]?
>>
>> The above IDL is valid (assuming you stick "void" before the function names).
>> Although DOMStringList is array like enough to work if you are not
>> overloading based on that argument (it has a .length and array index
>> properties), in this case because the function call is only distinguished
>> based
>> on the first argument you will need those separate declarations.
>>
>> You can see what happens when a value is passed as that first parameter
>> here:
>>
>> http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm
>>
>> If it's a DOMStringList object, since that is an interface type, it will
>> definitely
>> select the first overload. And if you pass an Array object or a platform
>> array
>> object, then the second overload will be selected.
>>
>
> After discussing this with some folks on our side, this change makes sense to
> us.
> There seem to be clear advantages at providing these overloads.
> I'm guessing we want to make this change to the webIDL of IDBDatabase,
> correct?
Yup. Sounds good to me.
/ Jonas
Re: [indexeddb] New WebIDL Exception Model for IndexedDB
On Mon, Oct 24, 2011 at 4:23 PM, Cameron McCormack wrote: > Replying late here, but: > > On 29/09/11 12:03 AM, Jonas Sicking wrote: >> >> From my understanding of the WebIDL spec, the idea is that >> specifications like IndexedDB should throw exceptions which use the >> DOMExceptions interface. The various errors would use different string >> values for .name which would replace the current codes that we have >> now. However, if existing ECMAScript errors can be used, we should use >> those. >> >> Cc'ing Cameron so that he can confirm that this is a correct >> understanding. > > That's not actually what the changes allow. The built-in Error types in > ECMAScript are not available at the IDL level. But I think that it would be > better if they are. I can lift them up to the IDL level, and define what it > means to "throw a TypeError" in other languages. So I actually do think that we want to explicitly throw a TypeError from at least one place in IndexedDB. Which is if you pass a illegal value to a function which takes an enumerated value. For example IDBDatabase.transaction has a second argument which indicates readonly or read/write (we might add other types in the future which is why it's not a bool). Here we'll want to throw a TypeError if someone passes the wrong value. / Jonas
RE: [IndexedDB] Passing an empty array to IDBDatabase.transaction
On Monday, October 17, 2011 9:14 PM, Cameron McCormack wrote:
> On 17/10/11 7:19 PM, Jonas Sicking wrote:
> > I sort of like the short-cut since it seems like a very common case
> > for web developers to want to create a transaction which only uses a
> > single objectStore.
> >
> > But I agree it's not a huge win for developers as far as typing goes
> > (two characters).
> >
> > I *think* we can move the validation into the IDL binding these days.
> > Something like:
> >
> > interface IDBDatabase {
> >...
> >transaction(DOMStringList storeNames, optional unsigned short mode);
> >transaction(DOMString[] storeNames, optional unsigned short mode);
> >transaction(DOMString storeNames, optional unsigned short mode);
> >...
> > }
> >
> > The WebSocket constructor does something similar.
> >
> > cc'ing Cameron to confirm that this is valid. It *might* even be the
> > case that DOMStringList passes as a DOMString[]?
>
> The above IDL is valid (assuming you stick "void" before the function names).
> Although DOMStringList is array like enough to work if you are not
> overloading based on that argument (it has a .length and array index
> properties), in this case because the function call is only distinguished
> based
> on the first argument you will need those separate declarations.
>
> You can see what happens when a value is passed as that first parameter
> here:
>
> http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm
>
> If it's a DOMStringList object, since that is an interface type, it will
> definitely
> select the first overload. And if you pass an Array object or a platform
> array
> object, then the second overload will be selected.
>
After discussing this with some folks on our side, this change makes sense to
us.
There seem to be clear advantages at providing these overloads.
I'm guessing we want to make this change to the webIDL of IDBDatabase, correct?
Israel
[Bug 14148] Drop resolveURL in favor of URL()
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14148 Ian 'Hixie' Hickson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Ian 'Hixie' Hickson 2011-10-25 00:29:08 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given above Rationale: Concurred with reporter's comments. -- 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.
[Bug 13373] Privacy: Limit SharedWorker connections to same top-level domain
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13373 Ian 'Hixie' Hickson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Ian 'Hixie' Hickson 2011-10-25 00:10:09 UTC --- Done. -- 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.
[Bug 14329] Add a warning about high-volume traffic through MessagePort being a DOS risk for UAs and scripts
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14329 Ian 'Hixie' Hickson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Ian 'Hixie' Hickson 2011-10-25 00:01:10 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: see diff given below Rationale: I added some informative text about this to the window.postMessage() section. I didn't add anything to the MessagePort section since an attacker couldn't get a MessagePort from another domain unless the other domain explicitly sent one to the attacker. Let me know if you think I should add anything else. -- 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: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 4:33 PM, Eric U wrote:
> The only things that this lacks that BlobBuilder has are the endings
> parameter for '\n' conversion in text and the content type. The
> varargs constructor makes it awkward to pass in flags of any
> sort...any thoughts on how to do that cleanly?
Easy. The destructuring stuff proposed for ES lets you easily say things like:
function(blobparts..., keywordargs) {
// blobparts is an array of all but the last arg
// keywordargs is the last arg
}
or even:
function(blobparts..., {contenttype, lineendings}) {
// blobparts is an array of all but the last arg
// contenttype and lineendings are pulled from the
// last arg, if it's an object with those properties
}
~TJ
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 4:33 PM, Eric U wrote:
> On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
>> Hi everyone,
>>
>> It was pointed out to me on twitter that BlobBuilder can be replaced
>> with simply making Blob constructable. I.e. the following code:
>>
>> var bb = new BlobBuilder();
>> bb.append(blob1);
>> bb.append(blob2);
>> bb.append("some string");
>> bb.append(myArrayBuffer);
>> var b = bb.getBlob();
>>
>> would become
>>
>> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>>
>> or look at it another way:
>>
>> var x = new BlobBuilder();
>> becomes
>> var x = [];
>>
>> x.append(y);
>> becomes
>> x.push(y);
>>
>> var b = x.getBlob();
>> becomes
>> var b = new Blob(x);
>>
>> So at worst there is a one-to-one mapping in code required to simply
>> have |new Blob|. At best it requires much fewer lines if the page has
>> several parts available at once.
>>
>> And we'd save a whole class since Blobs already exist.
>
> It does look cleaner this way, and getting rid of a whole class would
> be very nice.
>
> The only things that this lacks that BlobBuilder has are the endings
> parameter for '\n' conversion in text and the content type. The
> varargs constructor makes it awkward to pass in flags of any
> sort...any thoughts on how to do that cleanly?
The content-type can and should be added to the ctor.
Line-endings is a problem though. I'm not fully sure what the use case
is for them, and the spec does have an issue-marked asking if
line-ending conversion is needed at all. Worst case we could do them
as a separate function which does native-lineending-conversion for a
string.
I'm not fully sold on the var-args thing. It gets very awkward with
the content-type argument, and like you point out, it does make the
API less future proof.
It's also a bit scary to rely on a ES6 feature while ES6 is as
unstable as it still is.
/ Jonas
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
> Hi everyone,
>
> It was pointed out to me on twitter that BlobBuilder can be replaced
> with simply making Blob constructable. I.e. the following code:
>
> var bb = new BlobBuilder();
> bb.append(blob1);
> bb.append(blob2);
> bb.append("some string");
> bb.append(myArrayBuffer);
> var b = bb.getBlob();
>
> would become
>
> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>
> or look at it another way:
>
> var x = new BlobBuilder();
> becomes
> var x = [];
>
> x.append(y);
> becomes
> x.push(y);
>
> var b = x.getBlob();
> becomes
> var b = new Blob(x);
>
> So at worst there is a one-to-one mapping in code required to simply
> have |new Blob|. At best it requires much fewer lines if the page has
> several parts available at once.
>
> And we'd save a whole class since Blobs already exist.
It does look cleaner this way, and getting rid of a whole class would
be very nice.
The only things that this lacks that BlobBuilder has are the endings
parameter for '\n' conversion in text and the content type. The
varargs constructor makes it awkward to pass in flags of any
sort...any thoughts on how to do that cleanly?
Eric
Re: [indexeddb] New WebIDL Exception Model for IndexedDB
Replying late here, but: On 29/09/11 12:03 AM, Jonas Sicking wrote: From my understanding of the WebIDL spec, the idea is that specifications like IndexedDB should throw exceptions which use the DOMExceptions interface. The various errors would use different string values for .name which would replace the current codes that we have now. However, if existing ECMAScript errors can be used, we should use those. Cc'ing Cameron so that he can confirm that this is a correct understanding. That's not actually what the changes allow. The built-in Error types in ECMAScript are not available at the IDL level. But I think that it would be better if they are. I can lift them up to the IDL level, and define what it means to "throw a TypeError" in other languages.
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 4:15 PM, Michael Nordman wrote: > It's nice. Like Ojan said, I don't see this as mutually exlusive with > BlobBuilder either. There's nother peice of data to associate with a blob... > the content-type... that would need to be provided in the ctor. Good point. Which makes it much harder to use the ES6 fancyness. / Jonas
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 6:52 PM, Jonas Sicking wrote:
> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>
To give another comparison, this incremental appending:
bb = new BlobBuilder();
ongotdataevent = function(blobToAppend) { bb.append(blobToAppend); }
ondatafinishedevent = function() { b = bb.getBlob(); }
can become:
var b = new Blob();
ongotdataevent = function(blobToAppend) { b = new Blob(b, blobToAppend); }
which is nice, too. (UAs should optimize this to avoid O(n^2) copying, of
course.)
On Mon, Oct 24, 2011 at 7:01 PM, Ojan Vafai wrote:
> In theory, a BlobBuilder could be backed by a file on disk, no? The
> advantage is that if you're building something very large, you don't
> necessarily need to be using all that memory. You can imagine a UA having
> Blobs be fully in-memory until they cross some size threshold.
>
Blobs, or parts of Blobs, can be backed by files on disk too. You don't
need BlobBuilder to get that functionality.
--
Glenn Maynard
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 4:01 PM, Ojan Vafai wrote: > In theory, a BlobBuilder could be backed by a file on disk, no? The > advantage is that if you're building something very large, you don't > necessarily need to be using all that memory. You can imagine a UA having > Blobs be fully in-memory until they cross some size threshold. It does seem like something of an edge case to add a very big string or arraybuffer and then keep the BlobBuilder alive for long enough after that that both the string/arraybuffer is otherwise GC'ed, *and* that that memory usage is an issue. Worst case you can always change x.push(mylargestring); into x.push(new Blob(mylargestring)); and then the UA should be able to do the same optimization. / Jonas
Re: Is BlobBuilder needed?
It's nice. Like Ojan said, I don't see this as mutually exlusive with
BlobBuilder either. There's nother peice of data to associate with a
blob... the content-type... that would need to be provided in the ctor.
On Mon, Oct 24, 2011 at 4:01 PM, Ojan Vafai wrote:
> On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
>
>> Hi everyone,
>>
>> It was pointed out to me on twitter that BlobBuilder can be replaced
>> with simply making Blob constructable. I.e. the following code:
>>
>> var bb = new BlobBuilder();
>> bb.append(blob1);
>> bb.append(blob2);
>> bb.append("some string");
>> bb.append(myArrayBuffer);
>> var b = bb.getBlob();
>>
>> would become
>>
>> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>>
>
> I like this API. I think we should add it regardless of whether we get rid
> of BlobBuilder. I'd slightly prefer saying that Blob takes varargs and rely
> on ES6 fanciness to expand the array into varargs.
>
> In theory, a BlobBuilder could be backed by a file on disk, no? The
> advantage is that if you're building something very large, you don't
> necessarily need to be using all that memory. You can imagine a UA having
> Blobs be fully in-memory until they cross some size threshold.
>
>
>> or look at it another way:
>>
>> var x = new BlobBuilder();
>> becomes
>> var x = [];
>>
>> x.append(y);
>> becomes
>> x.push(y);
>>
>> var b = x.getBlob();
>> becomes
>> var b = new Blob(x);
>>
>> So at worst there is a one-to-one mapping in code required to simply
>> have |new Blob|. At best it requires much fewer lines if the page has
>> several parts available at once.
>>
>> And we'd save a whole class since Blobs already exist.
>>
>> / Jonas
>>
>>
>
Re: Is BlobBuilder needed?
Yeah, this is easily a win for the web platform. Smaller, more concise
API. I like it.
As Ojan said; Please use rest params here so that there is no need to
create the extra array.
erik
On Mon, Oct 24, 2011 at 16:07, Rick Waldron wrote:
> From a real-world developer perpective, this API modification is a win.
>
> On Mon, Oct 24, 2011 at 7:01 PM, Ojan Vafai wrote:
>>
>> On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
>>>
>>> Hi everyone,
>>>
>>> It was pointed out to me on twitter that BlobBuilder can be replaced
>>> with simply making Blob constructable. I.e. the following code:
>>>
>>> var bb = new BlobBuilder();
>>> bb.append(blob1);
>>> bb.append(blob2);
>>> bb.append("some string");
>>> bb.append(myArrayBuffer);
>>> var b = bb.getBlob();
>>>
>>> would become
>>>
>>> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>>
>> I like this API. I think we should add it regardless of whether we get rid
>> of BlobBuilder. I'd slightly prefer saying that Blob takes varargs and rely
>> on ES6 fanciness to expand the array into varargs.
>> In theory, a BlobBuilder could be backed by a file on disk, no? The
>> advantage is that if you're building something very large, you don't
>> necessarily need to be using all that memory. You can imagine a UA having
>> Blobs be fully in-memory until they cross some size threshold.
>>
>>>
>>> or look at it another way:
>>>
>>> var x = new BlobBuilder();
>>> becomes
>>> var x = [];
>>>
>>> x.append(y);
>>> becomes
>>> x.push(y);
>>>
>>> var b = x.getBlob();
>>> becomes
>>> var b = new Blob(x);
>>>
>>> So at worst there is a one-to-one mapping in code required to simply
>>> have |new Blob|. At best it requires much fewer lines if the page has
>>> several parts available at once.
>>>
>>> And we'd save a whole class since Blobs already exist.
>>>
>>> / Jonas
>>>
>>
>
>
Re: Is BlobBuilder needed?
>From a real-world developer perpective, this API modification is a win.
On Mon, Oct 24, 2011 at 7:01 PM, Ojan Vafai wrote:
> On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
>
>> Hi everyone,
>>
>> It was pointed out to me on twitter that BlobBuilder can be replaced
>> with simply making Blob constructable. I.e. the following code:
>>
>> var bb = new BlobBuilder();
>> bb.append(blob1);
>> bb.append(blob2);
>> bb.append("some string");
>> bb.append(myArrayBuffer);
>> var b = bb.getBlob();
>>
>> would become
>>
>> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>>
>
> I like this API. I think we should add it regardless of whether we get rid
> of BlobBuilder. I'd slightly prefer saying that Blob takes varargs and rely
> on ES6 fanciness to expand the array into varargs.
>
> In theory, a BlobBuilder could be backed by a file on disk, no? The
> advantage is that if you're building something very large, you don't
> necessarily need to be using all that memory. You can imagine a UA having
> Blobs be fully in-memory until they cross some size threshold.
>
>
>> or look at it another way:
>>
>> var x = new BlobBuilder();
>> becomes
>> var x = [];
>>
>> x.append(y);
>> becomes
>> x.push(y);
>>
>> var b = x.getBlob();
>> becomes
>> var b = new Blob(x);
>>
>> So at worst there is a one-to-one mapping in code required to simply
>> have |new Blob|. At best it requires much fewer lines if the page has
>> several parts available at once.
>>
>> And we'd save a whole class since Blobs already exist.
>>
>> / Jonas
>>
>>
>
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
> Hi everyone,
>
> It was pointed out to me on twitter that BlobBuilder can be replaced
> with simply making Blob constructable. I.e. the following code:
>
> var bb = new BlobBuilder();
> bb.append(blob1);
> bb.append(blob2);
> bb.append("some string");
> bb.append(myArrayBuffer);
> var b = bb.getBlob();
>
> would become
>
> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>
I like this API. I think we should add it regardless of whether we get rid
of BlobBuilder. I'd slightly prefer saying that Blob takes varargs and rely
on ES6 fanciness to expand the array into varargs.
In theory, a BlobBuilder could be backed by a file on disk, no? The
advantage is that if you're building something very large, you don't
necessarily need to be using all that memory. You can imagine a UA having
Blobs be fully in-memory until they cross some size threshold.
> or look at it another way:
>
> var x = new BlobBuilder();
> becomes
> var x = [];
>
> x.append(y);
> becomes
> x.push(y);
>
> var b = x.getBlob();
> becomes
> var b = new Blob(x);
>
> So at worst there is a one-to-one mapping in code required to simply
> have |new Blob|. At best it requires much fewer lines if the page has
> several parts available at once.
>
> And we'd save a whole class since Blobs already exist.
>
> / Jonas
>
>
Is BlobBuilder needed?
Hi everyone,
It was pointed out to me on twitter that BlobBuilder can be replaced
with simply making Blob constructable. I.e. the following code:
var bb = new BlobBuilder();
bb.append(blob1);
bb.append(blob2);
bb.append("some string");
bb.append(myArrayBuffer);
var b = bb.getBlob();
would become
b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
or look at it another way:
var x = new BlobBuilder();
becomes
var x = [];
x.append(y);
becomes
x.push(y);
var b = x.getBlob();
becomes
var b = new Blob(x);
So at worst there is a one-to-one mapping in code required to simply
have |new Blob|. At best it requires much fewer lines if the page has
several parts available at once.
And we'd save a whole class since Blobs already exist.
/ Jonas
Re: [selectors-api] Return an Array instead of a static NodeList
On Mon, Oct 24, 2011 at 3:02 PM, Cameron McCormack wrote: > On 24/10/11 12:14 PM, Jonas Sicking wrote: >> >> Based on my testing, many methods wouldn't throw for zero-size >> array-like objects. Similarly, methods like .push(), .unshift() and >> .slice() wouldn't throw if no entries were actually requested to be >> added or removed. And .reverse() wouldn't throw for single-sized >> array-like objects. >> >> May or may not be a big deal though. > > Yeah. IMO it's not. > > One thing that is difficult to reflect from the JS Array API to objects like > HTMLInputElements.files which we might want to make mutable is that the > former is designed to work with sparse arrays while we have typically > considered DOM collection/list objects as dense. > > myFileInput.files.length; // let's say this is 1 > myFileInput.files[2] = ...; // what does this mean? Indeed. Though I think we can deal with having holes. We'd just have to compact whenever the list was changed (in this case if the user modified the list of files). / Jonas
[Bug 14554] New: Consider adding support for contenteditable=plaintext
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14554 Summary: Consider adding support for contenteditable=plaintext Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: rn...@webkit.org QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org WebKit has been getting a lot of bugs reprots from developers who are trying to implement plaintext editable region. Facebook for example overlays invisible span on top of textarea to implement name highlighting. It'll be much better if UAs supported plaintext editable region (user can only insert plaintext but authors can insert rich content to highlight text, etc...). -- 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: WebSocket API: close and error events
On Mon, 24 Oct 2011, Tobias Oberstein wrote: > > Is executing step 2 above (fire "error") meant to cancel execution of step 3 > (fire "close")? No, it would say "...and abort these steps" if it did. > Specifically, which events should be fired when WS(S) connection > establishment fails due to: > > a) host unreachable (TCP could not even be established) > b) TLS handshake failed (thus TCP was there, but no TLS handshake, and thus > no WS handshake also) > c) TLS handshake failed due to invalid server certificate > d) TLS handshake failed for other reasons (invalid client cert, > non-acceptable ciphers, ..) All of these should be handled identically (for security reasons -- if we treat them differently you could use it to probe non-WebSocket servers on an intranet, for instance). > Practically, I am mostly interested in: > > How can I detect "TLS failed due to invalid server cert" from JavaScript > in the context of WSS. You cannot, by design. If we allowed JS to detect this it would enable attackers to do network topology scans of restricted networks. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [selectors-api] Return an Array instead of a static NodeList
On 24/10/11 12:14 PM, Jonas Sicking wrote: Based on my testing, many methods wouldn't throw for zero-size array-like objects. Similarly, methods like .push(), .unshift() and .slice() wouldn't throw if no entries were actually requested to be added or removed. And .reverse() wouldn't throw for single-sized array-like objects. May or may not be a big deal though. Yeah. IMO it's not. One thing that is difficult to reflect from the JS Array API to objects like HTMLInputElements.files which we might want to make mutable is that the former is designed to work with sparse arrays while we have typically considered DOM collection/list objects as dense. myFileInput.files.length;// let's say this is 1 myFileInput.files[2] = ...; // what does this mean?
WebSocket API: close and error events
I have two questions related to WebSocket API and close/error handling. Sorry for the long post .. need to give context for the questions first. == The WebSocket protocol draft (Hybi-17) http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17 defines a close code 1006 " 1006 is a reserved value and MUST NOT be set as a status code in a Close control frame by an endpoint. It is designated for use in applications expecting a status code to indicate that the connection was closed abnormally, e.g. without sending or receiving a Close control frame." Both Chrome (16.0.912.10 canary) and Firefox (10.0a1 (2011-10-24)) fire the onclose() event handler on the websocket object with code 1006 when the TCP connection to the target host of the WS cannot even be established (host unreachable). Firefox fires the onclose() event handler with 1006 also for WSS when the server certificate is invalid. Chrome currently does not check WSS server cert (unrelated beh./bug). The WebSocket API document http://dev.w3.org/html5/websockets/ says " When the WebSocket connection is closed, possibly cleanly, the user agent must queue a task to run the following substeps: 1. Change the readyState attribute's value to CLOSED (3). 2. If the user agent was required to fail the websocket connection or the WebSocket connection is closed with prejudice, fire a simple event named error at the WebSocket object. [WSP] 3. Create an event that uses the CloseEvent interface, with the event name close, which does not bubble, is not cancelable, has no default action, whose wasClean attribute is initialized to true if the connection closed cleanly and false otherwise, whose code attribute is initialized to the WebSocket connection close code, and whose reason attribute is initialized to the WebSocket connection close reason decoded as UTF-8, with error handling, and dispatch the event at the WebSocket object. " === Q1: Is executing step 2 above (fire "error") meant to cancel execution of step 3 (fire "close")? Q2: Specifically, which events should be fired when WS(S) connection establishment fails due to: a) host unreachable (TCP could not even be established) b) TLS handshake failed (thus TCP was there, but no TLS handshake, and thus no WS handshake also) c) TLS handshake failed due to invalid server certificate d) TLS handshake failed for other reasons (invalid client cert, non-acceptable ciphers, ..) Practically, I am mostly interested in: How can I detect "TLS failed due to invalid server cert" from JavaScript in the context of WSS. === I was on the Hybi list with similar questions, since I thought there might be a need for specific close codes for TLS failures, but was sent here. Here is the thread: http://www.ietf.org/mail-archive/web/hybi/current/msg09261.html http://www.ietf.org/mail-archive/web/hybi/current/msg09286.html and then: http://www.ietf.org/mail-archive/web/hybi/current/msg09291.html Am I on the right list here? ;)
Re: Disabling non-collapsed selection
Right, we would definitely don't want to provide yet another way to annoy users. I'm fine with (in fact I've been always inclined towards) not providing APIs for this. - Ryosuke On Mon, Oct 24, 2011 at 8:08 AM, Aryeh Gregor wrote: > (sorry for the delay in responding, I was on vacation for about ten days) > > On Sat, Oct 15, 2011 at 1:51 PM, Ryosuke Niwa wrote: > > Is there an interest in providing a way to prevent non-collapsed > selection > > under some node in a document? And if there is, what are use cases? > > Authors periodically file a WebKit bug against our implementation of > > selectstart event that they can't use it to disable selection. WebKit > > supports "-webkit-user-select: none" to do this but some authors > apparently > > want to allow collapsed selection. > > I personally don't quite understand why authors ever want to do this but > I'm > > not totally against the idea of providing new mechanism for this if there > > are good use cases. > > As far as I know, the use-case is to prevent users from copying text > easily. For instance, on this page: > > http://www.snopes.com/science/dhmo.asp > > Sites that have paid content only available to subscribers don't want > subscribers to copy text to other places. Also, sites that are > ad-supported might want users to come visit the original page (with > the ads) instead of reading the text elsewhere. Or authors might just > want credit for their work. > > There's no way we can stop authors from making things inconvenient for > users -- they could always call getSelection().collapseToStart() every > 50 ms or something. There's also no way we can stop users from > copying if they're determined -- they could save the HTML and copy > from there, say. I don't think we need to add features to the spec to > make it easier for authors to stop users from copying, because a lot > of authors will misuse them. I also don't personally think browsers > need to add features to make it easier for users to evade anti-copying > measures, because a lot of users will misuse them. The browser can't > decide what copying is good or bad, and shouldn't assume that the > author or the user is right. > > So I wouldn't worry about this much either way. I certainly don't > think a declarative feature to prevent all non-collapsed selections > (or all copying) is a good idea. A lot of authors are overprotective > of their content and would stop totally legitimate copying if given > the chance. >
[Bug 14364] Add an API to make appcache support caching specific URLs dynamically
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14364 Louis-Rémi changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NEEDSINFO | --- Comment #4 from Louis-Rémi 2011-10-24 19:52:37 UTC --- (In reply to comment #3) > Yeah we're definitely not using data: for this. > > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. > If > you have additional information and would like the editor to reconsider, > please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the tracker issue; or you may create a tracker issue > yourself, if you are able to do so. For more details, see this document: >http://dev.w3.org/html5/decision-policy/decision-policy.html > > Status: Did Not Understand Request > Change Description: no spec change > Rationale: What are the use cases for making appcache dynamic? (I'm not saying > there aren't any, I just need to know what they are to design the solution for > them.) Granted, using data isn't the best option. I've written an extensive blog post about the use cases for a dynamic appcache: http://www.louisremi.com/2011/10/07/offline-web-applications-were-not-there-yet/ tl;dr: if you build an rss reader with checkbox to make articles available offline, it's easy to store/delete the text content of the article at will using localStorage or indexedDb, but it's impossible to store/delete associated images (and sounds/videos). You could dynamically generate a cache manifest for all "offline enabled" articles, but the client would have to re-download all resources every-time the manifest is updated, as you know. (and you can't store images as data-uris, since they come from different origins) Mozilla implemented a simple "OfflineResourceList" API which solves that problem by enhancing applicationCache with "add()" and "remove()" methods. This is the kind of solution I am looking for, although "add" is a confusing name, since it should be able to update a particular resource too. There is a risk that this API could cause confusion amongst web developers. Should they use a cache manifest or abandon it completely in favor of the JS API? I believe the cache manifest should be advocated to be used for the application structure+presentation+logic (HTML, CSS, JS), while the dynamic API should be used for the application *content* (medias, xml, json). -- 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.
Postponed: Request for Review: Test cases for DOM L3 Events
Hi Alex - as I mentioned in [1], until the objections to the publication of a D3E CR are resolved I propose this RfR be postponed. -Regards, Art Barstow [1] http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0116.html On 10/14/11 1:49 PM, ext Alex Kuang wrote: We have submitted 21 test cases for DOM L3 Events using WebApps WG's test harness. They are now available here: http://w3c-test.org/webapps/DOMEvents/tests/submissions/Microsoft/converted/ Please consider this email our Request for Review (RfR) for the test cases listed below with a proposed deadline for comments of November 14. DOM.event.flow.html Determined.candidate.EventListeners.html Event.bubbles.false.html EventListener.dispatch.new.event.html EventListener.eventHandler.html EventObject.after.dispatchEvent.html EventObject.multiple.dispatchEvent.html ProcessingInstruction.DOMCharacterDataModified.html Propagation.path.target.moved.html Propagation.path.target.removed.html addEventListener.optional.useCapture.html createEvent.NOT_SUPPORTED_ERR.html dispatchEvent.DISPATCH_REQUEST_ERR.html dispatchEvent.NOT_SUPPORTED_ERR.html dispatchEvent.UNSPECIFIED_EVENT_TYPE_ERR.html dispatchEvent.click.checkbox.html dispatchEvent.return.value.html domnodeinserted.html stopImmediatePropagation.effect.html stopPropagation.deferred.effect.html stopPropagation.dispatchEvent.html Thanks, Alex
Re: CfC: publish a Candidate Recommendation of DOM 3 Events; deadline October 21
On Monday, 24 October 2011 at 20:33, Arthur Barstow wrote: > In Marcos Caceres' objection [Objection-2], he asserts some of the > overlaps and redundancies between D3E and DOM4 are confusing and > requests the D3E spec clarify its relationship to DOM4. I encourage > Marcos to work with the Editors on text and/or changes that clarify the > relationships. Happy to do that. However, I need to hear back from the editors if they agree or disagree with my comments and concerns.
Re: CfC: publish a Candidate Recommendation of DOM 3 Events; deadline October 21
Given the objections to this CfC, a publication request for CR will not be submitted. The group's next step will be to"endeavor to resolve" the objections as described in the Process Document [Consensus]. Ms2ger enumerates 3 points in his objection [Objection-1]. My expectation is that those supporting the CfC will respond to these points and both the D3E supporters and DOM4 supporters will work toward achieving a mutually agreeable position on them. In Marcos Caceres' objection [Objection-2], he asserts some of the overlaps and redundancies between D3E and DOM4 are confusing and requests the D3E spec clarify its relationship to DOM4. I encourage Marcos to work with the Editors on text and/or changes that clarify the relationships. This CfC created two additional points of contention: 1. Request by Alex Kuang to Review D3E test suites [RfR-D3E] 2. Request by Alex Kuang to add EventException support to WebApps' testharness.js [EventException] Until we have reached consensus on the spec issues, I propose these two requests be postponed and I will reply to those e-mail threads separately. I added a 16:00-17:00 agenda topic for D3E and DOM4 for WebApp's f2f meeting on Monday October 31 [Oct31-Agenda] -AB [Consensus] http://www.w3.org/2005/10/Process-20051014/policies.html#Consensus [Objection-1] http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0108.html [Objection-2] http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0111.html [RfR-D3E] http://lists.w3.org/Archives/Public/public-webapps-testsuite/2011Oct/0001.html [EventException] http://lists.w3.org/Archives/Public/public-webapps-testsuite/2011Oct/0002.html [Oct31-Agenda] http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Monday.2C_October_31 On 10/14/11 3:27 PM, ext Arthur Barstow wrote: The people working on the D3E spec (namely Jacob, Doug and Olli) propose below that the spec be published as a Candidate Recommendation and this is a CfC to do so: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html The comment tracking document for the last LCWD is: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/dc.html This CfC satisfies: a) the group's requirement to "record the group's decision to request advancement" to CR; and b) "General Requirements for Advancement on the Recommendation Track" as defined in the Process Document: http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs The exit criteria has not yet been added to the ED and I request the Editors to please propose the specific criteria in response to this e-mail before the comment deadline. It is my expectation that Microsoft and Mozilla will complete the test suite [TS] they started and they will implement this CR. As such, I assume the exit criteria will include a requirement that at least two independent implementations pass all of the test cases. As with all of our CfCs, positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is October 21 and all comments should be sent to www-dom at w3.org. -AB [TS] http://dvcs.w3.org/hg/webapps/file/tip/DOMEvents/tests/submissions Original Message Subject: Request for CfC to publish DOM Level 3 Events as a CR Date: Thu, 13 Oct 2011 03:11:52 + From: ext Jacob Rossi To: Arthur Barstow (art.bars...@nokia.com) , Charles McCathieNevile (cha...@opera.com) CC: Doug Schepers (schep...@w3.org) , www-...@w3.org Art and Charles, We'd like to request a Call for Consensus to publish DOM3 Events as a Candidate Recommendation. We believe the spec is ready for such publication on the following grounds: 1. Responses to Last Call issues have been documented in a published Disposition of Comments [1]. 2. At least two members are targeting implementations of this spec (Microsoft, Mozilla) 3. All changes since the Last Call draft have been editorial with the exception of: Revision 1.204 - this change was more of a clarification of intended behavior and it matches implementations. 4. In a recent Working Group teleconference, we've agreed on how to move forward with submitting and approving test cases for a suite (more on this subject to follow shortly). We recognize that there will always be new ideas for the event model--some great new ideas, such as event constructors, have recently been proposed. But we can't keep DOM3 Events in perpetual evolution. As such, I've prepared a rough proposal for a new specification to continue innovation in the event model (preliminarily titled "DOM4 Events" with event constructors as my first suggestion for scope). I believe such a spec can be written to extend and improve upon DOM3 Events in areas that are outside the scope of DOM4 (e.g., event constructors for interfaces outside the "DOM Event Architecture" and "Basic Event Interfaces" chapters of D3E). Doing so will give implementers a
Re: [selectors-api] Return an Array instead of a static NodeList
On Mon, Oct 24, 2011 at 11:57 AM, Cameron McCormack wrote: > On 24/10/11 11:51 AM, Jonas Sicking wrote: >> >> I think we have three types of array-like objects: >> >> 1. Objects like the one returned from getElementsByTagName where >> modifications to the array just doesn't make sense. >> 2. Objects like the one returned from HTMLInputElements.files where >> modifications to the array could be allowed and where such >> modifications affect the DOM (i.e. the submitted value would be >> changed) >> 3. Object like the one returned from findAll where modifications don't >> affect anything other than the mutated object. >> >> It appears to me that [ArrayClass] helps with case 2. > > Yes. > >> For case 3 I think we should simply return an Array. No need for >> anything more magic than that. > > Agreed. > >> Case 1 appears to be unaddressed though. And I actually think that's >> the most common case in the DOM right now. Or were we hoping that >> [ArrayClass] would be used there too and all mutating functions would >> throw? > > Yes that is the hope. I should run through the mutation function > definitions just to be sure. :) It is at least well defined. > > An alternative is to introduce a new prototype object in between > Array.prototype and the mutable array-like object that has properties > shadowing all of the mutating functions with a function that unconditionally > throws. I would prefer to avoid having to update the spec whenever new > Array.prototype methods are introduced in the ES spec if possible, though. Based on my testing, many methods wouldn't throw for zero-size array-like objects. Similarly, methods like .push(), .unshift() and .slice() wouldn't throw if no entries were actually requested to be added or removed. And .reverse() wouldn't throw for single-sized array-like objects. May or may not be a big deal though. / Jonas
Re: [selectors-api] Return an Array instead of a static NodeList
On 24/10/11 11:51 AM, Jonas Sicking wrote: I think we have three types of array-like objects: 1. Objects like the one returned from getElementsByTagName where modifications to the array just doesn't make sense. 2. Objects like the one returned from HTMLInputElements.files where modifications to the array could be allowed and where such modifications affect the DOM (i.e. the submitted value would be changed) 3. Object like the one returned from findAll where modifications don't affect anything other than the mutated object. It appears to me that [ArrayClass] helps with case 2. Yes. For case 3 I think we should simply return an Array. No need for anything more magic than that. Agreed. Case 1 appears to be unaddressed though. And I actually think that's the most common case in the DOM right now. Or were we hoping that [ArrayClass] would be used there too and all mutating functions would throw? Yes that is the hope. I should run through the mutation function definitions just to be sure. :) It is at least well defined. An alternative is to introduce a new prototype object in between Array.prototype and the mutable array-like object that has properties shadowing all of the mutating functions with a function that unconditionally throws. I would prefer to avoid having to update the spec whenever new Array.prototype methods are introduced in the ES spec if possible, though.
Re: [selectors-api] Return an Array instead of a static NodeList
On Mon, Oct 24, 2011 at 11:17 AM, Cameron McCormack wrote: > On 30/08/11 4:19 PM, Jonas Sicking wrote: >> >> Indeed! I think it's already been decided that all non-mutating >> functions should be added to NodeLists and other list-like DOM >> objects. I believe Cameron is still working on the specifics of that. > > Shortly before the LC#2 was published, I added an [ArrayClass] extended > attribute that you can put on interfaces that are not defined to inherit > from another. That causes that interface's [[Prototype]] to be > Array.prototype instead of Object.prototype. It's then up to the designer > of the interface to ensure that length and array index properties behave > usefully (by defining a length IDL attribute and using indexed properties) > so that the Array.prototype methods will do nice things. > > The other construct that uses Array.prototype is platform array objects. > They too have Array.prototype as their [[Prototype]]. Web IDL defines how > array index properties and length are exposed on platform array objects so > that they work with Array.prototype methods as best they can. I think we have three types of array-like objects: 1. Objects like the one returned from getElementsByTagName where modifications to the array just doesn't make sense. 2. Objects like the one returned from HTMLInputElements.files where modifications to the array could be allowed and where such modifications affect the DOM (i.e. the submitted value would be changed) 3. Object like the one returned from findAll where modifications don't affect anything other than the mutated object. It appears to me that [ArrayClass] helps with case 2. For case 3 I think we should simply return an Array. No need for anything more magic than that. Case 1 appears to be unaddressed though. And I actually think that's the most common case in the DOM right now. Or were we hoping that [ArrayClass] would be used there too and all mutating functions would throw? / Jonas
Re: [IndexedDB] IDBObjectStore.delete should accept a KeyRange
On Mon, Oct 24, 2011 at 10:17 AM, Israel Hilerio wrote: > On Wednesday, October 12, 2011 2:28 PM, Jonas Sicking wrote: >> Currently IDBObjectStore.count/get/openCursor and >> IDBIndex.count/get/openCursor/openKeyCursor all take a key or a KeyRange. >> However IDBObjectStore.delete only accepts keys. We should fix this to allow >> .delete to accept a KeyRange as well. >> >> / Jonas >> > > This makes sense to me. Is this something we still want to do? Yup, I think so. I was just waiting to hear back from others. I'll go ahead and make that change to the spec right away. / Jonas
Re: [selectors-api] Return an Array instead of a static NodeList
On 30/08/11 4:19 PM, Jonas Sicking wrote: Indeed! I think it's already been decided that all non-mutating functions should be added to NodeLists and other list-like DOM objects. I believe Cameron is still working on the specifics of that. Shortly before the LC#2 was published, I added an [ArrayClass] extended attribute that you can put on interfaces that are not defined to inherit from another. That causes that interface's [[Prototype]] to be Array.prototype instead of Object.prototype. It's then up to the designer of the interface to ensure that length and array index properties behave usefully (by defining a length IDL attribute and using indexed properties) so that the Array.prototype methods will do nice things. The other construct that uses Array.prototype is platform array objects. They too have Array.prototype as their [[Prototype]]. Web IDL defines how array index properties and length are exposed on platform array objects so that they work with Array.prototype methods as best they can.
RE: Indexed database API autoIncrement
On October 23, 2011 3:19 PM, Charles Pritchard wrote:
> On Oct 23, 2011, at 3:04 PM, Jonas Sicking wrote:
>
> > On Sun, Oct 23, 2011 at 4:20 AM, Futomi Hatano wrote:
> >> Hello everyone,
> >>
> >> I'm not a W3C member, can I send a mail to the list?
> >
> > Absolutely! This is a public list intended for just that!
> >
> >> I've tried to use Indexed database API using IE10 PP3 and Chrome 16 dev.
> >> I found a different behavior between the two.
> >> I set autoIncrement to true when I created a Object Store as below.
> >>
> >> var store = db.createObjectStore(store_name, { keyPath: 'id',
> >> autoIncrement: true });
> >>
> >> Then, I added some records.
> >>
> >> IE10 PP3 set the key value of the first recored to 0, while Chrome 16 set
> >> it
> to 1.
> >> Which is correct?
> >> I couldn't find the definition about this in the spec.
> >> The first value of autoIncrement should be defined in the spec, or
> >> the spec should allow us to set the first value of autoIncrement, I think.
> >>
> >> Sorry in advance if the discussion has already been done.
> >> Thank you for your time.
> >
> > Good catch! This definitely needs to be specified in the spec.
> >
> > I have a weak preference for using 1. This has a smaller risk of
> > triggering edge cases in the client code since it's always truthy.
> > I.e. if someone tries to detect the presence of an id, they won't fail
> > due to the id being 0.
>
> I agree -- this is also the behavior in all DBMS I've worked with. There's
> time
> for MS to update their implementation. All around win.
We are aware of the issue and we're looking to fix the problem to be
interoperable.
Thanks for the feedback.
Israel
Re: Reminder: RfC: Last Call Working Draft of Web IDL; deadline October 18
Travis Leithead: Is there a comment tracking doc for this LC (e.g., lc2)? Art Barstow: I don't see one in CVS. (I think Cameron returns soon though.) I have begun tracking these comments now: http://dev.w3.org/2006/webapi/WebIDL/lc2.txt
RE: [IndexedDB] transaction order
On Friday, October 14, 2011 6:42 PM, Jonas Sicking wrote:
> On Fri, Oct 14, 2011 at 1:51 PM, Israel Hilerio
> wrote:
> > On Friday, October 07, 2011 4:35 PM, Israel Hilerio wrote:
> >> On Friday, October 07, 2011 2:52 PM, Jonas Sicking wrote:
> >> > Hi All,
> >> >
> >> > There is one edge case regarding transaction scheduling that we'd
> >> > like to get clarified.
> >> >
> >> > As the spec is written, it's clear what the following code should do:
> >> >
> >> > trans1 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
> >> > trans1.objectStore("foo").put("value 1", "mykey");
> >> > trans2 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
> >> > trans2.objectStore("foo").put("value 2", "mykey");
> >> >
> >> > In this example it's clear that the implementation should first run
> >> > trans1 which will put the value "value 1" in object store "foo" at
> >> > key "mykey". The implementation should then run trans2 which will
> >> > write overwrite the same value with "value 2". The end result is
> >> > that "value 2" is the value that lives in the object store.
> >> >
> >> > Note that in this case it's not at all ambiguous which transaction runs
> first.
> >> > Since the two transactions have overlapping scope, trans2 won't
> >> > even start until trans1 is committed. Even if we made the code something
> like:
> >> >
> >> > trans1 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
> >> > trans1.objectStore("foo").put("value 1", "mykey");
> >> > trans2 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
> >> > trans2.objectStore("foo").put("value 2", "mykey");
> >> > trans1.objectStore("foo").put("value 3", "mykey");
> >> >
> >> > we'd get the same result. Both put requests placed against trans1
> >> > will run first while trans2 is waiting for trans1 to commit before
> >> > it begins running since they have overlapping scopes.
> >> >
> >> > However, consider the following example:
> >> > trans1 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
> >> > trans2 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
> >> > trans2.objectStore("foo").put("value 2", "mykey");
> >> > trans1.objectStore("foo").put("value 1", "mykey");
> >> >
> >> > In this case, while trans1 is created first, no requests are placed
> >> > against it, and so no database operations are started. The first
> >> > database operation that is requested is one placed against trans2.
> >> > In the firefox implementation, this makes trans2 run before trans1. I.e.
> >> > we schedule transactions when the first request is placed against
> >> > them, and not when the IDBDatabase.transaction() function returns.
> >> >
> >> > The advantage of firefox approach is obvious in code like this:
> >> >
> >> > someElement.onclick = function() {
> >> > trans1 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
> >> > ...
> >> > trans2 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
> >> > trans2.objectStore.put("some value", "mykey");
> >> > callExpensiveFunction();
> >> > }
> >> >
> >> > In this example no requests are placed against trans1. However
> >> > since
> >> > trans1 is supposed to run before trans2 does, we can't send off any
> >> > work to the database at the time when the .put call happens since
> >> > we don't yet know if there will be requests placed against trans1.
> >> > Only once we return to the event loop at the end of the onclick
> >> > handler will
> >> trans1 be "committed"
> >> > and the requests in trans2 can be sent to the database.
> >> >
> >> > However, the downside with firefox approach is that it's harder for
> >> > applications to control which order transactions are run. Consider
> >> > for example a program is parsing a big hunk of binary data. Before
> >> > parsing, the program starts two transactions, one READ_WRITE and
> >> > one READ_ONLY. As the binary data is interpreted, the program
> >> > issues write requests against the READ_WRITE transactions and read
> >> > requests against the READ_ONLY transaction. The idea being that the
> >> > read requests will always run after the write requests to read from
> >> > database after all the parsed data has been written. In this setup
> >> > the firefox approach isn't as good since it's less predictable
> >> > which transaction will run first as it might depend on the binary
> >> > data being parsed. Of course, you could force the writing
> >> > transaction to run first by placing a request
> >> against it after it has been created.
> >> >
> >> > I am however not able to think of any concrete examples of the
> >> > above binary data structure that would require this setup.
> >> >
> >> > So the question is, which solution do you think we should go with.
> >> > One thing to remember is that there is a very small difference
> >> > between the two approaches here. It only makes a difference in edge
> >> > cases. The edge case being that a transaction is created, but no
> >> > requests are placed against it until another transaction, with
> >> > overlapp
RE: [IndexedDB] IDBObjectStore.delete should accept a KeyRange
On Wednesday, October 12, 2011 2:28 PM, Jonas Sicking wrote: > Currently IDBObjectStore.count/get/openCursor and > IDBIndex.count/get/openCursor/openKeyCursor all take a key or a KeyRange. > However IDBObjectStore.delete only accepts keys. We should fix this to allow > .delete to accept a KeyRange as well. > > / Jonas > This makes sense to me. Is this something we still want to do? Israel
Re: CfC: publish a Candidate Recommendation of DOM 3 Events; deadline October 21
On Fri, Oct 21, 2011 at 4:42 PM, Ms2ger wrote: > However, *I do object to the publication* of this specification because the > inappropriate resolution of the following issues (in no particular order): > > First (issue 123), it contradicts an uncontested requirement [1] in DOM4 > forbidding the minting of new DOM feature strings, as reported by Anne. [2] > > Second (issue 179), it ignores the consensus about using DOMException > instead of custom exception types like EventException, as noted in WebIDL, > [3] which I reported. [4] > > Third (issue 130), the resolution made to add an informative WebIDL appendix > is insufficient. Not only did the editors not list any technical reason for > this decision in their reply, [5] despite this being required by the Process > document. [6] I agree with all three of these objections, and don't think the specification should progress to CR unless they're fixed.
Re: Disabling non-collapsed selection
On Mon, Oct 24, 2011 at 11:08 AM, Aryeh Gregor wrote: > As far as I know, the use-case is to prevent users from copying text > easily. . . . although on second thought, why would authors want to allow collapsed selections, then? Maybe I'm just confused.
Re: Disabling non-collapsed selection
(sorry for the delay in responding, I was on vacation for about ten days) On Sat, Oct 15, 2011 at 1:51 PM, Ryosuke Niwa wrote: > Is there an interest in providing a way to prevent non-collapsed selection > under some node in a document? And if there is, what are use cases? > Authors periodically file a WebKit bug against our implementation of > selectstart event that they can't use it to disable selection. WebKit > supports "-webkit-user-select: none" to do this but some authors apparently > want to allow collapsed selection. > I personally don't quite understand why authors ever want to do this but I'm > not totally against the idea of providing new mechanism for this if there > are good use cases. As far as I know, the use-case is to prevent users from copying text easily. For instance, on this page: http://www.snopes.com/science/dhmo.asp Sites that have paid content only available to subscribers don't want subscribers to copy text to other places. Also, sites that are ad-supported might want users to come visit the original page (with the ads) instead of reading the text elsewhere. Or authors might just want credit for their work. There's no way we can stop authors from making things inconvenient for users -- they could always call getSelection().collapseToStart() every 50 ms or something. There's also no way we can stop users from copying if they're determined -- they could save the HTML and copy from there, say. I don't think we need to add features to the spec to make it easier for authors to stop users from copying, because a lot of authors will misuse them. I also don't personally think browsers need to add features to make it easier for users to evade anti-copying measures, because a lot of users will misuse them. The browser can't decide what copying is good or bad, and shouldn't assume that the author or the user is right. So I wouldn't worry about this much either way. I certainly don't think a declarative feature to prevent all non-collapsed selections (or all copying) is a good idea. A lot of authors are overprotective of their content and would stop totally legitimate copying if given the chance.
[Bug 14455] When tapping within a contenteditable, mobile browsers display a VKB that hogs the screen. But what if users don't want to enter any new text? They might instead make a selection, copy
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14455 Aryeh Gregor changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Aryeh Gregor 2011-10-24 14:56:02 UTC --- This doesn't seem like a strong enough use-case to justify a new mode for contenteditable at this point. There are lots of other things that are much more important. Also, the mobile browser could be smart enough to not pop up the virtual keyboard if you're making a selection, dragging something, etc., and we don't need to change the spec for that. Thanks for your suggestion, though. Please reopen if you think there's something I've missed. -- 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.
[Bug 14455] When tapping within a contenteditable, mobile browsers display a VKB that hogs the screen. But what if users don't want to enter any new text? They might instead make a selection, copy
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14455 Aryeh Gregor changed: What|Removed |Added CC||a...@aryeh.name, ||public-webapps@w3.org Component|HTML5 spec (editor: Ian |HTML Editing APIs |Hickson)| AssignedTo|i...@hixie.ch|a...@aryeh.name Product|HTML WG |WebAppsWG Summary|When tapping within a |When tapping within a |contenteditable, mobile |contenteditable, mobile |browsers display a VKB that |browsers display a VKB that |hogs the screen. But what |hogs the screen. But what |if users don't want to |if users don't want to |enter any new text? They |enter any new text? They |might instead make a|might instead make a |selection, copy it, drag to |selection, copy it, drag to |move it, format it |move it, format it, or ||paste in something else. ||Ideally Summary|or paste in something else. | | Ideally| QAContact|public-html-bugzi...@w3.org |sideshowbarker+html-editing ||-a...@gmail.com -- 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.
