FW: TPAC Web App
From: ext Dominique Hazael-Massieux [d...@w3.org] Sent: Monday, October 31, 2011 9:25 AM To: w...@w3.org; cha...@w3.org Subject: TPAC Web App Dear all, For those of you at TPAC, you may want to use the companion Web app to the event available at: http://www.w3.org/2011/11/TPAC/live/ and let others know about it. That Web app lets you access the schedule of the week, pick which meetings you plan on attending to build your own schedule, and let others know in what meetings room you are currently setting via check-in, as well as orient yourself in the meeting facilities. It also features the list of registrants and their organizations to facilitate establishing contacts. This is very much an alpha-release of the tool, but we hope that you'll find useful during the week; learn more about the tool and the team behind it at http://www.w3.org/2011/11/TPAC/live/about Dom
Re: Enable compression of a blob to .zip file
On 10/30/2011 5:56 PM, Cameron McCormack wrote: On 30/10/11 4:25 PM, Bjoern Hoehrmann wrote: Then he probably means file system files and not HTTP files, and support there has indeed been spotty in the past. Ah, yes. Regarding data: URIs, someone should really just amend the RFC to allow specifying a content encoding. That seems rather unnecessary. I'm almost certain that somewhere, it is specified that the browser should sniff the first few bytes of the file to see if it is compressed. It's minimal work. This also applies to the local file system; as in file:///.
Re: Enable compression of a blob to .zip file
On Oct 31, 2011, at 10:42 AM, Charles Pritchard wrote: On 10/30/2011 5:56 PM, Cameron McCormack wrote: On 30/10/11 4:25 PM, Bjoern Hoehrmann wrote: Then he probably means file system files and not HTTP files, and support there has indeed been spotty in the past. Ah, yes. Regarding data: URIs, someone should really just amend the RFC to allow specifying a content encoding. That seems rather unnecessary. I'm almost certain that somewhere, it is specified that the browser should sniff the first few bytes of the file to see if it is compressed. It's minimal work. Work in progress: http://mimesniff.spec.whatwg.org/ mh
Re: Enable compression of a blob to .zip file
On 31/10/11 10:50 AM, Mike Hanson wrote: Work in progress: http://mimesniff.spec.whatwg.org/ There's a section on Images in there which looks like it won't do sniffing for automatic gunzipping. Although perhaps if the SVG document were used as the top level document it would be, if it falls under the Web Pages case.
Re: Enable compression of a blob to .zip file
On 10/31/11 1:42 PM, Charles Pritchard wrote: I'm almost certain that somewhere, it is specified that the browser should sniff the first few bytes of the file to see if it is compressed. I don't believe it is. In fact, doing that would contradict the specs as they stand, to my knowledge. I could be wrong, of course, but in that case citation needed... -Boris
WebSocket treated as subresource: no HTTP auth dialogs?
On a different thread, Adam Barth clarified that WebSocket connections established from JS should be treated as subresources in the context of the JS containing page. As a consequence, no browser built-in dialogs should be rendered which offer the user a chance to act upon i.e. untrusted TLS server certificates when the WebSocket connection is via TLS (wss). Now, how does that translate to HTTP authentication? What if the WS connection requires HTTP authentication? When the WS is treated as a subresource, does that mean that no authentication dialog should be presented to the user for that? Note, that this is a problem only when the WS connection is to a different host/port than the JS containing page was served from, which might be quite common in practice. However, should above be the case (no auth dialog rendered), that may come as a surprise to some in the WS community, since all discussions for WS auth mechanisms were always ended by: you have any HTTP auth there if you need. The same question applies to HTTP basic/digest auth as well as TLS client cert auth. No dialog?
Re: Enable compression of a blob to .zip file
On 10/31/11 11:34 AM, Boris Zbarsky wrote: On 10/31/11 1:42 PM, Charles Pritchard wrote: I'm almost certain that somewhere, it is specified that the browser should sniff the first few bytes of the file to see if it is compressed. I don't believe it is. In fact, doing that would contradict the specs as they stand, to my knowledge. I could be wrong, of course, but in that case citation needed... -Boris Well I've failed to find a citation. I will post one if I find it. In the meantime: Blob and Data uris can and should have sniffing for image/svg+xml. It's trivial, and it makes a whole lot more sense than extending both the Blob and data uri specs to include transfer encoding semantics. file: and filesystem: and widget urls are items that -might- be supported on an OS level, and thus out of scope here. Back to deflate use cases: PDF.js I'm sure implements deflate (for PDF FlateEncode), I've recently done some docx work which required deflate. Many servers do not host .svgz files well, and I use XHR with deflate to deal with that (though I would have just used blob urls if they worked). localStorage, indexedDB and WebSQL all require DOMString, as do most WebSocket implementations -- in practical use, this means base64 encoding data. It's another area where deflate could squeeze a few more bytes out of existing constraints. Especially with localStorage. As we continue to support more-and-more document formats, deflate support on the client side becomes more important. Apple and MS, two very large vendors, have pushed ahead with using deflate in various file formats they use. Adobe has been doing it for some time. Though HTTP works quite well for negotiated compression there are more and more cases that are not http bound. I would very much like to see deflate and inflate exposed to the scripting environment. From there I can easily interact with several file formats. Zip included. -Charles -Charles
Re: QSA, the problem with :scope, and naming
On Fri, Oct 21, 2011 at 12:41 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Oct 20, 2011 at 2:33 PM, Lachlan Hunt lachlan.h...@lachy.id.au
wrote:
Not necessarily. It depends what exactly it means for a selector to
contain
:scope for determining whether or not to enable the implied :scope
behaviour. Consider:
foo.find(:not(:scope));
Ooh, this is an interesting case too. So here's the full list of cases which
we need defined behavior for (again looking at Alex and Yehuda here).
In the following DOM
body id=3
div id=0/div
div id=context foo=bar
div id=1/div
div class=class id=2/div
div class=withChildren id=3div class=child id=4/div/div
/div
div id=5/div
div id=6/div
/body
What would each of the following .findAll calls return. I've included my
guessed based on the discussions so far:
var e = document.getElementById('context');
e.findAll(div) // returns ids 1,2,3,4
e.findAll() // returns an empty list
e.findAll(#3) // returns id 3, but not the body node
e.findAll( div) // returns ids 1,2,3
e.findAll([foo=bar]) // returns nothing
e.findAll([id=1]) // returns id 1
e.findAll(:first-child) // returns id 1
e.findAll(+ div) // returns id 5
e.findAll(~ div) // returns id 5, 6
e.findAll(:scope)
Returns the context.
e.findAll(div:scope)
Returns the context.
e.findAll([foo=bar]:scope)
Returns the context.
e.findAll(:scope div)
1, 2, 3, 4
e.findAll(div:scope div)
1, 2, 3, 4
e.findAll(div:scope #3)
3
e.findAll(body :scope div)
1, 2, 3, 4
e.findAll(div, :scope)
context, 1, 2, 3, 4
e.findAll(body :scope div, :scope)
context, 1, 2, 3, 4
e.findAll(:not(:scope))
empty set
Re: QSA, the problem with :scope, and naming
What Tab said = ) On Sun, Oct 30, 2011 at 9:23 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sat, Oct 29, 2011 at 8:28 PM, Cameron McCormack c...@mcc.id.au wrote: On 20/10/11 3:50 AM, Alex Russell wrote: I strongly agree that it should be an Array *type*, but I think just returning a plain Array is the wrong resolution to our NodeList problem. WebIDL should specify that DOM List types *are* Array types. It's insane that we even have a NodeList type which isn't a real array at all. Adding a parallel system when we could just fix the one we have (and preserve the value of a separate prototype for extension) is wonky to me. That said, I'd *also* support the ability to have some sort of decorator mechanism before return on .find() or a way to re-route the prototype of the returned Array. +heycam to debate this point. Late replying here again, apologies, but I agree with others who say that an actual Array object should be returned from this new API given that it is not meant to be live. What benefit is there from returning a NodeList? If it's a NodeList (or something else that *subclasses* Array) we can do fun things like add .find to it, which returns the sorted union of calling .find on all the elements within it. Returning a plain Array doesn't let us do that. ~TJ
Re: QSA, the problem with :scope, and naming
On Sun, Oct 30, 2011 at 1:23 PM, Rick Waldron waldron.r...@gmail.com wrote: On Sat, Oct 29, 2011 at 11:28 PM, Cameron McCormack c...@mcc.id.au wrote: On 20/10/11 3:50 AM, Alex Russell wrote: I strongly agree that it should be an Array *type*, but I think just returning a plain Array is the wrong resolution to our NodeList problem. WebIDL should specify that DOM List types *are* Array types. It's insane that we even have a NodeList type which isn't a real array at all. Adding a parallel system when we could just fix the one we have (and preserve the value of a separate prototype for extension) is wonky to me. That said, I'd *also* support the ability to have some sort of decorator mechanism before return on .find() or a way to re-route the prototype of the returned Array. +heycam to debate this point. Late replying here again, apologies, but I agree with others who say that an actual Array object should be returned from this new API given that it is not meant to be live. What benefit is there from returning a NodeList? As much as I hate saying this: introducing a third return type would be counter-productive, as you'd now have live NodeList, static NodeList and subclassed Array. Congratulations, the cluster-f*ck continues in true form. Live NodeList instances don't need to be considered here. They're the result of an API which generates them, and that API can be described in terms of Proxies. No need to complicate NodeList or imply that we need a different type. Making NodeList instances real array unifies them all. We can get that done too.
Re: QSA, the problem with :scope, and naming
On 31/10/11 1:56 PM, Alex Russell wrote: Live NodeList instances don't need to be considered here. They're the result of an API which generates them, and that API can be described in terms of Proxies. No need to complicate NodeList or imply that we need a different type. Making NodeList instances real array unifies them all. We can get that done too. Don't live and static NodeLists use the same prototype? If they are separate, I don't see any problem with making them real arrays, but I am not sure what the implications of that are. Array.isArray == true, I guess? Do we have that ability within the bounds of ECMAScript yet? Note that we can already make NodeList.prototype === Array.prototype if we want, using appropriate Web IDL annotations.
Re: QSA, the problem with :scope, and naming
On 10/31/11 2:03 PM, Cameron McCormack wrote:
On 31/10/11 1:56 PM, Alex Russell wrote:
Live NodeList instances don't need to be considered here. They're the
result of an API which generates them, and that API can be described
in terms of Proxies. No need to complicate NodeList or imply that we
need a different type.
Making NodeList instances real array unifies them all. We can get
that done too.
Don't live and static NodeLists use the same prototype? If they are
separate, I don't see any problem with making them real arrays, but
I am not sure what the implications of that are. Array.isArray ==
true, I guess? Do we have that ability within the bounds of
ECMAScript yet? Note that we can already make NodeList.prototype ===
Array.prototype if we want, using appropriate Web IDL annotations.
Array seems to work fine in WebKit:
document.getElementsByTagName('div').__proto__.__proto__ = Array.prototype;
dojo just reimplements NodeList as an array:
http://dojotoolkit.org/reference-guide/dojo/NodeList.html
I don't understand what real array means, other than the prototype
equivalence.
If NodeList were an array, what's the behavior of running push on NodeList?
The list may end up with non-node objects if push is not supplemented.
-Charles
Re: QSA, the problem with :scope, and naming
Ok, so we're down to not having full agreement on the following selectors: On Mon, Oct 31, 2011 at 1:55 PM, Alex Russell slightly...@google.com wrote: On Fri, Oct 21, 2011 at 12:41 AM, Jonas Sicking jo...@sicking.cc wrote: e.findAll(body :scope div) 1, 2, 3, 4 e.findAll(body :scope div, :scope) context, 1, 2, 3, 4 I'm hoping that you just made a mistake here? 4 isn't a child of the context node. So in both of these I would think that 4 should be removed based on your answers to the other questions. e.findAll(div, :scope) context, 1, 2, 3, 4 Yehuda had a very different suggestion here but so far hasn't motivated why. Personally I think Alex answer is the more useful one. We just need to decide on something e.findAll(:not(:scope)) empty set Again, Yehuda had a different answer here. Though in this case I think Yehuda's answer is more useful and consistent. But I'm all ears for what the logic used to get to your answer and why you think this is a better (more consistent? more useful?) answer. / Jonas
[IndexedDB] Throwing when *creating* a transaction
Hi guys,
Currently the spec contains the following sentence:
Conforming user agents must automatically abort a transaction at the
end of the scope in which it was created, if an exception is
propagated to that scope.
This means that the following code:
setTimeout(function() {
doStuff();
throw booo;
}, 10);
function doStuff() {
var trans = db.transaction([store1], IDBTransaction.READ_WRITE)
trans.objectStore(store1).put({ some: value }, 5);
}
is supposed to abort the transaction. I.e. since the same callback (in
this case a setTimeout callback) which created the transaction later
on throws, the spec says to abort the transaction. This was something
that we debated a long time ago, but my recollection was that we
should not spec this behavior. It appears that this was never removed
from the spec though.
One reason that I don't think that we should spec this behavior is
that it's extremely tedious and error prone to implement. At every
point that an implementation calls into javascript, the implementation
has to add code which checks if an exception was thrown and if so,
check if any transactions were started, and if so abort them.
I'd like to simply remove this sentence. Any objections?
Note, this does *not* affect the aborting that happens if an exception
is thrown during a success or error event handler.
/ Jonas
Re: QSA, the problem with :scope, and naming
On 31/10/11 2:18 PM, Charles Pritchard wrote: I don't understand what real array means, other than the prototype equivalence. There's also the [[DefineOwnProperty]] behaviour which is different from normal objects. That kind of behaviour doesn't *need* to be handled by making NodeLists real arrays, it can be done by making them proxies. Some people might prefer not to do require that though, if it is indeed possible to make them real arrays.
[Bug 12510] Specs split off from HTML5 (like WebSockets) need to have xrefs linked, otherwise they're ambiguous
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12510 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Comment #11 from Ian 'Hixie' Hickson i...@hixie.ch 2011-10-31 22:47:58 UTC --- I have no intention of adding cross-spec cross-references to the WebSocket spec. If someone is interested in providing patches to the spec splitter to do this, please contact me directly. -- 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 14474] Make it possible to close a connection in such a manner that all subsequent events are suppressed
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14474 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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: QSA, the problem with :scope, and naming
On Mon, Oct 31, 2011 at 2:03 PM, Cameron McCormack c...@mcc.id.au wrote: On 31/10/11 1:56 PM, Alex Russell wrote: Live NodeList instances don't need to be considered here. They're the result of an API which generates them, and that API can be described in terms of Proxies. No need to complicate NodeList or imply that we need a different type. Making NodeList instances real array unifies them all. We can get that done too. Don't live and static NodeLists use the same prototype? Yes, I envision they would. The restrictions on live lists are probably going to be created by a proxy that wraps them and manages their semantics. If they are separate, I don't see any problem with making them real arrays, but I am not sure what the implications of that are. Array.isArray == true, I guess? For JS, it just means having a working .length property (in all the ways that Arrays allow it to be used). Arrays are identical to other objects in all other respects. Do we have that ability within the bounds of ECMAScript yet? Note that we can already make NodeList.prototype === Array.prototype if we want, using appropriate Web IDL annotations. We'll need ES 6 proxies to get the working .length thing today. Not ideal.
Re: QSA, the problem with :scope, and naming
On Mon, Oct 31, 2011 at 2:18 PM, Charles Pritchard ch...@jumis.com wrote:
On 10/31/11 2:03 PM, Cameron McCormack wrote:
On 31/10/11 1:56 PM, Alex Russell wrote:
Live NodeList instances don't need to be considered here. They're the
result of an API which generates them, and that API can be described
in terms of Proxies. No need to complicate NodeList or imply that we
need a different type.
Making NodeList instances real array unifies them all. We can get that
done too.
Don't live and static NodeLists use the same prototype? If they are
separate, I don't see any problem with making them real arrays, but I am
not sure what the implications of that are. Array.isArray == true, I guess?
Do we have that ability within the bounds of ECMAScript yet? Note that we
can already make NodeList.prototype === Array.prototype if we want, using
appropriate Web IDL annotations.
Array seems to work fine in WebKit:
document.getElementsByTagName('div').__proto__.__proto__ = Array.prototype;
dojo just reimplements NodeList as an array:
http://dojotoolkit.org/reference-guide/dojo/NodeList.html
The reason we did it that way is because there's no other way to
create an intermediate type with the magic .length property.
I don't understand what real array means, other than the prototype
equivalence.
If NodeList were an array, what's the behavior of running push on NodeList?
The list may end up with non-node objects if push is not supplemented.
-Charles
Re: [IndexedDB] Throwing when *creating* a transaction
On Mon, Oct 31, 2011 at 3:02 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi guys,
Currently the spec contains the following sentence:
Conforming user agents must automatically abort a transaction at the
end of the scope in which it was created, if an exception is
propagated to that scope.
This means that the following code:
setTimeout(function() {
doStuff();
throw booo;
}, 10);
function doStuff() {
var trans = db.transaction([store1], IDBTransaction.READ_WRITE)
trans.objectStore(store1).put({ some: value }, 5);
}
is supposed to abort the transaction. I.e. since the same callback (in
this case a setTimeout callback) which created the transaction later
on throws, the spec says to abort the transaction. This was something
that we debated a long time ago, but my recollection was that we
should not spec this behavior. It appears that this was never removed
from the spec though.
One reason that I don't think that we should spec this behavior is
that it's extremely tedious and error prone to implement. At every
point that an implementation calls into javascript, the implementation
has to add code which checks if an exception was thrown and if so,
check if any transactions were started, and if so abort them.
I'd like to simply remove this sentence. Any objections?
No objections here. Chrome doesn't currently implement this behavior.
Note, this does *not* affect the aborting that happens if an exception
is thrown during a success or error event handler.
/ Jonas
Re: QSA, the problem with :scope, and naming
On 10/31/11 7:25 PM, Alex Russell wrote: For JS, it just means having a working .length property (in all the ways that Arrays allow it to be used). Arrays are identical to other objects in all other respects. No, they're not. For example, off the top of my head, they get serialized differently by JSON.stringify. Note that this is based off of the [[Class]] (ES5 section 15.12.3 definition of Str() item 10a). So if you want your object to behave like an array for JSON serialization, it needs to have the right [[Class]]. I'd bet money there are other such things in ES5, for what it's worth. We'll need ES 6 proxies to get the working .length thing today. Not ideal. I think we should just start assuming ES 6 proxies or equivalent mechanism. It's needed for all sorts of stuff and UAs are implementing it anyway. If we want to avoid assuming it, we could just specify things in terms of ES5 internal classes and hooks. -Boris
Re: QSA, the problem with :scope, and naming
On 10/31/11 7:25 PM, Alex Russell wrote: For JS, it just means having a working .length property (in all the ways that Arrays allow it to be used). Arrays are identical to other objects in all other respects. No, they're not. For example, off the top of my head, they get serialized differently by JSON.stringify. Note that this is based off of the [[Class]] (ES5 section 15.12.3 definition of Str() item 10a). So if you want your object to behave like an array for JSON serialization, it needs to have the right [[Class]]. I'd bet money there are other such things in ES5, for what it's worth. Structured cloning fails for NodeList, same as postMessage, because of circular structure. With .join, you get the .toString of the DOM Nodes. There is no JSON serialization for DOM elements.
Re: QSA, the problem with :scope, and naming
On 10/31/11 9:32 PM, Charles Pritchard wrote: Structured cloning fails for NodeList, same as postMessage, because of circular structure. What circular structure? Structured clone can handle that. It fails because it's a host object (based on its [[Class]]) that's not whitelisted in the structured clone algorithm. With .join, you get the .toString of the DOM Nodes. Yes, as you would for an array of DOM nodes. A quick skim through the ES spec shows that Array.prototype.concat also considers the [[Class]] of its arguments, by the way. And indeed, this testcase: script var l = document.getElementsByTagName(html); var a = Array.prototype.slice.call(l); l.__proto__.__proto__ = Array.prototype; var test1 = [].concat(l); var test2 = [].concat(a); alert(test1[0] instanceof HTMLHtmlElement); alert(test2[0] instanceof HTMLHtmlElement); /script alerts false followed by true in UAs. So we really do need to decide what it means for a return value to be an Array. For example, how does it behave with concat()? -Boris
