Re: [webcomponents] Change deepPath() back to path (a FrozenArray<EventTarget> attribute) (#428)

Sure, here's how I view the options. Where there is uncertainty, I'll give a percentage of the odds I'd give if running a (very strange) lottery. If the real odds were much different and could be known, I might view things differently.

**Option A)** Event.path as a property, including the behavior change of 4.

* Pro: 90% chance of fast interop
* Con: 10% risk of compat issues forcing a move to Option B or E.

(I assume this also includes the changes during dispatch when crossing closed shadow tree boundaries, not just the final emptying of the array. This doesn't change the situation because v0 is open.)

**Option B)** Event.path as a property, also reverting behavior change of 4.
* Pro: 100% chance of fast interop
* Con: A silly API that will presumably still change during dispatch, just not at the end.

**Option C)** Event.path() as a method
* Con: Longer path to interop, even riskier than trying to remove Event.path outright. Not worth further consideration IMHO.

**Option D)** No action. Event.deepPath() as a method.
* Pro: 100% chance of eventual interop on deepPath()
* Con: 80% risk that Event.path will never be removed from Blink because we have no way of estimating the compat risk.
* Con: 20% risk that eventually Blink will have a strong hold in *some* market, causing enough compat problems to compel other engines to also implement Event.path, eventually spreading to 100% of engines. (This scenario is currently unfolding with many webkit-prefixed APIs.)

**Option E)** Add Event.getPath() or Event.currentPath()
As my concern is the future of the Event.path property, I view this like Option D.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/428#issuecomment-196220128