[BUG] Equalize - Update doesn't work anymore

[agagnon]

I have a page with dynamic content and I used to use $( ".wb-eqht" ).trigger( "wb-update.wb-eqht" ); to update Equalize for visible elements.
It worked with WET 12.6.0, but I switched to 13.2.2 last week and the update seemed to not be working anymore.

I use the eqht-trgt and it seemed that there was a fix for that in version 13.2.1 and it broke the update feature. I actually tried with v13.1.0 and it worked properlly and it is broker in 13.2.1.

Can it be fixed?

[EricDunsworth]

@agagnon Does your page happen to be public? If so, would it be possible to provide a link to it? Or maybe a code sample?

I wouldn't of expected #9589's changes to have impacted wb-update.wb-eqht apart from improving how it calculates equal heights when eqht-trgt is in play.

Does your page contain multiple rows of equalized content? Is your expectation to see every grid across every row being based on the tallest row? If so... my PR deliberately undid that behaviour since it was inherently a bug :(.

[agagnon]

Here is my page using v13.2.2 (equalize update not working) : https://www.asc-csa.gc.ca/fra/evenements/
Here is the exact same page using v13.1.0 (equalize update working) : https://www.asc-csa.gc.ca/temp/

There is a list of events, filtered. When you change the filter, I use "Equalize update" to make all visible events the same height. With 13.1.0, is works fine. With 13.2.2, it doesn't work and you can see the events are not the same height.

[agagnon]

Just updated the temp page because the "/fra/evenements" page has changed.
You can choose filters "Activités" and "Terminés" and you'll see the issue in the "/fra/evenements" page.

[EricDunsworth]

@agagnon I think I figured it out :O.

What seems to have happened is that the new vertical offset logic #9589 added doesn't play nicely with hidden (display: none;) elements that are in the scope of equalization.

The equal heights plugin detects "virtual" rows by comparing the vertical offsets of all elements that are to be equalized:

• In the past, each element's vertical offset was based on their offsetTop property.
• #9589 changed it to be based on a calculation (currentChild.getBoundingClientRect().top + window.pageYOffset). That's more reliable when dealing with visible elements... but apparently not with hidden ones :(. The vertical offset of hidden elements seems to be getting derived from the viewport's top scroll position - which causes their vertical baseline to be inconsistent with those of visible elements. End result is that when the plugin encounters a hidden element after a visible element, it gets tricked into thinking a new virtual row is starting and ends up botching its min-height calculations.

I'll try sending over a PR to fix it sometime this week (hopefully tomorrow).

[EricDunsworth]

Just sent over #9639. It fixes messed-up equalization caused by hidden grids in-between visible ones. So min-height is set more consistently across rows now.

@agagnon Based on my local testing, it looks like your GCWeb v13.2.2 page has another twist to it that clashes with equalization :P. It's setup to lazy-load images. When a user plays around with the filters, equalization occurs on rows of grids that are off-screen. If many rows of results appear, the off-screen rows will be equalized without taking the images into consideration (since they don't load in unless they're on-screen).

So with my fix in play, everything technically gets equalized properly... but when a user scrolls down and the lazy-loaded images come into play, their grids grow taller :D. So the min-heights the equalization plugin setup earlier on become outdated.

To get around that issue, you'd probably need to do one of the following (from best to worst):

• Give up on the equal heights plugin and use one of these instead:
  • Use flexbox classes to get the same effect via pure CSS (not sure if all the classes that'd be needed for it currently exist)
  • Use the equal heights CSS plugin (requires JavaScript)
• Enhance the equal heights plugin to automatically re-equalize when heights change in realtime using something along the lines of a DOM mutation observer
• Stop lazy-loading images (not ideal)

[EricDunsworth]

@agagnon Here's what I'd suggest to transition those events pages to flexbox CSS:

• Events / Événements pages:
  • Change the <div id="list"> element's class attribute to gc-prtts small
  • Change the ul element's class attribute to list-unstyled d-sm-flex flex-sm-wrap
  • Change the li elements' class attribute to blog col-sm-6 col-md-4 mrgn-bttm-sm d-sm-flex
  • Change the article elements' class attribute to d-sm-flex
  • Change the a elements' class attribute to d-sm-flex mrgn-bttm-lg
  • Change the figure elements' class attribute to thumbnail thumbnail_MOD mrgn-bttm-0
  • Bonus - fix HTML validation errors:
    • Both pages:
      • Don't nest <p class="date"> within "parent" p elements
    • French page:
      • Replace the date element with time
      • Remove duplicate </span> closing tag after "Association of Science Teachers"
• evenements.css
  • Remove display:block; from the second #list a selector (to stop overriding the d-sm-flex class's display: flex; property)
• evenements.js
  • Remove $( ".wb-eqht" ).trigger( "wb-update.wb-eqht" )

Hope this helps :)!