– DRAFT –
DAS WG Brightness mode follow-up meeting

<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

https://github.com/w3c/screen-wake-lock/issues/129#issuecomment-971235292

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

https://webscreens.github.io/window-placement/

<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!