File Mozilla standards position even for trivial items?

[Rick Byers]

Hey Martin,

Given your comment here, I wanted to get your take on the issue below. It's a tiny addition to an existing spec and a Mozilla engineer has commented on the spec PR that they're happy with it. My guidance was not to bother polluting your standards position repo asking for a position on this - it's not worth anyone's time even to look at it. Instead I thought we should pragmatically approve it with only the unofficial position and so officially "no signals". WDYT?

Any guidance you can provide on how you'd like blink API owners to apply the mozilla standards position process would be welcome.

Thanks,

   Rick

---------- Forwarded message ---------
From: Yoav Weiss <yoav...@chromium.org>
Date: Wed, Nov 23, 2022 at 12:21 PM
Subject: Re: [blink-dev] Intent to ship: Media Session API: Presenting slides actions
To: Rick Byers <rby...@chromium.org>
Cc: François Beaufort <fbea...@google.com>, blink-dev <blin...@chromium.org>, Tommy Steimel <ste...@google.com>

On Wed, Nov 23, 2022 at 6:14 PM Rick Byers <rby...@chromium.org> wrote:

Seems like a tiny addition to a well supported pattern.  LGTM1 from my perspective. 

Other comments inline

On Wed, Nov 23, 2022 at 12:02 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Wed, Nov 23, 2022 at 5:15 PM 'François Beaufort' via blink-dev <blin...@chromium.org> wrote:

Contact emails

fbea...@chromium.org, ste...@chromium.org

Explainer

https://github.com/w3c/mediasession/issues/274

Specification

https://w3c.github.io/mediasession/#dom-mediasessionaction-previousslide

https://w3c.github.io/mediasession/#dom-mediasessionaction-nextslide

API spec

Yes

Summary

Adds "previousslide" and "nextslide" actions to the existing Media Session API.

Blink component

Blink>Media>Session

Motivation

This will enable developers of video conferencing websites to handle these actions from browser UI. For example, if the user puts their slides presentation into a picture-in-picture window, the browser could display buttons for navigating through slides. When the user clicks those, the website handles them through the Media Session API.

Neat! :)

 

TAG review

This small addition to the Media Session API doesn’t seem to qualify for a TAG review. 

Note that one for video conferencing actions was approved previously at https://github.com/w3ctag/design-reviews/issues/608

Thanks, that's good to see. The explainer linked there was also helpful to me to quickly understand how this is used.

TAG review status

N/A

Debuggability

No DevTools changes are required, treated like any other attribute/enum.

Risks

Interoperability and Compatibility
It’s low risk as it's a small addition to an existing API that both Gecko and WebKit approve of.

Signals from other implementations (Gecko, WebKit): 

Gecko: Positive (https://github.com/w3c/mediasession/pull/284#pullrequestreview-1106405304)

WebKit: Positive (https://github.com/w3c/mediasession/pull/284#issuecomment-1217526791) 

Can you file for official positions? https://bit.ly/blink-signals

Personally I'd be also fine calling this "no signals" - it's a very tiny addition and Gecko and WebKit already support the general pattern.

In general I feel like we should have some pattern for making small tweaks to exposed APIs that doesn't pollute these standards position repositories with noise. Yoav, WDYT?

I'm fine with calling this "no official signal" while pointing to the PR comments.

I was mostly trying to avoid them feeling we're misrepresenting their opinions.

 

Web / Framework developers: Positive - The existence of the popular (100K+ users) Remote for Slides extension (https://chrome.google.com/webstore/detail/remote-for-slides/pojijacppbhikhkmegdoechbfiiibppi) proves that there is strong user demand for a (remote) slide control feature, up to the point that they would install an extension just for that.

Nice signal!

 

Ergonomics:

N/A

Activation:

Web developers will be able to simply set/unset a media session action handler for “Previous Slide” and “Next Slide” to control the visibility of the button in the Picture-in-Picture window. When the action name is not supported, it raises a TypeError which can be caught to detect feature support.

Is this feature fully tested by web-platform-tests?

https://wpt.fyi/results/mediasession/setactionhandler.html 

Will someone be adding the two new actions to this test? You'll probably want the new ones in a separate test case.

The test is pretty trivial - just makes sure actions can be added, without verifying that callbacks get invoked. But IMHO I wouldn't personally see building an automation pipeline for testing the callbacks as high priority.

Tracking bug

https://crbug.com/1363548

Estimated milestones

DevTrial on desktop 110

DevTrial on Android 110

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5090980649238528

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5%2Bn-3MqwWueapG7K_3GoRSCJ4L1dRq6zmj%3DW2cQ2XT%2BYA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWeKA6%2BYj9j0dmLfAUJMSV23PW0ZKL7ZR%2BZGHSRrJrb%2BA%40mail.gmail.com.

[Martin Thomson]

Hey Rick,

There have been a few things recently where we have sort of wondered why there was a request for something so trivial.

However, if you think that it is important enough to require a position from us, then this is the way we would prefer you ask.

As you say, the question is really whether the Blink process should require signals. And I guess how you decide something is trivial enough to qualify. That isn’t easy, I know, but I do tend to agree that small stuff can be done without this sort of overhead.

[Rick Byers]

Perfect, thanks Martin. I think when we've asked for signals on something trivial in the past it's just been out of our sincere desire to engage y'all in whatever way you prefer. Your response does a good job of capturing the nuance so we'll try to apply it a bit more pragmatically. 

As always, don't hesitate to reach out to any of us (this public list or any of the API owners privately) if you have any suggestions for how we could better engage or otherwise alter our processes to work better for Mozilla.

Thanks,

  Rick