Not All Browser Events are Represented in py-on* Events

[JeffersGlass]

Checklist

• I added a descriptive title
• I searched for other issues and couldn't find a solution or duplication
• I already searched in Google and didn't find any good information or help

What happened?

A handful of potential browser events are not currently representable using the py-* event syntax, including auxclick, compositionstart and its related events, focusin, and others.

I don't know if this list can be considered definitive, but ideally the py-on* events should cover all possible browser events.

What browsers are you seeing the problem on? (if applicable)

No response

Console info

No response

Additional Context

No response

[tedpatrick]

The event syntax has changed to align with the DOM event spec naming as follows:

The attribute py-click equates to the DOM Event Spec click event.

<div py-click="foo()">click me</div>

Additions can be added here: https://github.com/pyscript/pyscript/blob/main/pyscriptjs/src/components/pyscript.ts#L119-L211

I wish this was dynamically created so we didn't need to denote these. If an attribute has py-, we should simply subscribe and thus these never need to be in the PyScript codebase and we support them all, always into the future. If this moved to mutation observer, it would also always be accurate if anyone edited the DOM live to add these.

[marimeireles]

Do we want to have all events represented?
Are we moving away from this interface now with the use of handlers? @tedpatrick are there plans to work on it?

[JeffersGlass]

This is a question I had @marimeireles - I really like the new handler work, but I was wondering if it was meant to replace the py-[event] syntax or coexist with it?

Personally, I like the idea of having both, it gives users the ability to use a Python function as an event handler from within the HTML or within the Python code, depending on which is easier/better for them. But that's just my feeling.

[tedpatrick]

There will be many new events in time. If we list them all in pyscript, we will always be wrong. Ideally we provide a way to access addEventListener cleanly. The @handler simply takes care of the py-proxy creation and uses addEventListener.

The py-events are different and are currently limited to the list of events in pyscript. I wanted to make these events dynamic as follows:

1. No list of event names, they all just work.
2. Add/remove attributes anytime and the events are wired/unwired.

This last step was hard and required using Mutation Observer which I found was flaky. So end of the day, I passed on doing anything with py-events and focused @marimeireles on the decorator.

[marimeireles]

Will be closed by https://github.com/pyscript/pyscript/pulls

[WebReflection]

Hello there, I just came across this long discussed issue and proposed various improvements to the events in this PR #1403 including the ability to look for any py-* event on any element so that we don't need to maintain anymore the list of events that easily gets outdated, or it doesn't play well with the variety of browsers supporting this or that event type.

The solution is to use te mighty XPath instead of CSS selector, superior in fact to Mutation Observer or querySelectorAll because it can actually crawl attributes nodes and screen those which name starts with py-.

[WebReflection]

@tedpatrick specific for this point:

Add/remove attributes anytime and the events are wired/unwired.

This is a bit more convoluted/complicated because we need to observe the whole document subtree for any attribute change and we need to retain previous value per attribute to be able to remove the previously attached listener or add a new one.

This is all doable but I feel like it'd be great as PR a part, as the current one addresses:

• No list of event names, they all just work.
• any previously added listener can now be removed or updated

The rest of the logic needs extra orchestration but it should work if done properly and, hopefully, without slowing down the whole DOM execution.