2nd Request for Mozilla Position on an Emerging Web Specification
Recent positive developments in PEPC warrant reconsideration. I’m opening a new issue rather than reopening #908 to start discussion afresh (for brevity please see previous issue for poster, apologies).
There’s an updated explainer, and we had a good meeting with the PEPC team.
Overall we like the new explainer’s focus on camera/microphone/geo-location use initiated by native elements. The geolocation PEPC successfully replaces a previous element serving as point of use:
To us, a successful embed is when websites use the PEPC unconditionally—not just when they need permission—removing the need for websites to query permission state, a major simplification. And users can untrap themselves from previous negative responses by clicking the button again. A win-win.
But we think clicking it again should do something useful, like update the location, not revoke permission (which isn’t a primary use case). We want websites to use PEPC in primary locations, so it should be tailored to that.
Camera and microphone
We also like the new explainer’s addition of camera and mic constraints to the element. This appears to similarly refocus on point of use. But it reveals these element to be quite different from geolocation (see bikeshed below).
Our main meeting feedback was that for PEPC to deliver on its promise of simplification, it needs to solve Ask at Time of Usage for camera/microphone as well—with permission regret solved, few reasons remain for websites to ask ahead of usage.
Like with geolocation, we think successful embedding requires replacing existing points of use buttons—video conferencing real estate is precious— making them do something useful, like toggle camera and microphone on/off, not revoke permission, helps:
Once accomplished, this would appear to remove a whole layer of user indirection:
Above we see the same triad of buttons repeated (is Meet anticipating this development perchance?)
In this shape, we hope websites will use the PEPCs unconditionally—not just when they need permission—removing a complicated layer of browser-specific permission querying from the minds of web developers (a boon for interop).
Bikeshed
To “not repeat the <input> mistake”, Martin in our meeting suggested discrete <camera>, <microphone> and <geolocation> elements. E.g.
<camera id="camera"></camera>
<microphone id="microphone"></microphone>
<script>
document.getElementById("camera").setConstraints({
width: { min: 640, ideal: 1920, max: 1920 },
height: { min: 400, ideal: 1080 },
aspectRatio: 1.777777778,
frameRate: { max: 30 }
});
document.getElementById("microphone").setConstraints({
sampleSize: 16,
channelCount: 2
});
</script>
2nd Request for Mozilla Position on an Emerging Web Specification
Recent positive developments in PEPC warrant reconsideration. I’m opening a new issue rather than reopening #908 to start discussion afresh (for brevity please see previous issue for poster, apologies).
There’s an updated explainer, and we had a good meeting with the PEPC team.
Overall we like the new explainer’s focus on camera/microphone/geo-location use initiated by native elements. The geolocation PEPC successfully replaces a previous element serving as point of use:
To us, a successful embed is when websites use the PEPC unconditionally—not just when they need permission—removing the need for websites to query permission state, a major simplification. And users can untrap themselves from previous negative responses by clicking the button again. A win-win.
But we think clicking it again should do something useful, like update the location, not revoke permission (which isn’t a primary use case). We want websites to use PEPC in primary locations, so it should be tailored to that.
Camera and microphone
We also like the new explainer’s addition of camera and mic constraints to the element. This appears to similarly refocus on point of use. But it reveals these element to be quite different from geolocation (see bikeshed below).
Our main meeting feedback was that for PEPC to deliver on its promise of simplification, it needs to solve Ask at Time of Usage for camera/microphone as well—with permission regret solved, few reasons remain for websites to ask ahead of usage.
Like with geolocation, we think successful embedding requires replacing existing points of use buttons—video conferencing real estate is precious— making them do something useful, like toggle camera and microphone on/off, not revoke permission, helps:
Once accomplished, this would appear to remove a whole layer of user indirection:
Above we see the same triad of buttons repeated (is Meet anticipating this development perchance?)
In this shape, we hope websites will use the PEPCs unconditionally—not just when they need permission—removing a complicated layer of browser-specific permission querying from the minds of web developers (a boon for interop).
Bikeshed
To “not repeat the
<input>mistake”, Martin in our meeting suggested discrete<camera>,<microphone>and<geolocation>elements. E.g.