DaviDevMod

Hello there, apologies for how I exposed my ideas previously, I was having a bad time. I did publish a focus trap package, eventually, in which I implemented and tested...

@stefcameron Nice to see you will work on the fix! The approach of bringing focus back only after it has escaped the trap is fine, but which element will receive...

Relying on `tabbable` and `checkKeyNav` is not a bulletproof fix, but it may work good enough so that no one will ever hit the limitations of the approach. I get...

> I'm now tempted to somehow limit positive tabindex support to a single container trap. Something like, whenever updateTabbableNodes() is called, check if >1 container && >0 positive tabindex nodes...

@stefcameron Another option worth considering is to solve the issue upstream by allowing `tabbable` to be called with an array of elements. In this way *focus-trap* can rely on the...

@stefcameron I may be wrong, but solving the issue upstream may be as easy as that: https://github.com/focus-trap/tabbable/compare/master...DaviDevMod:tabbable:multi-container Meaning no novel logic at all.

@stefcameron Glad to see you liked the approach! I've sent you a PR to add sorting of the `containers` prior to querying the `candidates`. I just realised, while writing this...

> This is starting to get non-trivial... :grimacing: I see, but it's the shadow DOM realm that complicates things, so as a last resort I think it may be acceptable...

> There's a now long-standing implication that when multiple containers are given, they're given in the order in which focus should move between them, not a random order for focus-trap...

> If we do that, though, isn't there a chance of actually changing the order resulting from sortByOrder()? That was a concern, hence why I didn't suggest removing duplicates at...