I am using 'choice' with a few options to review my images, so what's we get is an image at the top/middle of the page, and a few checkboxes after it.
This works well in desktop web browser, and also in desktop browser's mobile view (Inspector tool), but its behavior is weird on my iPhone, tested with both Chrome app and Safari app.
See screenshot, I have to scroll a long way to see the two options under the image, it seems the image's height / CSS wasn't calculated properly.
Thanks for the report – I think your analysis makes sense, too! Will look into this 
The regular image view currently uses the same UI component as the bounding box and manual image annotation view. This means it’ll render the image as part of an SVG and calculate the width and height based on the loaded image file.
Just as a quick check, does the same problem occur if you provide a "width" and "height" value in the task? For example:
{"image": "foo.jpg", "width": 800, "height": 600}
Thank you Ines, for prompt reply. I will try to add the ‘height’ attribute as a workaround.
It might because I am loading images from HTTP URLs, not BASE64 encoded data. And the image loading could be slower than the JS code that you used to layout? Just guessing.
Yeah, if you already know the dimensions of the image, it might be a good idea anyways to include it with the data. It’s always useful to have, especially if you’re planning on training a model later on.
In theory, the base64 images should load faster, because once the task data is there, the front-end has all the image data it needs and only has to swap out the src – it won’t have to load a file or anything else, which delays the loading. I’m using the onload of a hidden <img> to determine the image size, so maybe there is some edge case with how that behaves when the image comes from base64 data instead of a file? 
Mostly thinking out loud here, but will definitely investigate!