Re: CfC: publish WD of DOM; deadline December 2
On 2012-11-25 16:19, Ms2ger wrote: On 11/25/2012 02:49 PM, Arthur Barstow wrote: This is Call for Consensus to publish a Working Draft of the DOM spec using #ED as the basis. Same objections as to the XHR WD. From your XHR objection: I object unless the draft contains a clear pointer to the canonical spec on whatwg.org. In addition to the link I already had in the draft, I have now included this statement above the W3C copyright notice. This specification is based on DOM Standard published by the WHATWG. DOM Standard is licensed under Creative Commons CC0 1.0 (Public Domain Dedication). I have also stated this in the status section: This document is published by the Web Applications Working Group in co-operation with the Web Hypertext Application Technology Working Group. The Working Group expects to advance this Working Draft to Recommendation Status. Does that address your concerns? I have committed a WD ready copy, with the publication date tentatively set for 6 December. http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html -- Lachlan Hunt http://lachy.id.au/ http://www.opera.com/
Re: Colliding FileWriters
On Wed, Nov 28, 2012 at 4:10 PM, David Bruant bruan...@gmail.com wrote: One downside of this is that it means that if you're doing a bunch of separate read/write operations in separate locks, each lock is held until we've had a chance to fire the final success event for the operation. So if you queue up a ton of small write operations you can end up mostly sitting waiting for the main thread to finish posting events. It'd only slow things down if you attach an expensive, long-running event handler to a load/loadend event, which is an inherently bad idea if you're doing lots of tiny operations. Is that actually a problem? No, that's not correct. Most likely the implementation of this will use two threads. The main thread which runs the JS code running in the window or worker and an IO thread which does the file reading/writing. The main thread is also where event handlers run. Every time a read/write is requested by the main thread, data about this operation is sent to the IO thread allowing the main thread to continue. If the main thread creates two separate locks which perform two small write operations (...) I'd like to stop here for a minute, because I'm not entirely clear as to what this assumptions means. Does this part mean that during the same event loop turn, some JS code would open 2 separate locks for the same file? If so, that sounds like such an edge case it should just be forbidden like throwing an ALREADY_LOCKED error when asking a second lock. Since the first lock is released at the end of turn, the code asking the second lock can recover by try/catching the error and deciding to lock and play with the file in another later turn (using setTimeout( , 0) or whatev's) Preventing 2 locks for the same file in the same turn saves a lot of complications it seems. What ended up happening for Firefox implementation? The name lock is a bit misleading here. It's more like the transaction in IDB. You can get more than one lock or rather LockedFile objects for the same file. Operations for these objects can be processed in parallel or serialized, depending on the type of LockedFile objects (readonly or readwrite). Operations for LockedFile objects which can't be processed (for example if there's already a readwrite active LockedFile) are just queued. Jan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Nov 28, 2012 at 2:51 PM, Maciej Stachowiak m...@apple.com wrote: Does this support the previously discussed mechanism of allowing either public or private components? I'm not able to tell from the referenced sections. Can you explain the use case for wanting private shadows that are not isolated? - E
Re: [Workers] Worker same-origin and usage in JS libraries...
On Tue, 17 Jul 2012, Ian Hickson wrote: My plan is to make it so that cross-origin URLs start cross-origin workers. The main unresolved question is how to do this in an opt-in manner. The best idea I've come up with so far is having scripts that want to opt-in to being run in such a way start with a line line: // Cross-Origin Worker for: http://example.net ...or (for multiple domains): // Cross-Origin Worker for: http://example.com https://example.org ...or (for any domain): // Cross-Origin Worker for all origins ...but that doesn't seem super neat. Just as an update, I still plan to do this, but I'm currently waiting for browser vendors to more widely implement the existing Worker, SharedWorker, MessagePort, and PortCollection features before adding more features to this part of the spec. It would also be helpful to have confirmation from browser vendors that y'all actually _want_ cross-origin workers, before I spec it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Workers] Worker same-origin and usage in JS libraries...
On Thu, Nov 29, 2012 at 4:31 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 17 Jul 2012, Ian Hickson wrote: My plan is to make it so that cross-origin URLs start cross-origin workers. The main unresolved question is how to do this in an opt-in manner. The best idea I've come up with so far is having scripts that want to opt-in to being run in such a way start with a line line: // Cross-Origin Worker for: http://example.net ...or (for multiple domains): // Cross-Origin Worker for: http://example.com https://example.org ...or (for any domain): // Cross-Origin Worker for all origins ...but that doesn't seem super neat. Just as an update, I still plan to do this, but I'm currently waiting for browser vendors to more widely implement the existing Worker, SharedWorker, MessagePort, and PortCollection features before adding more features to this part of the spec. It would also be helpful to have confirmation from browser vendors that y'all actually _want_ cross-origin workers, before I spec it. The only difference with cross-origin workers is that they're in a different execution environment, right? If so, seems like a good thing to support. I don't see any downside and it doesn't sound especially difficult to implement. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[selectors-api] Matching of :scope in document.querySelector(All)
When implementing :scope support, I discovered that as things stand this call: document.querySelector(:scope) is specified to return null. In particular http://dev.w3.org/2006/webapi/selectors-api2/#queryselector step 1 calls http://dev.w3.org/2006/webapi/selectors-api2/#determine-contextual-reference-nodes which returns an empty set. Then this empty set is passed as an explicit contextual reference set to selector matching in http://dev.w3.org/2006/webapi/selectors-api2/#evaluate-a-selector so that :scope doesn't match anything. Is this intentional? I would have expected the above call to return the documentElement, which is what :scope would match in a non-scoped stylesheet... -Boris
