Fix `Our Events` Card Glitch After Toggling and Resizing Window

[tony1ee]

Overview

We need to fix the visual glitch of the Our Events cards on event page for better website user experience.

Details

It has been identified that a combination of:

• toggling the dropdown on the Our Events cards, followed by
• resizing window between mobile and tablet/desktop view

can cause a visual glitch where contents of the card is lost. See complete steps to reproduce this issue below.

Complete Steps to Reproduce the Issue

1. make the browser window narrow enough (width <=767 in Chrome developer mode) so cards in "Our Events" section will be displayed stacked in a single column 2. Open Events Page at https://www.hackforla.org/events/ 3. interact with the arrow by each card to fold/unfold cards 4. resize/widen browser window so cards appear side by side (width >767 in Chrome developer mode) 5. issue reproduced:   a. if card was folded before resizing, the content of the card will not display after resizing   b. if card was unfolded before resizing, there will be an extra symbol `∟` (`U+221F`) displayed next to the title

Visual Demo of the Glitch

 

Action Items

• [x] Update the CSS and/or JavaScript code as needed to fix this issue.

Resources/Instructions

• This issue was created per #6687
• MDN Web Docs - Window: resize event
• Events Page

Possible Direction

Preliminary research shows the following code might be related to this problem, as the following event listener is not properly registered: https://github.com/hackforla/website/blob/42954259e5cffa7ef40add46541fbcfbff0e58a8/assets/js/events.js#L30-L44

From MDN Web Docs - Window: resize event:

In some earlier browsers it was possible to register resize event handlers on any HTML element. It is still possible to set onresize attributes or use addEventListener() to set a handler on any element. However, resize events are only fired on the window object (i.e. returned by document.defaultView). Only handlers registered on the window object will receive resize events.

[roslynwythe]

Great job writing this issue @tony1ee. It is not clear to me why this would be labelled as Feature: Accessibility. I would suggest the Bug label. Also I noticed the 3 pt label. Do you feel that the issue will take 13-18 hours to complete?

[tony1ee]

@roslynwythe Thank you, label updated.

Size label was copied from the ER as my estimation for total research, implement and testing time. You are correct, this probably won't take another 13-18 hours since some research is already done.

I've adjusted the size label to reflect my estimation of the remaining time needed to complete this issue from this point on.

[github-actions[bot]]

Hi @tony1ee, thank you for taking up this issue! Hfla appreciates you :)

Do let fellow developers know about your:- i. Availability: (When are you available to work on the issue/answer questions other programmers might have about your issue?) ii. ETA: (When do you expect this issue to be completed?)

You're awesome!

P.S. - You may not take up another issue until this issue gets merged (or closed). Thanks again :)

[ExperimentsInHonesty]

@tony1ee I assigned you the issue and will move to in progress. I also revised upward the size to account for the research you already did to make the issue.

[tony1ee]

Availability: 04/28/2024 afternoon and evening, 04/29/2024 evening, 04/30/2024 morning. ETA: EOD 04/30/2024

[tony1ee]

Trying to solve it by making changes to assets/js/events.js following the MDN Web Docs and register the eventListener for resize to window instead of .flex-page-card, so resize events can actually trigger handleScreenResize().

With this change, handleScreenResize() can now work as intended therefore the original issue is addressed. However, I also discovered an issue with the original handleScreenRize() code, where it did not handle width changes within #bp-below-tablet (e.g. from 765 to 755), and can make unfolded cards unexpectedly collapse while resizing, as shown below:

Will work on a fix for this new issue before submitting a PR request.