There’s two approaches that can be used here, general and particular.
For scaling the images generally, the content management system can include a post-processing rule regarding how the dimensions HTML is generated. This approach is adquate, maybe even preferred, for a number of systems where you’d want the system (instead of the author) to take care of how the images are scaled automatically (e.g. making all of the images in a news article or forum topic the same width).
For scaling particular images to particular dimensions, I agree some kind of additional syntax would be required. Since people are wanting to add other particular attributes to page elements in Markdown, this is a good fit for the consistent attribute syntax extension, rather than creating a seperate syntax just for image dimensions. Different scaling attributes/techniques could be supported via different attributes too.
I don’t believe support for image dimensions needs to be added to the core spec, since the general approach + HTML for particulars has worked fine up until now and the already large CommonMark core is focused on the features found in the original Markdown spec. So I propose we move this discussion to “Extensions”.
I’d like to bring this subject on the table as it seems important and not decided yet.
The basic reason we need image dimensions flags is that a standard cannot rely on definition only but has to include resolution too, and both at the same time if possible.
The world is going high dpi, (or retina for fruit people), and the quality of a document should not rely on a design based on one only (old) type of screen device.
The same way you are pleased to have vector quality for your fonts, why do you want to force the image item type to be stuck at a basic level of quality ?
Example: I want to include a screenshot in my markdown to show how to use a GUI, I don’t want to have to reduce the quality of my GUI screenshot to 640x480 where it becomes unreadable just so it can fit into my markdown page, a simple example like this should be enough to prove the current limitation of the image markdown support.
Ps: The dimension feature should not rely on percentage because the layout needs to be source quality/definition agnostic.
here my humble syntax proposal:
 for setting width / height at the same time
 for setting the width and auto-ratio for height
 for setting the height and auto-ratio for width
Thanks for reading me, I hope it can help and make things moving the right way.
Is this still under discussion? This thread is linked from all over the internet (e.g. StackExchange) as the canon of image dimensions in markdown, but it doesn’t seem there’s been any movement in a couple years.
FWIW, I would love to have this option, with really any syntax.
