[Bug 27876] New: [Shadow] It is not defined what event.path actually should return
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27876 Bug ID: 27876 Summary: [Shadow] It is not defined what event.path actually should return Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: b...@pettay.fi QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org a copy of the event path for the context object in unclear. There is no such thin as Event's event path. There is Event and there is event path but specs don't seem to actually make clear mapping between those. (1) What is the value when the event hasn't been dispatched? I assume empty array. (2) What is the value during event dispatch I assume the event target chain which was created before capture phase (and changes to the DOM don't actually affect to this). (3) what is the value after the event has been dispatched? empty array? The same as in (2)? -- You are receiving this mail because: You are on the CC list for the bug.
Re: oldNode.replaceWith(...collection) edge case
I have two more things to add. 1. One more reason why context node should be allowed as an argument. These work as intended: node.before(node) node.after(node) node.replaceWith(node) By passing an additional argument, they suddenly fail: node.before(node, another) node.after(node, another) node.replaceWith(node, another) This doesn’t feel right. 2. Algorithm performance The performance hit is based on the assumption that an implementation will follow the spec algorithm closely and use a document fragment when multiple arguments are passed. In reality, I believe an implementation can totally get away from that and insert arguments directly, as long as it can make sure the final DOM structure is correct, mutation records are queued, ranges are modified, etc. Nothing in the algorithm dictates the using of a document fragment. For example, for the before() method, I can imagine it could be implemented it like this (in pseudo code, ignoring mutation records and range, etc): ensure context node validity set prevInserted to null for node from last argument to first argument, if the argument is a document fragment, from its last child to first child if node is the context node if prevInserted is not null insert node before it set prevInserted to node else set prevInserted to node continue else insert node before the context node set prevInserted to node This algorithm shouldn’t slow normal operations down, and I wonder if the spec could use an algorithm like this and not using document fragment. On Jan 21, 2015, at 5:50 PM, Glen Huang curvedm...@gmail.com wrote: @Boris @Simon From the jsperf, looks like Blink is indeed making document fragment obsolete. Run the tests in webkit, although still way faster with document fragment, I believe the gap will narrow in the future. (I really think authors shouldn’t have to rely on it to get good performance). Thank you for debunking the myth for me. :) Now, let’s go back to the original topic. I brought up document fragment because I wanted to argue that by disallowing passing the context node as an argument, authors would be unable find an equally performant solution. You guys tell me that’s not the case. I agree, and I will drop that. But I still don’t feel disallowing that is the right way to go, for two reasons: 1. Passing context node as an argument does have a meaningful result, and practical use cases. 2. Although the use cases might not come as often, these are native DOM methods, everybody is expected to use them. Given the huge user base, the use cases might not come as rare also. I see the argument against it is probably that it may slow down normal operations too. But is that really true? The key here is to find the correct insertion point after the macro action. Although in the spec algorithm, using a transient node seems to be the most performant way (and it slows down normal operations), I doubt it’s impossible for an actual implementation to optimize that. This isn't some feature that can be disallowed now and allowed in the future. And by disallowing it, I think it qualifies as a gotcha when you do need it. But that’s just my personal feelings. If it turns out it’s really not that cheap to implement. I’d be happy to correctly use before() and after() and not root for something that will slow everybody down. :) On Jan 21, 2015, at 4:52 PM, Simon Pieters sim...@opera.com wrote: On Wed, 21 Jan 2015 00:45:32 +0100, Glen Huang curvedm...@gmail.com wrote: Ah, thank you for letting me know. I vaguely remember document fragment is introduced just to reduce reflows. Looks like this best practice is obsolete now? (I remember myself wondering why bowsers couldn’t optimize that back then.) Many people still suggest it though, including google (https://developers.google.com/speed/articles/javascript-dom https://developers.google.com/speed/articles/javascript-dom the DocumentFragment DOM Generation” section), and you can find more by googling “why use document fragment. I think that article is a bit misguided. Changing a class does trigger a reflow, but it doesn't force a reflow while the script is running (maybe it does in old browsers). Asking for layout information does force a reflow. I think documentfragment has been faster in several browsers and maybe still is, but in Blink at least it appears that the different methods are getting about equally fast. It probably depends on how you do it, though. This jsperf might be interesting: http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/81 So to recap, when you have the need to pass the context node as an argument along with other nodes, just use before() and after() to insert these other nodes? And
RE: Better focus support for Shadow DOM
Thanks Takoyoshi! This new version looks great to me. It would allow people to create custom elements with the same focus capabilities as native elements, including both the simple cases (like custom-a) and the more complicated ones with a shadow DOM (like custom-input type=date). Very exciting stuff! I hope others are as enthused as I am :) From: Takayoshi Kochi (河内 隆仁) [mailto:ko...@google.com] Sent: Wednesday, January 21, 2015 02:41 To: public-webapps Subject: Re: Better focus support for Shadow DOM Hi, After conversation with Domenic Denicola, I changed the title and the whole story of solving this issue, though the result is not quite different. Instead of adding delegatesFocus property, we added isTabStop() to expose tab focusable flag explained in HTML5 spec. https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Any comments/suggestions welcome. On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) ko...@google.commailto:ko...@google.com wrote: Hi, For shadow DOMs which has multiple focusable fields under the host, the current behavior of tab navigation order gets somewhat weird when you want to specify tabindex explicitly. This is the doc to introduce a new attribute delegatesFocus to resolve the issue. https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Any comments are welcome! -- Takayoshi Kochi -- Takayoshi Kochi
Re: oldNode.replaceWith(...collection) edge case
On Wed, 21 Jan 2015 00:45:32 +0100, Glen Huang curvedm...@gmail.com wrote: Ah, thank you for letting me know. I vaguely remember document fragment is introduced just to reduce reflows. Looks like this best practice is obsolete now? (I remember myself wondering why bowsers couldn’t optimize that back then.) Many people still suggest it though, including google (https://developers.google.com/speed/articles/javascript-dom https://developers.google.com/speed/articles/javascript-dom the DocumentFragment DOM Generation” section), and you can find more by googling “why use document fragment. I think that article is a bit misguided. Changing a class does trigger a reflow, but it doesn't force a reflow while the script is running (maybe it does in old browsers). Asking for layout information does force a reflow. I think documentfragment has been faster in several browsers and maybe still is, but in Blink at least it appears that the different methods are getting about equally fast. It probably depends on how you do it, though. This jsperf might be interesting: http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/81 So to recap, when you have the need to pass the context node as an argument along with other nodes, just use before() and after() to insert these other nodes? And even insert them one by one is fine? Yeah. -- Simon Pieters Opera Software
Re: oldNode.replaceWith(...collection) edge case
@Boris @Simon From the jsperf, looks like Blink is indeed making document fragment obsolete. Run the tests in webkit, although still way faster with document fragment, I believe the gap will narrow in the future. (I really think authors shouldn’t have to rely on it to get good performance). Thank you for debunking the myth for me. :) Now, let’s go back to the original topic. I brought up document fragment because I wanted to argue that by disallowing passing the context node as an argument, authors would be unable find an equally performant solution. You guys tell me that’s not the case. I agree, and I will drop that. But I still don’t feel disallowing that is the right way to go, for two reasons: 1. Passing context node as an argument does have a meaningful result, and practical use cases. 2. Although the use cases might not come as often, these are native DOM methods, everybody is expected to use them. Given the huge user base, the use cases might not come as rare also. I see the argument against it is probably that it may slow down normal operations too. But is that really true? The key here is to find the correct insertion point after the macro action. Although in the spec algorithm, using a transient node seems to be the most performant way (and it slows down normal operations), I doubt it’s impossible for an actual implementation to optimize that. This isn't some feature that can be disallowed now and allowed in the future. And by disallowing it, I think it qualifies as a gotcha when you do need it. But that’s just my personal feelings. If it turns out it’s really not that cheap to implement. I’d be happy to correctly use before() and after() and not root for something that will slow everybody down. :) On Jan 21, 2015, at 4:52 PM, Simon Pieters sim...@opera.com wrote: On Wed, 21 Jan 2015 00:45:32 +0100, Glen Huang curvedm...@gmail.com wrote: Ah, thank you for letting me know. I vaguely remember document fragment is introduced just to reduce reflows. Looks like this best practice is obsolete now? (I remember myself wondering why bowsers couldn’t optimize that back then.) Many people still suggest it though, including google (https://developers.google.com/speed/articles/javascript-dom https://developers.google.com/speed/articles/javascript-dom the DocumentFragment DOM Generation” section), and you can find more by googling “why use document fragment. I think that article is a bit misguided. Changing a class does trigger a reflow, but it doesn't force a reflow while the script is running (maybe it does in old browsers). Asking for layout information does force a reflow. I think documentfragment has been faster in several browsers and maybe still is, but in Blink at least it appears that the different methods are getting about equally fast. It probably depends on how you do it, though. This jsperf might be interesting: http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/81 So to recap, when you have the need to pass the context node as an argument along with other nodes, just use before() and after() to insert these other nodes? And even insert them one by one is fine? Yeah. -- Simon Pieters Opera Software
Re: oldNode.replaceWith(...collection) edge case
On 1/21/15 3:52 AM, Simon Pieters wrote: This jsperf might be interesting: http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/81 Or misleading. Again, in real life what matters most here is what else is on the page, which the jsperf doesn't capture. The other thing that really matters is how many elements are being inserted, exactly, of course... which the jsperf also doesn't capture. Typically, jsperf is the wrong tool for answering questions like this, unless you're 100% sure your microbenchmark captures all the essential features of the macro-situation... -Boris
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On 01/17/2015 05:11 PM, Aryeh Gregor wrote: On Wed, Jan 14, 2015 at 6:14 PM, Mats Palmgren m...@mozilla.com wrote: It would be easy to change Gecko to ignore addRange() calls if the range start/end node is detached. We could easily do the same for range.setStart*/setEnd* for ranges that are in the Selection. Would that address your concern about detached nodes? I think so, yes, but it would mean making Range methods behave differently depending on whether the range is in a selection. Is that really sane? It seems fine to me. WebKit/Blink already rejects(*) a range with detached nodes in the addRange call. Imposing the same restriction on a (live) Selection range is consistent with that. (*) It appears to collapse the current range, if any, at the end point, but I might be mistaken on the exact behavior. I would prefer to simply ignore calls with detached nodes and leave the Selection as is, but I don't feel strongly about it. If we really want authors to have convenience methods like setStartBefore() on Selection, we could add them to Selection. Selection methods wouldn't provide the same functionality though. Selection.setStart* would presumably be equivalent to setStart* on the first range in the Selection, but how do you modify the start boundary point on other ranges when there are more than one? I guess we could add them as convenience methods, making setStart* operate on the first range and setEnd* on the last, but it's still an incomplete API for multi-range Selections. /Mats