Normative definition of optionally-blockable contradicts following note

[bzbarsky]

The normative definition says:

Images loaded via img or CSS (background-image, border-image, etc)

and then has a note saying:

It does not include images loaded via picture.

But <picture> doesn't do any loading itself. It just affects what URL is used for the <img> inside the <picture>; the actual load is still "via <img>". So the note flatly contradicts the normative text.

This should be clarified.

The behavior of <img srcset> should also be clarified: is that considered a load "via <img>" or not?

[bzbarsky]

/cc @mikewest

[mikewest]

You're right. That text is bad. It should be pointing to the initiator of the request, which will be the empty string for "legacy" image requests, and "imageset" for amazing new requests. I'll fix it up.

(That said, I wonder if we're doing more harm than good by subsetting image requests, since it's probably just confusing for developers, and we're still just as far away from deprecating non-secure image requests as ever. :( )

[annevk]

You're less far away, since developers wanting to use new features might go the extra mile to enable HTTPS on their CDN or what not.

[mikewest]

Sorry this took forever for me to address. TPAC turns out to be a good forcing function. :/

I think https://w3c.github.io/webappsec-mixed-content/#category-optionally-blockable reads more clearly, and should address the specific concerns here. Thanks for the report! And apologies again that I've been slow at addressing it.

[bzbarsky]

@mikewest Thanks for the update. The "[=use srcset or picture=]" bit looks like markdown of some sort that escaped into the final rendering?

[mikewest]

Hrm. That should have linked to https://html.spec.whatwg.org/#use-srcset-or-picture. I'll go poke at Bikeshed to see why it didn't. Thanks!