EventCatcherWidget and mouseenter

[CodaCodr]

Probably @saqimtiaz ...

I've been playing around with https://tiddlywiki.com/#EventCatcherWidget. Specifically, I took the example from that tiddler and and added mouseover and mouseenter.

mouseover works as I'd expect.

mouseenter has issues. Stepping through the code in $:/core/modules/widgets/eventcatcher.js, I see that on line 51, selectedNode taken from event.target, gets div.tc-eventcatcher whereas I think the later code wants/expects div.item.

Looking at the event object, the explicitOriginalTarget property is the only prop carrying div.item.

It's not clear to me (I didn't investigate) what phase the widget expects to be handling - mouseenter does not bubble so maybe that's the root of the issue - that the parent "trap" is the only point at which it can be caught?

I didn't file a bug - I'm not confident it is one and I have more questions than answers ;)

[saqimtiaz]

@CodaCodr the eventcatcher handles the bubbling phase of events, so any event that does not bubble will not be captured as things stand. It is worth making a PR to add this to the documentation if you have the opportunity.

There may be a workaround we can explore for events that do not bubble, i.e. adding the event listener on the capturing phase, but it will be a bit tricky as a single eventcatcher widget supports multiple events (some of which might bubble and others not). If we cannot find a user-friendly way to accommodate both, we may have to live with this limitation.

Note that explicitOriginalTarget is not a standard attribute and cannot be used.

I need to focus on another project for the next week or two where we have a pressing deadline. I can try to have a look after that unless someone beats me to it.

[CodaCodr]

@saqimtiaz Still playing around with EC... here's my current thinking.

1. If we're only dealing with bubbling, we need an attr allow-propagation="no" (default "yes") on the eventcatcher element (span/div). I realize this might cause havoc in TW if misused, but I also think the disclaimer "This is an advanced widget intended to be used by those familiar with HTML, CSS and JavaScript" covers that. If there's a workaround for stopPropagation, I'd love to hear about it.

2. Trying to write wikitext that drives underlying event handling code that might be intended to mimic CSS :hover is best achieved with mouseenter, not mouseover (so says the mdn stuff I've read - makes sense to me). You want one event for mouse entering and one for it leaving again. if eventcatcher v2.0 could support mouseenter (and any other worthy non-bubbling events) that would be cool.

3. The docs talk about "JavaScript events". As I'm sure you're aware, JavaScript does not have any events (apart from low level stuff that engine implementers deal with) but merely provides bindings to the APIs made available from the DOM. The more I read the doc, the more I believe JavaScript shouldn't even be mentioned (exception: the disclaimer I mentioned above). FIX: Better to use "DOM events", I think. (You could use "Web APIs" but that's a much broader brush with potential for confusion).

Sorry this is "late" - I really should have begun playing around like this well before 5.1.23 went live.

I know you're busy, don't rush to respond...

[saqimtiaz]

3. The docs talk about "JavaScript events". As I'm sure you're aware, JavaScript does not have any events (apart from low level stuff that engine implementers deal with) but merely provides bindings to the APIs made available from the DOM. The more I read the doc, the more I believe JavaScript shouldn't even be mentioned (exception: the disclaimer I mentioned above). FIX: Better to use "DOM events", I think. (You could use "Web APIs" but that's a much broader brush with potential for confusion).

This isn't an oversight but rather intentional. The documentation on TiddlyWiki.com is written for the average user who does not have a technical background. Technical documentation, especially those that require an understanding of programming languages (as event delegation does) belong on tiddlywiki.com/dev. The <$eventcatcher> is unique in straddling that divide because it can be used with wikitext but requires an understanding of how event delegation in JavaScript, and the DOM work. So there is a judgement call involved in how to present the documentation.

Most TiddlyWiki users tend to separate changes and tweaks to TiddlyWiki into those that require JavaScript and those that do not. In this particular case, use of the term JavaScript events is well understood and is common parlance - even if not strictly accurate - among developers, while still highlighting to the non-technical users that it likely requires skill and knowledge that is beyond just use of wikitext. Furthermore it would be quite difficult to talk about event delegation without mentioning JavaScript.

Note how we have tiddlers to disambiguate and explain what JavaScript is, as well as (in 5.1.23) "Web Developer Tools". Adding yet another term such as "DOM events" to confuse and have to explain to the non-technical user is not desirable in my opinion. This is my take on it of course and I am not the final authority on how the documentation should be written and Jeremy may feel differently.

What I would suggest instead is perhaps adding some disambiguation, for instance:

"The event catcher widget traps JavaScript events (strictly speaking DOM events) dispatched within its child content, and allows invoking a series of ActionWidgets in response to the events. ",

OR perhaps even better:

"The event catcher widget traps JavaScript DOM events dispatched within its child content, and allows invoking a series of ActionWidgets in response to the events. ",

with a link to more technical documentation on tiddlywiki.com/dev

I would welcome a documentation PR in this direction.

[CodaCodr]

[...] there is a judgement call involved in how to present the documentation. [...] Adding yet another term such as "DOM events" to confuse and have to explain to the non-technical user is not desirable in my opinion.

Fair.

PR? I have zero GH skills. :/

[saqimtiaz]

A PR for a single tiddler is arguably easier than using the eventcatcher:

1. use the github search to find the file for the tiddler you want, something like eventcatcher wont have many matches.

2. From the branch dropdown to the left of the file title, choose tiddlywiki.com for changes meant to go live immediately:
   

3. Click the edit button. It will fork the project for you and allow you to edit the file.
   

4. Edit the file (tiddler). You can copy the text on to the same tiddler on tiddlywiki.com (or tiddlywiki.com/dev depending on the content) to test it. Or you can start on TiddlyWiki.com, edit the tiddler. Then copy your changes to Github in this step. You can also preview in Github to see a diff of the changes. It is easier than it sounds.

5. Propose changes, adding a message as to what you changed.

6. Create a Pull Request adding the same message as in Step 5 or a bit more explanation if not self explanatory.

From step 3 onwards it is almost a guided flow, and the entire process can be accomplished on the Github site without the need for commandline shenanigans. Also there is no chance you can create problems for others.

[CodaCodr]

A PR for a single tiddler is arguably easier than using the eventcatcher:

LOL. I'm looking at it now.