The reason there is white-space and 2 rows is because the number of images I defined per row exceeds the width that will fit on your device; it wraps to a new line, as expected. Also, there is a skyscraper image (to eliminate a popping effect, the scroll container must be tall enough to accommodate the largest image).
You are requesting a major change for a standard feature of VaultWiki, where the benefit of that change will only affect a small number of imports and will be obsolete in a few months anyway. It is not clear to me whether fotorama supports:
1. multiple rows in one -rama
2. limits on the number of images per row
3. when combining 1 & 2, multiple "pages" of images in one -rama
4. captions for each image and their thumbnails
5. images of various aspect ratios and sizes without "popping" (especially for the main image when clicked)
It uses jQuery, and is therefore not compatible with our existing lazy-loader.
All of this is required for the GALLERY tag as designed, needs to be customizable with each use of the GALLERY tag, and for the most part, already works as expected in the current implementation. The existing implementation can possibly be improved by:
- forcing square thumbnail images inside the GALLERY (so the thumb is not skyscraper). This reduces whitespace by reducing the need for the popping solution (except for the main gallery image).
- possibly finding better responsive rules for the gallery rows (without reintroducing popping). Possibly, square thumbnails can be made fluid, and shrink automatically to prevent wrapping to a new line. If the thumbnails are below a certain width, captions automatically disappear and become tooltips only.
- redrawing the GALLERY if the window is resized, if still necessary after the previous improvements
- on small width devices that have touch support, eliminate the arrow buttons and use swipes to move left or right.
My proposal was to wrap converted images in a GALLERY tag, which would reduce the likelihood of a new line forming, especially if a small number of images is defined per row and scrollable mode is therefore activated. If you do not prefer that idea over the current behavior, then we don't really have to do anything to improve non-inserted-attachments-that-are-converted-to-FILE-tags-at-the-bottom-of-the-page-during-an-import, because whatever solution we make will be obsolete when those attachments are at long last no longer imported that way.