Last modified: 2014-06-05 21:51:10 UTC
Since Parsoid already runs an API call for each image given to it in wikitext, it would be extremely helpful for the editing in terms of user experience if the call also asked for the original dimensions. At the moment, VisualEditor asks for details from the API on each edited image to get its original dimensions. When this is done for the edit dialog the asynchronous call works fine because we don't mind letting the user wait the seconds it takes the async call to finish. But when the user resizes images with the mouse (with the resize handles) the information about original dimensions usually comes too late. The user may (and often does) resize the image to above its limits, and by the time VE gets the API response, the user is already done resizing. On top of that, calculating aspect ratio from original size is a lot more accurate than calculating it from the given (usually smaller) size, though, granted, this is a lot less crucial. We have some fall backs and we are considering an after-the-fact user experience ideas to make this work, but it would be extremely helpful if the information was already available when it comes from Parsoid -- especially since Parsoid already asks for information from the API.
I'm not convinced we should be bloating our Parsoid DOM representation with original size information which can easily be obtained from the imageinfo API. In order to do a proper resize, you are probably going to have to fetch the original image anyway so that things don't get blurry when you scale up. But I'm interesting in hearing other thoughts.
(In reply to C. Scott Ananian from comment #1) > I'm not convinced we should be bloating our Parsoid DOM representation with > original size information which can easily be obtained from the imageinfo > API. In order to do a proper resize, you are probably going to have to > fetch the original image anyway so that things don't get blurry when you > scale up. > > But I'm interesting in hearing other thoughts. We don't fetch the original image unless the new size is the image's original dimensions – we ask MW for the thumbnail of that size. We certainly don't ask e.g. for a 10MiB original 5000x4000px image when the user is just resizing from 250x200px to 300x240px. Also, we fetch the new image /after/ the image is resized.
I do agree we should be careful, but I think this is worth including. It's really useful and costs very little.
We have a new strategy for serializing square bounding boxes that will be helped by having original image size hanging around, so we will probably put original image size in data-mw.
On top of the dimensions, it would also be helpful to get the 'mediatype' property of images, separating them between "DRAWING" and "BITMAP". The two types behave differently, especially with size considerations. It is useful for VE to know (we request this now with our separate api call) but it might actually make sense to categorize the difference between the images for other purposes.
The size concern also matters less once we move data-mw out of the DOM. There's still the minor nuisance of having some read-only attributes in data-mw, which is otherwise a read-write interface. Maybe it would make sense to group dimensions & image type in a separate 'imageinfo' sub-object inside data-mw that is documented to be read-only. The grouping & naming should make it clearer that this is read-only info only, even without looking at the docs.
