Intent to Prototype & Ship: toJSON() for MediaSettingsRange

76 views
Skip to first unread message

François Beaufort

unread,
Jul 22, 2020, 12:52:41 AM7/22/20
to blink-dev

Contact emails


fbea...@chromium.org, rei...@chromium.org


Spec


Specification: https://w3c.github.io/mediacapture-image/#dom-mediasettingsrange-tojson

PR: https://github.com/w3c/mediacapture-image/pull/234

Summary


Allow web developers to aggregate and easily log media settings ranges (max, min, step) in JSON.


Motivation


Adding toJSON() to MediaSettingsRange will improve developer ergonomics by allowing web developers to easily log and aggregate exposureCompensation, exposureTime, colorTemperature, iso, brightness, contrast, saturation, sharpness, focusDistance, pan, tilt, and zoom.

For info, MediaDeviceInfo returned by navigator.mediaDevices.enumerateDevices() already has a toJSON() method.


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?


The feature will be supported on all platforms.


Interoperability: None
Gecko: No Signal

Webkit: No Signal


Compatibility: None

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Web platform tests will be updated and available at https://wpt.fyi/results/mediacapture-image.


Feature dashboard

https://www.chromestatus.com/feature/5677894124699648

Mike West

unread,
Jul 23, 2020, 9:15:04 AM7/23/20
to blink-dev, Francois Beaufort
Adding a default `toJSON()` implementation seems like a quite small and reasonable thing to do, without substantial interop risk.

That said, I do wonder whether both `MediaSettingsRange` and `MediaDeviceInfo` could be `dictionary` objects rather than `interface`s. That would, I think, allow `JSON.stringify()` to operate on those objects without doing any additional work, as all the types seem to be JSON types.

-mike

Domenic Denicola

unread,
Jul 23, 2020, 9:59:05 AM7/23/20
to Mike West, blink-dev, Francois Beaufort
From: Mike West <mk...@chromium.org>

> That said, I do wonder whether both `MediaSettingsRange` and `MediaDeviceInfo` could be `dictionary` objects rather than `interface`s. That would, I think, allow `JSON.stringify()` to operate on those objects without doing any additional work, as all the types seem to be JSON types.

+1. These appear to be simple data holders, and not classes/interfaces with data and behavior and inheritance.

However, the changes needed would be a bit more extensive, as they are used by other parts of the IDL that does not work with dictionaries. In particular, PhotoCapabilities should become a dictionary too (which would also allow use of sequence<> instead of FrozenArray).

And MediaDeviceInfo has a subclass, InputDeviceInfo, which does have a method, getCapabilities(). It's unclear whether that method really needs to be a method, instead of potentially being another dictionary property, but perhaps it's desired to only construct the relevant MediaTrackCapabilities upon request (instead of eagerly, as would be required if getCapabilities() became a `capabilities` attribute).

So, I'd advise making the change for MediaSettingsRange and PhotoCapabilities. MediaDeviceInfo might not be worth the churn.

François Beaufort

unread,
Jul 24, 2020, 3:55:57 AM7/24/20
to Domenic Denicola, Mike West, blink-dev
Thanks for the valuable feedback folks!
I've filed a PR spec at https://github.com/w3c/mediacapture-image/pull/238 to change MediaSettingsRange & PhotoCapabilities interfaces to dictionaries as suggested.
I'll update this thread when it lands.

Francois Beaufort

unread,
Jul 27, 2020, 11:55:07 AM7/27/20
to blink-dev

François Beaufort

unread,
Jul 28, 2020, 1:39:51 AM7/28/20
to Domenic Denicola, Mike West, blink-dev
This intent has been replaced by "Intent to Prototype & Ship: Change MediaSettingsRange & PhotoCapabilities interfaces to dictionaries"
Reply all
Reply to author
Forward
0 new messages