Event.prototype.deepPath as an attribute breaks TinyMCE 4.3.10

[rniwa]

This is probably an evangelism but wordpress.com breaks due to its use of deepPath as an attribute. Specifically, they have a code that retrieves event.deepPath[0].

[rniwa]

@hayatoito @annevk @Ms2ger @zcorpan @bzbarsky @hober @travisleithead

[annevk]

What would a good alternative name be? connectedPath(), composedPath(), unclosedPath(), openPath()?

[rniwa]

I like composedPath(). I'm really hoping that wordpress.com fixes this especially since WordPress itself doesn't seem to have it. But I'm interested in what you all think.

[domenic]

Are there other parts of the API that should make the deep -> composed substitution for consistency?

[annevk]

As far as I know this is the only API that uses "deep" thus far. There's several open issues about adding more, but nothing remotely conclusive.

The other APIs that can go "downward" are slotable.assignedSlot and shadowHost.shadowRoot. And of course, all three are restricted to returning nodes in open shadow trees.

[rniwa]

Perhaps flattenedPath would be more consistent with assignedNodes({flatten: true})?

[annevk]

That does not seem entirely unreasonable (though I'd spell it flatPath()). One difference is that in the non-fallback case, children of slots are not part of the flat tree, but they can be part of the event path. I'm not sure if those subtle difference end up mattering more over time or not. If they do at some point, I think it would be better they had distinct terms.

[rniwa]

How about bubblingPath? propagationPath appears to be no so popular but has a usage that definitely breaks.

[annevk]

I think those are more confusing than composed or flat. I figured we could maybe use eventPath getting back to the original path property that I suppose we can also no longer use, but that also seems like an extremely popular term.

[annevk]

whatwg/html#1160 suggests either piercingPath or composedPath. We want to couple it with renaming scoped.

[rniwa]

Apparently, this problem was caused by TinyMCE 4.3.10, which is included in WordPress 4.5 on the contrary to my earlier statement. (Thanks @apple-web-evangelist for figuring this out!) So we probably need to do this rename since there will be a lot of websites that have this version of WordPress and/or TinyMCE and never update to a new version :(

[annevk]

So @smaug---- does not like piercing because going from shadow to light is not really piercing anything (you're supposed to have that access) and @rniwa does not like composed because nothing is really composed. Giant sigh.

Different direction: broad. We cannot really use complete or full since it isn't always, but it's broader than usual and a broad event logically reaches more EventTarget objects. findRootNode({ broad:true }) also works in that sense.

[rniwa]

broad sounds vague and won't make me think of shadow roots at all. How about shadowPath or shadowCrossingPath? dispatchPath or propagationTargets?

[annevk]

@rniwa I think ideally we have something that can also be used for findRootNode() and as replacement for Event.prototype.scoped (with opposite meaning).

[rniwa]

How about escaping then? findRootNode({escaping: true}), Event.prototype.escaping, and escapingPath.

Or leaking? findRootNode({leaking: true}), Event.prototype.leaking, and leakingPath.

Yet another alternative: emanating: findRootNode({emanating: true}), Event.prototype.emanating, and emanatingPath.

One more: exiting or shadowExiting: findRootNode({exiting: true}), Event.prototype.exiting, and exitingPath.

[annevk]

I suspect @smaug---- would not like those for the same reason he did not like piercing. Is broad that bad?

[rniwa]

I don't like it because board doesn't convey the semantics of exiting from a shadow root to a shadow host. @othermaciej @hober

[rniwa]

I talked with @smaug---- on #whatwg and he seems to like dispatchPath, and I like that name too.

WDYT?

[smaug----]

"like". I can live with dispatchPath is perhaps closer ;)
propagationPath would be way nicer, but can't be used.

though, dispatchPath doesn't play well with findRootNode, if that is one goal.

[smaug----]

composedPath and findRootNode({composedTree: true}) ?
(I couldn't quite understand the reasoning to object "compose" when looking at the IRC logs)

[rniwa]

I don't think composedPath makes sense because it contains nodes that are not in the composed tree. Also, we don't use the term composed anywhere else so that might be rather confusing.

[smaug----]

hmm, sounds like we have different meaning for composed tree. You think it as a synonym to flattened tree, I think. For me composed tree is the tree of node trees, including shadow roots and everything.

And if we don't use composed for anything else, it is a good thing. less likely to cause confusion.

[rniwa]

That's a good point. Okay, with that, we can do Event.prototype.composed and findRootNode({composed:true})

[annevk]

And composedPath? \o/ Now we just need to wait for @hayatoito to weigh in.

[hayatoito]

composed is no longer a reserved word in the Shadow DOM spec. I stopped using this term in normative sections about a few month ago. Now, we can use it freely in any meaning, if we want to re-use it.

I am fine with composedPath. I can not think of any better name.

[rniwa]

Let's go with composedPath then!