Picking names

[padenot]

We need to decide on the final property names for HTMLMediaElement and document. Also we need to decide on the enum type names and values.

For now, #1 has document.autoplayPolicy as an attribute, and HTMLMediaElement.canAutoplay() as a method that returns a promise.

In webidl form, it would go something like this:

enum AutoPlayState {
    "allowed",
    "allowed-muted",
    "disallowed",
    "prompt"
};

partial interface document {
  readonly attribute AutoPlayState policy; 
};

partial interface HTMLMediaElement {
  Promise<void> canAutoPlay(); 
};

[beaufortfrancois]

LGTM with nits:

-  readonly attribute AutoPlayState policy; 
+  readonly attribute AutoPlayState autoplayPolicy; 

I'd also prefer if autoplay was used instead of autoPlay for canAutoplay() and AutoplayState.

[jernoble]

@beaufortfrancois

I'd also prefer if autoplay was used instead of autoPlay for canAutoplay() and AutoplayState.

Agreed. Let's not have a repeat of the camel-case controversy of the FullScreen era.

[cpearce]

How about allowedToPlay instead of canAutoplay? allowedToPlay matches the name of the exception that is thrown when play() rejects because playback is not allowed.

[ghost]

IMO we should use canAutoplay instead of allowedToPlay since we already have the autoplay attribute on the media element.

[cpearce]

IMO we should use canAutoplay instead of allowedToPlay since we already have the autoplay attribute on the media element.

I don't follow your reasoning here, could you elaborate please?

[ghost]

We use the term autoplay on the media element already for the autoplay attribute (and also this proposal uses the term autoplay in autoplayPolicy) so we should be consistent.

NotAllowedError was reused for the media element and the definition for it in the spec touches on permissions which may cause confusion.

[cpearce]

The spec refers to a media element being allowed to play, and I think what we're discussing basically just exposes that state?

There are two things that people consider "autoplay". The first is when authors set the "autoplay" attribute on HTMLMediaElement. This is what the spec considers autoplay. The second is when script calls play() on an HTMLMediaElement without the user initiating the play. Most authors use the latter mechanism and fallback to doing something else if the promise returned by play() is rejected with NotAllowedError.

Because authors tend to use play() to play automatically rather than the autoplay attribute (despite the spec's recommendations not to), I think it makes sense to align the name with the play() function rather than the autoplay attribute.

[ghost]

Okay I can see that, but if we are going down the route of a function here we probably want to use isAllowedToPlay rather than allowedToPlay.

[cpearce]

I'm not aware of a clear directive or convention here, but I note that other HTMLMediaElement attributes don't use the isFoo convention. For example HTMLMediaElement.paused and ended. The only counter examples I can think of are Window.isSecureContext, or perhaps MediaSource.isTypeSupported().

I think we're better to remain consistent with the existing pattern in HTMLMediaElement, and not have the "is" prefix.

[ghost]

If the allowed to play check is a method then it should be prefixed with is as per TAG recommendations: https://w3ctag.github.io/design-principles/#naming-is-hard

[alastor0325]

This issue could also be closed because we already decided the API naming for the first version of the draft in this PR.