It seems just setting correct width and height HTML attributes is now going to work in modern browsers, without any new standard.
So the "data:" stuff no longer applies, it will be automatic.

Good article: https://www.industrialempathy.com/posts/image-optimizations/

This is a complex morass of an issue.

Essentially we are talking about:
- Lazy loading of images
- Not having CSS repaints happen when a responsive image finally loads
- srcset support for content authoring
- More precise control of image sizing

I'm nuking most of it on the basic of:
- Overcomplexity
- The web standards folks have got ahead of this issue

Lazy loading is now possible with loading="lazy" on the image tag. Very simple. I think we can reasonably assume any Comcode/attachment image in Composr should be lazy loaded, because that kind of image lines up almost perfectly with the kind of thing that should be (i.e. you want content images to be lazy loaded but fundamental design images not to be). We don't need to make it configurable because the user can always customise their own HTML.
*I have just added this.*

I think a precedence system for lazy loading is overkill, the browser can be trusted to do this (besides, it is parallelising requests).

CSS repaints was already fixed by browsers allowing CSS to tentatively assume the HTML-supplied width/height attributes in the HTML are correct hints to an images aspect ratio. A reasonable assumption that at worst creates a repaint (which would need to happen anyway) if the assumption proves wrong.

srcset is obviated by people using SVG images. v11 is going in very heavy with SVG. For the small and very thin remaining case of people wanting hi-dpi support for raster images shown for content, they can hand edit their HTML.

Making image sizing more precise is not really needed at the Comcode layer. At the CSS layer we now don't allow any images to overflow via our default CSS rules. Intrinsic size is the default. Specific size is possible by specifying width/height. Responsive is the default *FOR OVERFLOW*. I think that covers the vast majority of use cases without adding extra complexity.