“Effective size” error handling

[eeeps]

Right now if we can’t determine an ‘effective size’ we return 300px.

(Presumably, if #86 sees implementation, there will be an effective box size of 300 × 150 — the default size for replaced elements).

Could we instead wait for layout, figure out what the rendered size of a source with infinite pixel dimensions would be, and use that as an effective size?

This seems like it would produce the expected results in cases where authors use media queries which the browser can't parse, improving backwards compatibility for e.g. the new media query syntax.

It also complicates implementation and might hide authoring errors.

One additional benefit: authors could leave off the sizes attribute intentionally in cases where they don’t care about preloading, e.g. for postponed images.

[zcorpan]

We can't wait for layout, that's incompatible with the goal of enabling early load of images. We want to be able to load images in the pre-scanner even.

That said, I'm not sure I like the 300px default. If the sizes attribute is absent we could let the effective size be "error" and drop candidates with missing density descriptors on the floor. It's an authoring error to do <img srcset="foo.jpg 500w"> without sizes, and it's less noticeable for the author that something is wrong if it magically does something instead of falling back to src.

[eeeps]

If/when there's a way to explicitly mark up an image as something you want loaded later (lazy loading), it would be nice to be able to mark it up in a layout-agnostic way. But yeah, error-handling that would also apply to images that hadn't been marked as lazy-loaded probably isn't the way to do it.

Falling back to src rather than picking a size based on 300px makes sense to me, though I bet in many cases they'd have the same result (picking the smallest source).

[zcorpan]

Thinking about it some more, we could change the default to 100% instead of 300px. That seems like a useful default.