[Bug 27876] New: [Shadow] It is not defined what event.path actually should return

2015-01-21 Thread bugzilla
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

2015-01-21 Thread Glen Huang
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

2015-01-21 Thread Domenic Denicola
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

2015-01-21 Thread Simon Pieters
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

2015-01-21 Thread Glen Huang
@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

2015-01-21 Thread Boris Zbarsky

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?

2015-01-21 Thread Mats Palmgren

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