Mainly introduced in:
- Lacking documentation with regards to intended behaviour.
- Buggy user-experience. The two resize handles contradict each other. On resize, three visible actions happen:
- Native browser rendering updated based on the distribution of the css-floated elements.
- First resize handle fires, which resizes the images back to their original size. This causes other content to reflow.
- Second resize handle fires, which resizes the images again (to the destination size).
E.g. Given a gallery with images that fit on one row for the current window size. Widen the window. The module is then supposed to widen the images to fill the extra space. The first resize handler makes the images smaller (original size), the second resize handle makes them bigger. Aside from it being plain wrong that the images are first being made smaller (instead of bigger), it shouldn't be doing the resize in two steps. It's fine to do some pre-computation in an earlier handler (before the 300ms debounce), but it shouldn't be causing an active reflow in both.
- Poor javascript performance.
It adds lots of inline style attributes, duplicates thereof and doesn't account for JavaScript's number type being double-precision float – thus creating lots of fractions. The img element itself has a strict integer value for the width/height, so the fractions are trimmed there by the browser.
<div style="width: 503.9604743083px;">
<div class="thumb" style="width: 501.9604743083px;">
<div style="margin: 0px auto;"><a ...><img alt="" src=".../513px-VisualEditor-logo.svg.png" width="501" ...>
</div>
<div class="gallerytextwrapper" style="width: 481.9604743083px;">
...
</div>
</div>