DOM Event Handling

Relevant source files

The following files were used as context for generating this wiki page:

• js/myJs.js
• index.html
• css/style.css
• css/spinload.css
• README.md

DOM Event Handling in this project manages user interactions to create an interactive "crush" proposal interface. It utilizes jQuery to bind events to HTML elements, triggering visual transitions, audio feedback, and evasive UI behaviors. The system primarily relies on mouse movements, clicks, and focus events to drive the application logic and state changes.

Sources: js/myJs.js:15-150, index.html:42-53

Application Initialization and Preloading

The initialization phase prepares the UI by hiding content and managing the preloader state. Upon the document being ready, the script executes a sequence to transition from the loading screen to the first interaction.

• Preloader Removal: A setTimeout function delays the transition for 600ms, then fades out the .spinner and #preloader elements.
• Content Visibility: The script sets the body overflow to visible and invokes the firstQuestion() function to display a SweetAlert2 modal.
• Text Injection: Configuration values from textConfig are injected into DOM elements with IDs #text3, #text4, #no, and #yes.

Sources: js/myJs.js:16-32, css/spinload.css:1-12

The diagram illustrates the sequence of operations that occur immediately after the DOM is fully loaded.
Sources: js/myJs.js:16-30, js/myJs.js:34-44

Evasive Button Logic

The #no button implements evasive behavior through mousemove and click event listeners to prevent the user from selecting the negative option.

Movement Triggers

The script tracks a counter n to determine the button's movement behavior:

1. First Interaction (n < 1): Invokes switchButton(), which swaps the CSS coordinates (top and left positions) of the #yes and #no buttons.
2. Subsequent Interactions (n > 1): Invokes moveButton(), which assigns random CSS top and left values based on the screen width to relocate the button within a defined range.

Sources: js/myJs.js:76-81, js/myJs.js:47-72

Audio Feedback

Every evasive movement triggers audio playback. The switchButton function plays duck.mp3, while moveButton plays Swish1.mp3.

Sources: js/myJs.js:48-49, js/myJs.js:59-60

Response Input Simulation

When the user clicks the #yes button, a SweetAlert2 popup appears containing a text input field (#txtReason). This field uses focus and blur events to simulate a "forced" response.

• Focus Event: When #txtReason gains focus, the script starts a setInterval that executes textGenerate() every 10ms.
• Text Generation: textGenerate() captures the current input length and replaces it with characters from a predefined string (textConfig.text9), effectively forcing the user's input to match a specific message regardless of what they type.
• Blur Event: When the input loses focus, clearInterval stops the simulation.

Sources: js/myJs.js:106-149, js/myJs.js:86-103

The sequence diagram shows the relationship between user focus events and the automated text generation loop.
Sources: js/myJs.js:143-150

Event Mapping Summary

Event Type	Target Element	Function / Action	Purpose
ready	document	Anonymous function	Initializes UI and triggers preloader exit.
mousemove	#no	switchButton / moveButton	Prevents selection by moving the button.
click	#no	switchButton	Swaps positions if screen width >= 900px.
click	#yes	SweetAlert2 Popup	Displays the reason input modal and plays tick.mp3.
focus	#txtReason	setInterval(textGenerate)	Begins the automated typing simulation.
blur	#txtReason	clearInterval	Stops the automated typing simulation.

Sources: js/myJs.js:15-150, index.html:48-51

Conclusion

The DOM event handling in this project creates a controlled user experience by overriding standard input behaviors. By combining jQuery event listeners with dynamic CSS manipulation and SweetAlert2 modals, the system ensures that the application flow leads to a predetermined outcome (the "yes" response) regardless of the user's initial choices.

Sources: js/myJs.js:1-150, index.html:1-66