[Bug 24708] New: [Shadow]: Wrong spelling
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24708 Bug ID: 24708 Summary: [Shadow]: Wrong spelling Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: dh20...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 The folowing set of relationships hold in the figure: -- You are receiving this mail because: You are on the CC list for the bug.
Re: [webcomponents] Imperative API for Insertion Points
On Mon, Feb 17, 2014 at 11:03 AM, Edward O'Connor eocon...@apple.comwrote: I think Ryosuke's content.add/remove are a better base layer than content select. In fact, content select is straightforwardly implementable / explainable on top of MO + content.add/remove, but there are several use cases that content.add/remove address that are difficult or impossible with content select (as described in Maciej's recent email on this thread). I agree. As a contributor to a major JS framework, I was shocked by the lack of an imperative API and that content select was even a thing. - Erik
Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)
On 2/17/14 9:17 AM, ext Jungkee Song wrote: On Mon, Feb 17, 2014 at 9:38 PM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: The only process requirement for a FPWD is that the group record consensus to publish it. However, it's usually helpful if the FPWD is feature complete from a breadth perspective but there is no expectation the FPWD is complete from a depth perspective. As such, if there are missing features, it would be good to mention that in the ED and/or file related bugs. I believe things are mostly addressed in a breadth perspective albeit quite a few issues are still being discussed and sorted out. We are currently drafting the ED and thought the F2F is sort of a right time to have a consensus for FPWD but think it'll be nicer if we can make it even before that to get a wider review as soon as possible. Given the broad interest in this spec, I think it would be helpful to move toward FPWD as soon as possible. Would you please give a rough guestimate on when you think spec can ready for a CfC to publish a FPWD? -Thanks, ArtB
Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?
So, the story so far is that the spec has added something it labels semi-trusted events - that is an event triggered from a trusted event of a whitelisted type. The precedence here is popup blocking - browsers already have rules for which events are more trusted than others in terms of likely expressing user intent. (An example makes this clearer: scripts are typically allowed to call window.open() from a click event listener, but are typically not allowed to call window.open() from an load or mouseover listener.) However.. Also, will there be any way for us to feature detect when this is available? I've still not really been able to come up with a nice way to feature detect these semi-trusted events. Good ideas requested and appreciated.. I'm thinking that just using `document.queryCommandSupported(copy)` and `document.queryCommandEnabled(copy)` could return some false positives (i.e. the feature is not yet implemented but returns `true` anyway) when the user is working within a contenteditable element, right? No idea what the current implementation state of these calls are.. -Hallvord
Re: Why can't we just use constructor instead of createdCallback?
On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote: What I mean is that for nodes that doesn't have a constructor, and whose parent doesn't have a constructor, no need to add them to the above arrays. Just insert them into their parent. That means that when that the constructor of an element runs, the element doesn't have any parents or children. So no need to hide parents or children anywhere. Okay, let me see if I got this right. The list is effectively a serialized representation of a document subtree. The parent + order in the list provides all the necessary information. We use this list to separate tree construction into two stages: one before custom element constructors are called, and one after. In cases when the custom element is just a like button widget (a leaf in the tree), the list is short and just contains the widgets. In cases like bodymy-appdiv ... the entire doc tree ... /my-app/body, the list contains the entire subtree of my-app, which is effectively the document. In cases like divmy-bar../my-barspan.../span ... more siblings ... /div, the list will contain at least all siblings of my-bar, because they can't be inserted into tree until after my-bar's constructor runs. When run, the constructors are free to explore the partially-completed tree, which enables interesting hacks like this: in document: div id=amy-bar/my-bar lots more markup... in my-bar constructor: var myFutureParent = document.querySelector(#a); // redirect tree construction to resume at a new point. document.body.appendChild(myFutureParent); Or, in my-bar constructor: var myFutureParent = document.querySelector(#a); var iframe = document.body.appendChild(document.createElement(iframe)); // teleport the tree into another frame iframe.contentDocument.body.appendChild(myFutureParent); I can't immediately tell whether these hacks are cool or scary. The thing that really bothers me is that this approach is contradicting itself. We go to into pretty elaborate lengths to enable running constructors during parsing, but the key performance lesson developers will immediately learn is to avoid constructors on custom elements, because they will trigger the two-phase code path during parsing. Here's a thing that you can use, but you probably don't want to ever use it. Here's an alternative proposal: 1) The Web developers are already aware of the fact that you can create new instances of JS objects without running their constructors with Object.create 2) Let's make sure that when they call constructors directly (as in var b = new MyB(arg1,arg2);), the constructor is actually called. 3) When the parser instantiates the element, it does the equivalent of Object.create, so no constructor is called. It seems simple and easy to understand. :DG
Re: Why can't we just use constructor instead of createdCallback?
On Tue, Feb 18, 2014 at 1:35 PM, Dimitri Glazkov dglaz...@google.comwrote: Here's an alternative proposal: 1) The Web developers are already aware of the fact that you can create new instances of JS objects without running their constructors with Object.create These are not the instances you are looking for. We need to have real instances here. @@create gives us the semantics for doing this. 2) Let's make sure that when they call constructors directly (as in var b = new MyB(arg1,arg2);), the constructor is actually called. 3) When the parser instantiates the element, it does the equivalent of Object.create, so no constructor is called. That would not set the internal state as needed. It would not know how to associate the instance object with the C++ backing object for example. Also, all the DOM methods are using brand checks (and not instanceof checks) so the brand needs to be setup as well. The solution is to call `MyElement[Symbol.create]()` which would setup the internal state as needed. We can make this non writable, non configurable which allows the implementation to skip calling any js code at that point because the semantics is unobservable. It seems simple and easy to understand. With ES6 it is possible to create instance objects without ever calling the constructor (this is NOT possible in ES5) so maybe we should just give up on having the parser calling the constructor? -- erik
Re: Why can't we just use constructor instead of createdCallback?
On Tue, Feb 18, 2014 at 11:24 AM, Erik Arvidsson a...@chromium.org wrote: On Tue, Feb 18, 2014 at 1:35 PM, Dimitri Glazkov dglaz...@google.comwrote: Here's an alternative proposal: 1) The Web developers are already aware of the fact that you can create new instances of JS objects without running their constructors with Object.create These are not the instances you are looking for. We need to have real instances here. @@create gives us the semantics for doing this. Ah, yes. Sorry :) 2) Let's make sure that when they call constructors directly (as in var b = new MyB(arg1,arg2);), the constructor is actually called. 3) When the parser instantiates the element, it does the equivalent of Object.create, so no constructor is called. That would not set the internal state as needed. It would not know how to associate the instance object with the C++ backing object for example. Also, all the DOM methods are using brand checks (and not instanceof checks) so the brand needs to be setup as well. The solution is to call `MyElement[Symbol.create]()` which would setup the internal state as needed. We can make this non writable, non configurable which allows the implementation to skip calling any js code at that point because the semantics is unobservable. It seems simple and easy to understand. With ES6 it is possible to create instance objects without ever calling the constructor (this is NOT possible in ES5) so maybe we should just give up on having the parser calling the constructor? Sounds good to me. :DG
Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)
On Tue, Feb 18, 2014 at 4:59 AM, Arthur Barstow art.bars...@nokia.comwrote: On 2/17/14 9:17 AM, ext Jungkee Song wrote: On Mon, Feb 17, 2014 at 9:38 PM, Arthur Barstow art.bars...@nokia.commailto: art.bars...@nokia.com wrote: The only process requirement for a FPWD is that the group record consensus to publish it. However, it's usually helpful if the FPWD is feature complete from a breadth perspective but there is no expectation the FPWD is complete from a depth perspective. As such, if there are missing features, it would be good to mention that in the ED and/or file related bugs. I believe things are mostly addressed in a breadth perspective albeit quite a few issues are still being discussed and sorted out. We are currently drafting the ED and thought the F2F is sort of a right time to have a consensus for FPWD but think it'll be nicer if we can make it even before that to get a wider review as soon as possible. Given the broad interest in this spec, I think it would be helpful to move toward FPWD as soon as possible. Would you please give a rough guestimate on when you think spec can ready for a CfC to publish a FPWD? I've been waiting until we have all the algorithms filled in. It's a non-sensical document until then.
Re: Why can't we just use constructor instead of createdCallback?
On Feb 18, 2014, at 10:35 AM, Dimitri Glazkov dglaz...@google.com wrote: On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote: What I mean is that for nodes that doesn't have a constructor, and whose parent doesn't have a constructor, no need to add them to the above arrays. Just insert them into their parent. That means that when that the constructor of an element runs, the element doesn't have any parents or children. So no need to hide parents or children anywhere. Okay, let me see if I got this right. The list is effectively a serialized representation of a document subtree. The parent + order in the list provides all the necessary information. We use this list to separate tree construction into two stages: one before custom element constructors are called, and one after. In cases when the custom element is just a like button widget (a leaf in the tree), the list is short and just contains the widgets. In cases like bodymy-appdiv ... the entire doc tree ... /my-app/body, the list contains the entire subtree of my-app, which is effectively the document. In cases like divmy-bar../my-barspan.../span ... more siblings ... /div, the list will contain at least all siblings of my-bar, because they can't be inserted into tree until after my-bar's constructor runs. When run, the constructors are free to explore the partially-completed tree, which enables interesting hacks like this: in document: div id=amy-bar/my-bar lots more markup... in my-bar constructor: var myFutureParent = document.querySelector(#a); // redirect tree construction to resume at a new point. document.body.appendChild(myFutureParent); Or, in my-bar constructor: var myFutureParent = document.querySelector(#a); var iframe = document.body.appendChild(document.createElement(iframe)); // teleport the tree into another frame iframe.contentDocument.body.appendChild(myFutureParent); You can already do this in a regular script element so this isn't a new issue custom element's constructor is introducing. The thing that really bothers me is that this approach is contradicting itself. We go to into pretty elaborate lengths to enable running constructors during parsing, but the key performance lesson developers will immediately learn is to avoid constructors on custom elements, because they will trigger the two-phase code path during parsing. Here's a thing that you can use, but you probably don't want to ever use it. Have you tried implementing this and found that you can't implement it efficiently? Could you quantify the runtime or memory cost? Here's an alternative proposal: 1) The Web developers are already aware of the fact that you can create new instances of JS objects without running their constructors with Object.create 2) Let's make sure that when they call constructors directly (as in var b = new MyB(arg1,arg2);), the constructor is actually called. 3) When the parser instantiates the element, it does the equivalent of Object.create, so no constructor is called. I don't see why we want to make the edge case like the one you described above prevent us from making common cases easy to use and understand. Just call constructor whenever a custom element is created. If you're doing weird stuff in constructor, then weird things happen. - R. Niwa
Re: Why can't we just use constructor instead of createdCallback?
On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov dglaz...@google.com wrote: On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote: What I mean is that for nodes that doesn't have a constructor, and whose parent doesn't have a constructor, no need to add them to the above arrays. Just insert them into their parent. That means that when that the constructor of an element runs, the element doesn't have any parents or children. So no need to hide parents or children anywhere. Okay, let me see if I got this right. The list is effectively a serialized representation of a document subtree. The parent + order in the list provides all the necessary information. We use this list to separate tree construction into two stages: one before custom element constructors are called, and one after. Yes In cases when the custom element is just a like button widget (a leaf in the tree), the list is short and just contains the widgets. Yes In cases like bodymy-appdiv ... the entire doc tree ... /my-app/body, the list contains the entire subtree of my-app, which is effectively the document. Well. With the optimization I mentioned you only need to make the my-app element and it's immediate children into the list. Any grand-children of my-app can immediately be inserted into their parent. So I guess you could say that the list contains basically the whole document. But most nodes would only indirectly be in the list. I.e. the list would be short, but each entry could contain large subtrees. In cases like divmy-bar../my-barspan.../span ... more siblings ... /div, the list will contain at least all siblings of my-bar, because they can't be inserted into tree until after my-bar's constructor runs. Yes When run, the constructors are free to explore the partially-completed tree, which enables interesting hacks like this: in document: div id=amy-bar/my-bar lots more markup... in my-bar constructor: var myFutureParent = document.querySelector(#a); // redirect tree construction to resume at a new point. document.body.appendChild(myFutureParent); Or, in my-bar constructor: var myFutureParent = document.querySelector(#a); var iframe = document.body.appendChild(document.createElement(iframe)); // teleport the tree into another frame iframe.contentDocument.body.appendChild(myFutureParent); Yup I can't immediately tell whether these hacks are cool or scary. You can already do exactly this with script elements. I also am not sure if that's cool or scary. But I also haven't heard of anyone running into trouble because of it. I suspect it's not a common thing to do. The thing that really bothers me is that this approach is contradicting itself. We go to into pretty elaborate lengths to enable running constructors during parsing, but the key performance lesson developers will immediately learn is to avoid constructors on custom elements, because they will trigger the two-phase code path during parsing. Here's a thing that you can use, but you probably don't want to ever use it. The above paragraph appears to assume that creating this list is slow. Do you have data to back that up? The whole premise of my original email was that we should not do this if it's slow. And that we should measure if it's slow or not. I absolutely agree that we should not add features that are slow anytime they are used. / Jonas
Re: Why can't we just use constructor instead of createdCallback?
On Tue, Feb 18, 2014 at 5:59 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov dglaz...@google.com wrote: On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote: What I mean is that for nodes that doesn't have a constructor, and whose parent doesn't have a constructor, no need to add them to the above arrays. Just insert them into their parent. That means that when that the constructor of an element runs, the element doesn't have any parents or children. So no need to hide parents or children anywhere. Okay, let me see if I got this right. The list is effectively a serialized representation of a document subtree. The parent + order in the list provides all the necessary information. We use this list to separate tree construction into two stages: one before custom element constructors are called, and one after. Yes In cases when the custom element is just a like button widget (a leaf in the tree), the list is short and just contains the widgets. Yes In cases like bodymy-appdiv ... the entire doc tree ... /my-app/body, the list contains the entire subtree of my-app, which is effectively the document. Well. With the optimization I mentioned you only need to make the my-app element and it's immediate children into the list. Any grand-children of my-app can immediately be inserted into their parent. So I guess you could say that the list contains basically the whole document. But most nodes would only indirectly be in the list. I.e. the list would be short, but each entry could contain large subtrees. Would that cause issues with the order of the mutation record reported by mutation observers? In cases like divmy-bar../my-barspan.../span ... more siblings ... /div, the list will contain at least all siblings of my-bar, because they can't be inserted into tree until after my-bar's constructor runs. Yes When run, the constructors are free to explore the partially-completed tree, which enables interesting hacks like this: in document: div id=amy-bar/my-bar lots more markup... in my-bar constructor: var myFutureParent = document.querySelector(#a); // redirect tree construction to resume at a new point. document.body.appendChild(myFutureParent); Or, in my-bar constructor: var myFutureParent = document.querySelector(#a); var iframe = document.body.appendChild(document.createElement(iframe)); // teleport the tree into another frame iframe.contentDocument.body.appendChild(myFutureParent); Yup I can't immediately tell whether these hacks are cool or scary. You can already do exactly this with script elements. I also am not sure if that's cool or scary. But I also haven't heard of anyone running into trouble because of it. I suspect it's not a common thing to do. The thing that really bothers me is that this approach is contradicting itself. We go to into pretty elaborate lengths to enable running constructors during parsing, but the key performance lesson developers will immediately learn is to avoid constructors on custom elements, because they will trigger the two-phase code path during parsing. Here's a thing that you can use, but you probably don't want to ever use it. The above paragraph appears to assume that creating this list is slow. Do you have data to back that up? The whole premise of my original email was that we should not do this if it's slow. And that we should measure if it's slow or not. I absolutely agree that we should not add features that are slow anytime they are used. / Jonas -- erik
Re: Why can't we just use constructor instead of createdCallback?
On Tue, Feb 18, 2014 at 2:59 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov dglaz...@google.com wrote: On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote: What I mean is that for nodes that doesn't have a constructor, and whose parent doesn't have a constructor, no need to add them to the above arrays. Just insert them into their parent. That means that when that the constructor of an element runs, the element doesn't have any parents or children. So no need to hide parents or children anywhere. Okay, let me see if I got this right. The list is effectively a serialized representation of a document subtree. The parent + order in the list provides all the necessary information. We use this list to separate tree construction into two stages: one before custom element constructors are called, and one after. Yes In cases when the custom element is just a like button widget (a leaf in the tree), the list is short and just contains the widgets. Yes In cases like bodymy-appdiv ... the entire doc tree ... /my-app/body, the list contains the entire subtree of my-app, which is effectively the document. Well. With the optimization I mentioned you only need to make the my-app element and it's immediate children into the list. Any grand-children of my-app can immediately be inserted into their parent. So I guess you could say that the list contains basically the whole document. But most nodes would only indirectly be in the list. I.e. the list would be short, but each entry could contain large subtrees. In cases like divmy-bar../my-barspan.../span ... more siblings ... /div, the list will contain at least all siblings of my-bar, because they can't be inserted into tree until after my-bar's constructor runs. Yes When run, the constructors are free to explore the partially-completed tree, which enables interesting hacks like this: in document: div id=amy-bar/my-bar lots more markup... in my-bar constructor: var myFutureParent = document.querySelector(#a); // redirect tree construction to resume at a new point. document.body.appendChild(myFutureParent); Or, in my-bar constructor: var myFutureParent = document.querySelector(#a); var iframe = document.body.appendChild(document.createElement(iframe)); // teleport the tree into another frame iframe.contentDocument.body.appendChild(myFutureParent); Yup I can't immediately tell whether these hacks are cool or scary. You can already do exactly this with script elements. I also am not sure if that's cool or scary. But I also haven't heard of anyone running into trouble because of it. I suspect it's not a common thing to do. I see. I am continually amazed at the exciting world we live in. The thing that really bothers me is that this approach is contradicting itself. We go to into pretty elaborate lengths to enable running constructors during parsing, but the key performance lesson developers will immediately learn is to avoid constructors on custom elements, because they will trigger the two-phase code path during parsing. Here's a thing that you can use, but you probably don't want to ever use it. The above paragraph appears to assume that creating this list is slow. Do you have data to back that up? No, of course not :) It's a first intuitive reaction. :DG
[Bug 24658] [imports]: The fetch readiness shouldn't block fetching.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24658 Morrita Hajime morr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Morrita Hajime morr...@google.com --- See https://github.com/w3c/webcomponents/commit/220b817d705f483b978b765f24244287d8ca28f9 and following changes. I should've done this in branch to make the diff easy to read :-( This is an attempt to reduce blocking. The main changes are: - Now the import dependencies are explained as a DAG. The dependency for each import is explicitly spec-ed as import dependent using the DAG topology. - The import fetching algorithm no longer spins until unblock. Only place to spin is before script, as it is originally intended. The notion of fetch readiness is gone. Some superficial changes: - import parent is renamed to import owner. Now the parent-child relationship over DOM is called import owner and one over the DAT is called import parent. - Many existing paragraphs are rephrased based on these new concepts. I hope new revision make the whole concept clearer. As usual, feel free to reopen/file new bugs. Any feedback will be appreciated! -- You are receiving this mail because: You are on the CC list for the bug.
Re: Why can't we just use constructor instead of createdCallback?
On Tue, Feb 18, 2014 at 3:26 PM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, Feb 18, 2014 at 2:59 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov dglaz...@google.com wrote: The thing that really bothers me is that this approach is contradicting itself. We go to into pretty elaborate lengths to enable running constructors during parsing, but the key performance lesson developers will immediately learn is to avoid constructors on custom elements, because they will trigger the two-phase code path during parsing. Here's a thing that you can use, but you probably don't want to ever use it. The above paragraph appears to assume that creating this list is slow. Do you have data to back that up? No, of course not :) It's a first intuitive reaction. One example that seems intuitively problematic about this approach (to me, anyway) are those parts of the parser that inspect the tree during parsing: foster parenting. I'm not sure it's a performance issue so much as a complexity issue. Consider: div my-element table div When following the spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#appropriate-place-for-inserting-a-node), any text in that algorithm which says parent node need to be patched to say something about this new list of to-be-attached nodes. Patching all such references seems likely to be difficult and error-prone, but I admit that I can't quantify those worries. - Adam
