Expose both requested and actual preload state

[foolip]

The preload IDL attribute is defined to reflect the content attribute. However, preload="auto" or even preload="metadata" isn't appropriate on all platforms, and Chromium sometimes returns "none" regardless of the content attribute's value, see HTMLMediaElement::preloadType() which is used for the preload IDL attribute as well.

In order to expose both the content attribute's state and what will actually be used, I suggest allowing preload to return the real state and adding defaultPreload to merely reflect the content attribute, similar to defaultMuted.

I argued elsewhere that we need an "effective preload" state, and by letting preload return it we could spec Treat preload="none" as preload="metadata" when load() is called quite easily.

@mounirlamouri

[mounirlamouri]

Can we first spec the preload IDL attribute to return the effective preload state and only add deafultPreload if needed? Basically, it would make preload behave like an enum attribute for which the default value and the allowed values depend on the implementation.

[mounirlamouri]

/CC @cpearce @jernoble

I wrote this simple test page that shows how the preload IDL attribute behaves: https://mounirlamouri.github.io/sandbox/preload/api-exposure.html

As far as I can see:

• Gecko shows the "parsed" preload and the empty string if unknown/invalid.
• WebKit shows the "parsed" preload and auto if unknown/invalid even on iOS where metadata is the default one and auto is not allowed.
• Blink shows the effective preload state. It would behave like Firefox and Safari when all values are allowed apart for unknown/invalid cases. When unknown/invalid reverts to auto, Chrome and Safari will behave the same.

UA seems to have very different behaviour. I think it would unlikely break websites to change the spec to ask preload to expose the effective preload type but because it would not affect Blink, I might be biased :).

@cpearce and @jernoble, WDYT?

[foolip]

I've tested https://mounirlamouri.github.io/sandbox/preload/api-exposure.html on Edge and it says:

• none exposed as none
• metadata exposed as metadata
• auto exposed as auto
• default (no value) exposed as metadata
• invalid value ('foobar') exposed as metadata

[mounirlamouri]

That's interesting. They seem to have the same behaviour as Blink then.

[foolip]

Except for the default value, yes, and these tests don't reveal if there are any cases in which it's not merely reflecting the content attribute.

[mounirlamouri]

My goal here is to first decide whether we should change preload to return the effective preload type then decide whether reflecting the parsed preload content attribute makes sense. My gut instinct says that it probably wouldn't but I think these two questions can be solved after each other especially because if we don't reflect the effective preload type, preload should be a straightforward enum content attribute reflection.

[domenic]

I know this is an old bug and probably not high priority for the parties involved anymore, but I'll note that we generally want to have reflected IDL attributes for all content attributes. This is necessary for some frameworks that only support properties (IDL attributes) and not (content) attributes, such as React.

So, I think defaultPreload that straightforwardly reflects is a good idea, if someone wants to prioritize it.