DAS WG Brightness mode follow-up meeting

17 November 2021


Anssi_Kostiainen, Francois_Beaufort, Fuqiao_Xue, Juha_Vainio, Lars_Knudsen, Marcos_Caceres, Raphael_Kubo_da_Costa, Reilly_Grant, Thomas_Steiner, Will_Morgon
Anssi, anssik, marcosc_

Meeting minutes

<willmorgan> Summary here: https://github.com/w3c/screen-wake-lock/issues/129#issuecomment-817151517

Review Will's proposal

[will recapping his proposal https://github.com/w3c/screen-wake-lock/issues/129#issuecomment-817151517 ]

willmorgan: in my key use case, need to increase the brightness for a few seconds only

<tomayac> Is there a recommendation when it comes to en-US vs. en-GB language? Will wrote maximise vs. maximize. Using maximum instead would help us move around this issue.

anssik: is the use cases list in order of importance?

willmorgan: yes, kind of, perhaps netflix use case should be higher on the list

marcosc: netflix did not really propose anything but shared with us what they're doing in native

<tomayac> tomayac: François has reached out to Netflix.

reillyg: use cases are important, but maybe we try too hard to try to identify them
… user surfaced controls for video in the netflix use case seem orthogonal

anssik: should we solve the netflix use case separately and say it is out of scope for the wake lock brightness feature?

reillyg: we can draw parallel to volume control for video that is not a global setting

<marcosc_> mc: confirming that Netflix boost the actual system brightness

larsgk: I'm figuring our why a user wants a web page to boost brightness
… accidentally max brightness in cinema is my concern

willmorgan: for my use case, we're calibrating env brightness from dark and bright extremes, basically gives us a contrast score
… DOM element with a slider (to adjust brightness) is an interesting proposal

larsgk: you cannot trust screens for color correctness

reillyg: the key benefit for in-app brightness control of netflix style app is I don't need to figure out how to adjust the platform control

anssik: bail out should be as easy as exit fullscreen

marcosc_: want to complement reilly re screen brightness control, with netflix use case you're looking at the image when adjusting the setting
… in will's case the same situation does not apply, you want to make the screen bright as possible

marcosc_: with HDR screen, they can go bright, leads us to brightness vs contrast
… my monitor allows to max brightness and contrast, two knobs

marcosc_: there's also CSS prefers-contrast: mode to put the page in high contrast mode

willmorgan: my particular use case does not care about contrast
… barcode scanning probably useful
… in terms of color sensitivity test or mirror apps, not sure they would benefit

<tomayac> Barcode scanning is _the_ no. 1 use case where we have heard developer demand for.

willmorgan: how is that done today on native? is there a way to modify screen contrast on Android or iOS?
… on macOS you can go to accessibility mode

reillyg: that's modifying widgets to make them render differently


tom: that's accessibility setting, for people who need more contrast

larsgk: I implemented emulation of contrast in my past life

tom: #1 we started this was QR code scanning
… QR code is the mainstream use case

marcosc_: agree brightness is a component of this
… I think Mark of Netflix said we can probably do more here

willmorgan: I think, as you say marcos, there are many things monitors and OSes can do
… interesting, potentially you could integrate that into this proposal
… if we do this contrast only, how that affects branding (in logos etc)?
… in GH there was a proposal for fullscreen integration, that is more heavily policed by browsers currently

nested a 3rd party iframe grabbing a wake lock not a good thing

willmorgan: question is, do we put this into wake lock or fullscreen?

<larsgk> adjusting display (all pixels rendering) by applying a curve mapping for RGB might be what is needed in some of the cases mentioned

reillyg: different proposal, if we are willing to limit this to having an element on the page be scannable
… I'd propose this to not be an API but a CSS property that tells div in this layout is a "QR code"

anssik: interesting proposal, enables UA to maxing brightness when QR code scrolls into view and dim screen after

willmorgan: I'd like to see more details to better understand this proposal

willmorgan: how would the develop know if CSS property is in effect or not?
… in my use case need to know that
… we need to be able to do fallback

anssik: rakuco are we touching your issues and opens?

rakuco: we're exploring new things

anssik: I'd advocate for the simplest solution that gets the work done while being extensible

tom: I like the imperativeness of screen wake lock
… on system-level, it'd be good to see if this feature is actively used, user-visible indicator
… I would not tie to fullscreen, not all use cases require fullscreen
… none of the key apps using QR codes do not go fullscreen

reillyg: my feeling is, we could put this in Screen Wake Lock and Fullscreen too, fullscreen has good mitigations for abuse,
… for wake lock we can block iframes from using this feature
… dismissing wake lock is easy by turning the screen off, not as actively annoying as maxing brightness

reillyg: making this require a user gesture is one mitigation
… if the site keeps making the screen bright we could stop that, also add button "make screen bright again"

<reillyg> document.requestMaximumBrightness()

<reillyg> + some kind of "scannable element" CSS property.

marcosc: agree with reilly, but would approach it differently
… low hanging fruit is the video element, strong use case, but does not solve barcode use case
… if we have the slides in video, that may be an easier path to something common, to try out first
… may also address some of Will's use case
… if the color palettes are added through video element

reillyg: I have strong reservations for that from implementation perspective
… there's a lot of ideas in this space, what if we can stick trusted UI inside an element, that's problematic

marcosc: how you do replacement in <video> and <audio> we could do that here too

reillyg: haven't done that

francois: agree with reilly

tom: Multi-Screen Window Placement API has some API surface that could be helpful


<reillyg> Screen.requestMaximumBrightness() (so it would work for window.screen and window.getScreenDetails().)

will: having a brightness slider on video wouldn't be useful for our use case

<larsgk> wake lock + 'scannable' => high contrast, high brightness, static => ugly for (many) malicious purposes

will: the video would need to be fullscreen, otherwise it'd be abused
… in terms of well-rounded feature, going through Wake Lock or Fullscreen with existing mitigations seems simplest way
… with CSS I don't know how permissions work there

reillyg: up to the browser to decide

larsgk: agree with Reilly, if "make scannable" attribute makes it ugly for ads that may use this property for malicious purposes, it might mitigate the concern

rakuco: given all the new ideas in this brainstorming session, anyone willing to try to figure out a proposal with all these ideas, how they address the open issues we have
… external displays? or do we focus on mobile?
… want to see way forward

reillyg: for next steps, we should put together a concrete proposal for a new method on the screen object that request max brightness along with permission and mitigations around it
… and also engage with CSS WG
… having a discussion what how that CSS property could look like

MC: agree

rakuco: if we write an explainer, we'll have a long list of considered alternatives

reillyg: single display use case should be the focus
… can expand to other platforms from there
… focusing on mobile first makes sense
… will any of your use cases happen in desktops?

will: we run on any device, desktop is useful but focusing on mobile first would be a good win

marcosc: we should reach out to people who know these areas

willmorgan: what is the exact proposal?

marcosc: do not do detailed API shape at all, explain the problem with pictures and use cases
… we know what we want, do not know how to achieve that

rakuco: one thing we can do, is to write in GH issue the list of people we need to talk to
… there are two related fullscreen GH issues
… similarly to CSS folks who are expert in this

marcosc: let's point others to rakuco's summary

anssik: propose to consider turning that into explainer doc or similar

reillyg: narrow down on brightness, off scope video use case for now

<willmorgan> Old explainer: https://github.com/WICG/proposals/issues/17

anssik: is this a case of “Perfect is the enemy of good”
… we cannot engineer a perfect solution without trying, testing, feedback from developers
… Origin Trial is a way to do that

rakuco: need to figure out if we tie this to Wake Lock still

reillyg: my proposal was to have this be independent of Wake Lock and Fullscreen

rakuco: in any case makes sense to reach out to CSS and Fullscreen people

anssik: where would your API be concretely documented?

<xfq> https://drafts.csswg.org/cssom-view/#the-screen-interface

reillyg: so add this to CSS OM spec as an extension?

<xfq> https://drafts.csswg.org/cssom-view/#dom-window-screen

reillyg: proposal to put together an explainer with a proposal for this method and send it to CSS WG

reillyg: we should mention in this explainer relationship with Screen Wake Lock and Fullscreen APIs

anssik: I want to make sure the proposal we make is considering marcos' comments, given he had to leave the meeting

RESOLUTION: Create an explainer for Screen.requestMaximumBrightness() as an extension to CSS OM and send it to CSS WG for comment.

anssik: thanks everyone for joining this discussion!

Summary of resolutions

  1. Create an explainer for Screen.requestMaximumBrightness() as an extension to CSS OM and send it to CSS WG for comment.
Minutes manually created (not a transcript), formatted by scribe.perl version 159 (Fri Nov 5 17:37:14 2021 UTC).