Re: [IndexedDB] Closing on bug 9903 (collations)
The more I think about it, the more I want a user-specified comparison function. Efficiency should not be an issue here - the engines should tweek the JIT compiler to fix any efficiency issues. Just let the user pass a closure (remember functions are first-class in JavaScript so this is not a callback nor an event). Keean. On 2 May 2011 19:57, Aryeh Gregor simetrical+...@gmail.com wrote: On Fri, Apr 29, 2011 at 3:19 PM, Keean Schupke ke...@fry-it.com wrote: As long as we have a binary mode I am happy. Something I didn't think to mention: what exactly is binary mode for DOMStrings? I guess it means you encode as big-endian UTF-16, then sort bytewise? This is kind of evil, but it matches what sort() does, so I guess it should be the required behavior. (It's kind of evil because it doesn't match code-point order, unlike if you encoded as UTF-8. E.g., U+1 is encoded as 0xd800dc00 and U+E000 is 0xe000, so U+E000 sorts after U+1.) Perhaps this should be spelled out more clearly in the spec.
Re: [widgets] Widget Updates tests?
Scott Wilson wrote:
Just one more thing...
Test ta-processing2-14, Tests that update-info element's src attribute need to be
valid, else it is ignored. The widget is not updated or replaced.
However, the value to fail with is fail.wgt which ought to be interpreted as
a relative URL, in which case the expected result would be to turn this into:
http://people.opera.com/harig/wupdres/resources/fail.wgt
Which is valid.
So, the test needs to have a different value to be an invalid src attribute.
Missed this one - it has been fixed and the src attribute has been set
to an invalid IRI (':') as required.
- Rich
Re: paste events and HTML support - interest in exposing a DOM tree?
On Tue, 03 May 2011 07:10:10 +0900, João Eiras joao.ei...@gmail.com wrote: event.clipboardData.getDocumentFragment() which would return a parsed and when applicable sanitized view of any markup the implementation supports from the clipboard. This is already covered by doing x=createElement;x.innerHTML=foo;traverse x Of course it is. The point was simply to see if there was interest in possibly optimising away an extra serialize-parse roundtrip, if developers feel it would be more convenient to get the DOM right away rather than the markup. Regarding simplifying the pasted html to remove stuff that could be malicious, consider a rogue app that injects a script in the clipboard and expects the user to hit paste on his bank site. Well, I've never seen a bank site with a rich text editor / contentEditable-based feature customers are meant to use ;-) Rouge scripts and social engineering to paste them in the comment field on Facebook is still a threat to worry about. If the implementation knows that the content originates from another website it should definitely be sanitized. I don't think it adds much security to sanitise content from a local application though - an application running locally already has quite a lot of possibilities, for example to tell the browser to launch a javascript: URL directly or go into the DOM to modify things through the browser's accessibility APIs. Using social engineering to make the user paste something would be an awkward way to try to launch an exploit, no? There is little the user agent can do but to provide quick and easy methods to sanatize this. There is already the toStaticHTML API that IE implements. I'm planning to *not* leave sanitization to the script author, but have it as a default and (currently) non-overridable mode for cross-origin HTML paste. So the user-agent will do it all behind the scenes before the script event gets to see a single tag of the markup. I would suggest supporting and implementing it. Or even add a sister property of innerHTML, innerStaticHTML which would not return scripts or event handlers on reading, and would parse out those when setting. That sounds like a good idea, but would be best followed up in a separate context. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Does WebApps want to do work in Model-driven Views area?
Hi All, Pardon the interruption here to digress a bit to look at Rafael's proposal from the process perspective ... [Charter] defines WebApps' scope and explicit deliverables. Depending on how the proposal is viewed, (perhaps) at least part of it could be rationalized by being related to XBL templates. Nevertheless, I would appreciate feedback on - should WebApps start new work in this area? * If yes - why should WebApps take on this new deliverable? * If no - would some other group be a better place to do work in this area? Options here would include: a new Incubator Group [XG] that would have its own mail list to build consensus on the UCs, requirements and to start preliminary spec work; a new WG; some existing WG (Chaals mentioned some related work done in XForms); added to the new WG Dave Raggett mentioned; other options? -Art Barstow [Charter] http://www.w3.org/2010/webapps/charter/ [XG] http://www.w3.org/2005/Incubator/about.html Original Message Subject:Re: Model-driven Views Resent-Date:Tue, 3 May 2011 01:08:53 + Resent-From:public-webapps@w3.org Date: Mon, 2 May 2011 18:05:17 -0700 From: ext Rafael Weinstein rafa...@google.com To: Maciej Stachowiak m...@apple.com CC: o...@pettay.fi, public-webapps@w3.org Apologies. I feel like I have failed to properly contextualize this issue. Let me back up and see if I can't help create a different frame of reference. This email is already too long so I've avoided examples. Please let me know what isn't apparent and I'll explain further. 1) Imperative templating (JSP, jQuery, Closure, a load of others) is the problem. Declarative templating (Angular, Knockout, JSTemplate, Spry) is the solution. -Imperative approaches reduce to a function that spits out a string containing markup. -They are destructive in updating an existing view. Re-rendering trashes transient state and thus they are fundamentally unsuitable for dynamic web applications. -They aren't performant because they require destruction and re-creation of all instances in a collection when any item is added or removed. -Use of innerHTML for parsing tends to create XSS attack surface. 2) There's very little new in our design. This isn't a question of validating a new approach. Its a question of doing the hard work of making a successful pattern fit well into the rest of the web platform. -We've simply taken the basic design aspects of existing declarative approaches and attempted to explain their behavior with respect to the rest of the platform APIs. Further, we've attempted to give the pattern direct support for missing capabilities which currently require fairly ugly hacks. -Declarative approaches are heavily deployment tested and shown to be robust. -Declarative templating is a subset of the expressiveness of imperative. Generally speaking it's the subset that people use. [An imperative-declarative compiler is possible. It would need to enforce certain things. e.g. code blocks must contain balanced HTML, loops must not exit early, conditionals must be deterministic, etc...]. 3) The diversity in templating systems doesn't represent diversity in approaches or semantics. The differences are mostly superficial. The expressive requirements can be summarized quickly: a) Insert, assign (and possibly transform) a data value into an attribute, property or textContent. b) Conditionally include/show a bit of DOM. c) Produce a sub-template once for every item in a collection. d) Sub-iteration support is required e) Recursion (producing unknown depth trees) support is required f) Some mechanism for scoping is specifically required inside iterations, and more generally, so that full paths to data items don't need to be typed. 4) The lack of a standard blocks economies of scale that generally lead to many terrific things I don't have to list for this group, but most importantly: -Automation: Complexity kills. Non-trivial applications need tooling support. The automation and tooling support for Windows, MacOS and even Linux dwarfs that of web applications. Without a standard, there's little chance that we'll get good tools (inspecting/debugging, authoring, validation, optimization) inside or outside the browser. 5) We can create a feature which is fast by default. Libraries almost never do. -Our design is such that it fully delays all DOM work until the script event exits and then hands the instructions to the renderer as a batch. -UAs try to be lazy about doing work in order to only do expensive things minimally. This is the lazy nuclear option. All DOM work can be fully lazy. We're hopeful that there are big perf gains to be had here, but experimental implementations are the only way to prove this. -At minimum, the typical case can be assured to only incur one layout/style resolution. 6) Libraries can't hit the latency goals that we'd like to. -Libraries cannot render incrementally during page load. Leaving this
Re: Does WebApps want to do work in Model-driven Views area?
On 05/03/2011 02:38 PM, Arthur Barstow wrote: Hi All, Pardon the interruption here to digress a bit to look at Rafael's proposal from the process perspective ... [Charter] defines WebApps' scope and explicit deliverables. Depending on how the proposal is viewed, (perhaps) at least part of it could be rationalized by being related to XBL templates. Well, to me XBL templates are still quite different to MDV templates. XBL needs to handle all sort of attribute value and text value copying/forwarding and building the actual instance data in anonymous DOM and special event handling in the anonymous DOM etc. Nevertheless, I would appreciate feedback on - should WebApps start new work in this area? * If yes - why should WebApps take on this new deliverable? * If no - would some other group be a better place to do work in this area? Options here would include: a new Incubator Group [XG] that would have its own mail list to build consensus on the UCs, requirements and to start preliminary spec work; a new WG; some existing WG (Chaals mentioned some related work done in XForms); added to the new WG Dave Raggett mentioned; other options? I think I'm still missing some information before I could say yes or no. Basically I don't know what kinds of requirements led to the current design of MDV and why exactly it can't be implemented as a js library if some rather small primitives were added to the web platform. (Those small primitives should be defined either in webapps or whatwg, I think.) -Olli -Art Barstow [Charter] http://www.w3.org/2010/webapps/charter/ [XG] http://www.w3.org/2005/Incubator/about.html Original Message Subject: Re: Model-driven Views Resent-Date: Tue, 3 May 2011 01:08:53 + Resent-From: public-webapps@w3.org Date: Mon, 2 May 2011 18:05:17 -0700 From: ext Rafael Weinstein rafa...@google.com To: Maciej Stachowiak m...@apple.com CC: o...@pettay.fi, public-webapps@w3.org Apologies. I feel like I have failed to properly contextualize this issue. Let me back up and see if I can't help create a different frame of reference. This email is already too long so I've avoided examples. Please let me know what isn't apparent and I'll explain further. 1) Imperative templating (JSP, jQuery, Closure, a load of others) is the problem. Declarative templating (Angular, Knockout, JSTemplate, Spry) is the solution. -Imperative approaches reduce to a function that spits out a string containing markup. -They are destructive in updating an existing view. Re-rendering trashes transient state and thus they are fundamentally unsuitable for dynamic web applications. -They aren't performant because they require destruction and re-creation of all instances in a collection when any item is added or removed. -Use of innerHTML for parsing tends to create XSS attack surface. 2) There's very little new in our design. This isn't a question of validating a new approach. Its a question of doing the hard work of making a successful pattern fit well into the rest of the web platform. -We've simply taken the basic design aspects of existing declarative approaches and attempted to explain their behavior with respect to the rest of the platform APIs. Further, we've attempted to give the pattern direct support for missing capabilities which currently require fairly ugly hacks. -Declarative approaches are heavily deployment tested and shown to be robust. -Declarative templating is a subset of the expressiveness of imperative. Generally speaking it's the subset that people use. [An imperative-declarative compiler is possible. It would need to enforce certain things. e.g. code blocks must contain balanced HTML, loops must not exit early, conditionals must be deterministic, etc...]. 3) The diversity in templating systems doesn't represent diversity in approaches or semantics. The differences are mostly superficial. The expressive requirements can be summarized quickly: a) Insert, assign (and possibly transform) a data value into an attribute, property or textContent. b) Conditionally include/show a bit of DOM. c) Produce a sub-template once for every item in a collection. d) Sub-iteration support is required e) Recursion (producing unknown depth trees) support is required f) Some mechanism for scoping is specifically required inside iterations, and more generally, so that full paths to data items don't need to be typed. 4) The lack of a standard blocks economies of scale that generally lead to many terrific things I don't have to list for this group, but most importantly: -Automation: Complexity kills. Non-trivial applications need tooling support. The automation and tooling support for Windows, MacOS and even Linux dwarfs that of web applications. Without a standard, there's little chance that we'll get good tools (inspecting/debugging, authoring, validation, optimization) inside or outside the browser. 5) We can create a feature which is fast by default. Libraries almost never
Re: [IndexedDB] Closing on bug 9903 (collations)
On Tue, May 3, 2011 at 3:19 AM, Keean Schupke ke...@fry-it.com wrote: The more I think about it, the more I want a user-specified comparison function. Efficiency should not be an issue here - the engines should tweek the JIT compiler to fix any efficiency issues. Just let the user pass a closure (remember functions are first-class in JavaScript so this is not a callback nor an event). Wouldn't it be a bit more complicated than just passing a regular closure? The function has to be persisted in the database across page views, but a JavaScript closure is going to contain references to all sorts of objects (like document, or local variables) that are very specific to the current page view. It makes no sense to persist those objects in general. You'd need to serialize the function somehow, possibly putting restrictions on the sorts of variables it can access, so that it can be sensibly restored later. Is there some established way of doing this yet in JavaScript? It might be useful in other contexts too. I still agree that this is the correct direction to go in, though.
Re: [IndexedDB] Closing on bug 9903 (collations)
Why does it need to be persisted? I would prefer the database to be stateless. Obviously all users of the database need to use the same function. I would recommend modular programming - create a .js script you can include in all pages that provides 'collated' versions of the method calls by adding the collation argument - Infact for good programming in general make this API your model, so if you were writing a shopping cart, this '.js' would provide methods like 'addToCart', 'removeFromCart', and all collations settings would be hidden in this layer and kept out of individual pages, whilst not needing to be stored in the database at all. Cheers, Keean. On 3 May 2011 15:27, Aryeh Gregor simetrical+...@gmail.com wrote: On Tue, May 3, 2011 at 3:19 AM, Keean Schupke ke...@fry-it.com wrote: The more I think about it, the more I want a user-specified comparison function. Efficiency should not be an issue here - the engines should tweek the JIT compiler to fix any efficiency issues. Just let the user pass a closure (remember functions are first-class in JavaScript so this is not a callback nor an event). Wouldn't it be a bit more complicated than just passing a regular closure? The function has to be persisted in the database across page views, but a JavaScript closure is going to contain references to all sorts of objects (like document, or local variables) that are very specific to the current page view. It makes no sense to persist those objects in general. You'd need to serialize the function somehow, possibly putting restrictions on the sorts of variables it can access, so that it can be sensibly restored later. Is there some established way of doing this yet in JavaScript? It might be useful in other contexts too. I still agree that this is the correct direction to go in, though.
Re: paste events and HTML support - interest in exposing a DOM tree?
Le 3 mai 2011 à 12:20, Hallvord R. M. Steen a écrit : Regarding simplifying the pasted html to remove stuff that could be malicious, consider a rogue app that injects a script in the clipboard and expects the user to hit paste on his bank site. Well, I've never seen a bank site with a rich text editor / contentEditable-based feature customers are meant to use ;-) write a message to us ?? Seems like a function an e-banking site offers and could support html one day. Your other use case remains strong. One thing that I like in the DOM exposure of the HTML flavour is that it prevents an amount of the threats related to parsing and that is good. In MathML (as in any xml fragment), the only dangers are, I believe: - parsing time: related files inclusion (schema and dtd notably) - image and/or style embedding The first danger is eliminated if the fragment is exposed as a DOM fragment (provided the reference is removed of course). The second danger is eliminated by the same techniques as those with HTML. paul
copy events and content from server
Hello list, As noted in the thread about security started by Halvord: In many of the scenarios I have working for, the content to be put on the clipboard would come from a luxury knowledge structure on the server, one that has access to some semantic source and can infer useful representations out of it; these get put to the clipboard. An offline HTML would also be an example of it. but I am realizing that this is probably not possible to do because the only way to do obtain something from the server is to wait until a callback is called (and this is good so) at which time the copy event might be long gone already. Would it be thinkable to *lock* the copy event until either a timeout occurs or an unlock is called? This way the script in the client would be able to fetch rich transformations from the server. thanks in advance. paul PS: I would expect the same could be needed for the copy event which could want to write to the server.
[IndexedDB] Bug#10601 - Need some way to create IDB events?
Is this what the working group had in mind when opening this bug [1], the
ability to add a initIDBVersionChangeEvent method to the interface below?
interface IDBVersionChangeEvent: Event {
readonly attribute DOMString version;
-- void initIDBVersionChangeEvent(in DOMString typeArg, in boolean
canBubbleArg, in boolean cancelableArg, in DOMString version);
}
Israel
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10601
[IndexedDB] Bug#11401 -We should disallow .transaction() from within setVersion transactions
We expect async operations to be queue up and executed in the order in which they were created. Thus, the request to create a second transaction inside the onsuccess handler of a setVersion request using a .transaction() method would fail as long as we were inside a VERSION_CHANGE transaction. The reason being that the VERSION_CHANGE transaction locks the complete db. It seems we wouldn't want to allow this type of scenario. Do we expect this to be a realistic scenario? Is there a reason why we wouldn't just throw a NOT_ALLOWED_ERR. Could we modify the transaction method information to say something like: --Throws an IDBDatabaseException of NOT_ALLOWED_ERR when the transaction() method is called within the onsuccess handler of a setVersion request. This would simply the Async model and keep it consistent with the Sync model. Israel [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=11401
Re: copy events and content from server
On Tue, May 3, 2011 at 10:26 AM, Paul Libbrecht p...@hoplahup.net wrote: As noted in the thread about security started by Halvord: In many of the scenarios I have working for, the content to be put on the clipboard would come from a luxury knowledge structure on the server, one that has access to some semantic source and can infer useful representations out of it; these get put to the clipboard. An offline HTML would also be an example of it. but I am realizing that this is probably not possible to do because the only way to do obtain something from the server is to wait until a callback is called (and this is good so) at which time the copy event might be long gone already. Would it be thinkable to *lock* the copy event until either a timeout occurs or an unlock is called? No. We definitely don't want to lock a local system resource for some random web service that may potentially fail to release the lock. - Ryosuke
Re: copy events and content from server
Ryosuke, Le 3 mai 2011 à 21:15, Ryosuke Niwa a écrit : Would it be thinkable to *lock* the copy event until either a timeout occurs or an unlock is called? No. We definitely don't want to lock a local system resource for some random web service that may potentially fail to release the lock. I am not sure I made this clear. The intent is to let javascript operate a lock. Locking the system resource? Who spoke about that? That'd lock maybe some of the continuation of a script in that page... nothing else. It could start to operate on the clipboard only after the unlock has occurred (or a focus-lost has happened which would have declared that the copy operation is aborted). The random web-service in question is the web-server the user is currently using which could have delivered the information in question before, just did not because it did not know which information the user intended to copy! If you look at desktop apps, there are many apps that do very rich copy operations and these take time with a modal dialog sometimes displayed. paul
Re: [IndexedDB] Closing on bug 9903 (collations)
On Tue, May 3, 2011 at 10:56 AM, Keean Schupke ke...@fry-it.com wrote: Why does it need to be persisted? I would prefer the database to be stateless. Obviously all users of the database need to use the same function. And if they don't use exactly the same function, maybe due to a transient bug, the index is silently and permanently corrupted, until all affected rows happen to be updated again? That doesn't sound like a good idea to me.
Re: [IndexedDB] Bug#10601 - Need some way to create IDB events?
On Tue, May 3, 2011 at 11:51 AM, Israel Hilerio isra...@microsoft.com wrote:
Is this what the working group had in mind when opening this bug [1], the
ability to add a initIDBVersionChangeEvent method to the interface below?
interface IDBVersionChangeEvent: Event {
readonly attribute DOMString version;
-- void initIDBVersionChangeEvent(in DOMString typeArg, in boolean
canBubbleArg, in boolean cancelableArg, in DOMString version);
}
Israel
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10601
Yes. Back when the bug was originally filed we had a larger set of
events, but now it's only that one.
/ Jonas
[File API: FileSystem] Path restrictions and case-sensitivity
I'd like to bring back up the discussion that went on at [1] and [2]. In particular, I'd like to propose a minimal set of restrictions for file names and paths, punt on the issue of what happens in later layers of the API, and discuss case-sensitivity rules. For the sandboxed filesystem, I propose that we disallow only: * Embedded null characters [will likely break something somewhere] * Embedded forward slash (/) [it's our delimiter] * Embedded backslash (\) [will likely confuse people if we permit it] * Files called '.' [has a meaning for us already] * Files called '..' [has a meaning for us already] * Path segments longer than 1KB [probably long enough, and I feel better having a limit] ...and explicitly support anything other than that. I'm not proposing a maximum path length at this time...perhaps we should just say MUST support at least X for some large X? Regarding case sensitivity: I originally specced it as case-insensitive-case-preserving to make it easier to support a passthrough implementation on Windows and Mac. However, as passthroughs have turned out to be unfeasible [see previous thread on path length problems], all case insensitivity really gets us is potential locale issues. I suggest we drop it and just go with a case-sensitive filesystem. Eric [1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1031.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0704.html
RE: [IndexedDB] Bug#10601 - Need some way to create IDB events?
On Tue, May 3, 2011 at 4:45 PM, Jonas Sicking wrote:
On Tue, May 3, 2011 at 11:51 AM, Israel Hilerio isra...@microsoft.com
wrote:
Is this what the working group had in mind when opening this bug [1], the
ability to add a initIDBVersionChangeEvent method to the interface below?
interface IDBVersionChangeEvent: Event {
readonly attribute DOMString version;
-- void initIDBVersionChangeEvent(in DOMString typeArg, in
-- boolean canBubbleArg, in boolean cancelableArg, in DOMString
-- version);
}
Israel
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10601
Yes. Back when the bug was originally filed we had a larger set of events, but
now it's only that one.
/ Jonas
Great! I'll talk to Eliot to added to his list of spec updates.
Israel
[IndexedDB] deleteObjectStore method and updates to IDBDatabase.objectStoreNames on the client
In looking at createObjectStore on IDBDatabase, it seems that we would have to update the IDBDatabase.objectStoreNames attribute on the client side after returning the IDBObjectStore. Otherwise, it would be difficult to detect that an objectStore with the same name already exists and throw a CONSTRAINT_ERR exception. Following this pattern, would it make sense to update the IDBDatabase.objectStoreNames attribute on the client side after executing deleteObjectStore before the async operation is executed. This would allow us to support scenarios like: var b = db.createObjectStore(B); var req = db.deleteObjectStore(B); b = db.createObjectStore(B); What do you think? Israel
