-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Devices and Sensors WG - Screen Wake Lock Brightness follow-up #51
Comments
cc'ing event attendees @reillyeon @anssiko @marcoscaceres @beaufortfrancois @tomayac @willmorgan @xfq @larsgk |
This would only be useful for mobile devices and seems very unlikely (or quite surprising) if one could change the brightness on an external display. As mentioned in the other issue, the framing around “brightness” is a misnomer or red herring, because the use case is about achieving optimal contrast. Brightness obviously plays a role in achieving contrast, but it’s one factor. |
Just adding another data-point... I'm unsure if it's a thing on mobile, but displays allow adjusting both brightness and contrast: Was also thinking what might be worth exploring is if requesting high contrast with the screen wake lock should trigger At least... it might be good to also bounce this off @frivoal or other CSS folks. |
We should probably move the summary back to the main issue.... otherwise we will split the discussion. |
@rakuco @marcoscaceres we've used this repo for meeting planning purposes. Your summary and comments would be good material for the explainer we committed to. |
Quite a few ideas were presented towards the end of the meeting so I don't fully remember what ended up being agreed, but if I recall correctly the expanded version of the resolution ("Create an explainer for Screen.requestMaximumBrightness() as an extension to CSS OM and send it to CSS WG for comment") was to:
I've done 1) with the contents of this issue put together with what we discussed during the meeting and shared the document with the attendees. It's available for viewing and suggestions here: https://docs.google.com/document/d/1skbEBafMjKnYVC7UoJfRgnnhAkp-jx0k_Z4j6eZeOwc/edit?usp=sharing One thing that's not clear is where to host the explainer once we move off Google Docs. |
I've left some comments in the doc. Thank you @rakuco for starting this! |
What is the current status @rakuco? |
I think there's been adequate time to review the Google doc (thanks for all the comments folks, and @rakuco for creating the doc!), so we can proceed with integrating comments, then drop the content into the explainer template and continue iterate there. When satisfied, circulate with the other groups per our resolution.
Given the origins of this proposal are with the Screen Wake Lock API being worked on in the DAS WG, the scope of this proposal seems to fit within the scope of the WG, the proposal has been discussed here since 2018(!) and we seem to have interested stakeholders on board, I'd propose to host the explainer in an existing repo until we figure out where the API itself will land. My pragmatic proposal would be https://github.com/w3c/screen-wake-lock/brightness-mode/explainer.md or https://github.com/w3c/screen-wake-lock/brightness-mode-explainer.md but feel free to disagree. My worry is if we push this proposal with its existing history to a new WICG repo now it gets lost in the sea of proposals. |
Related to w3c#129 and w3c/devicesensors-wg#51 for more context. The contents come from https://docs.google.com/document/d/1skbEBafMjKnYVC7UoJfRgnnhAkp-jx0k_Z4j6eZeOwc/edit?usp=sharing which was used while hashing out the basics and the structure. Now that the contents have matured a bit, it is time to move this to an explainer and continue iterating here.
Sorry for the silence, I ended up getting busy with other stuff and didn't get notified about changes the doc so I was pleasantly surprised when I looked at it again and noticed there had been a lot of activity :-) I've incorporated most edits into the doc and converted it to Markdown. w3c/screen-wake-lock#334 adds it to the Screen Wake Lock repository for now. Hopefully people keep working on it and it gets into shape soon so we can move on to the next steps. |
Related to #129 and w3c/devicesensors-wg#51 for more context. The contents come from https://docs.google.com/document/d/1skbEBafMjKnYVC7UoJfRgnnhAkp-jx0k_Z4j6eZeOwc/edit?usp=sharing which was used while hashing out the basics and the structure. Now that the contents have matured a bit, it is time to move this to an explainer and continue iterating here. Huge thanks to everyone who reviewed the pull request and contributed with edits and suggestions: - @anssiko - @beaufortfrancois - @kenchris - @marcoscaceres - @reillyeon - @tomayac - @willmorgan
We have an explainer and also a WIP spec draft and Chromium CL (see https://github.com/beaufortfrancois/screen-brightness) so it is appropriate to close this with thanks to everyone who helped the effort take its first steps. For the time being, we're reusing the screen-wake-lock issue tracker with control-screen-brigthness label for this. |
Main event URL: https://www.w3.org/events/meetings/0f623aa1-2026-4366-846b-c2faedda4180
This is happening tomorrow; I've written down some notes to get us started and I didn't know where to put them, my apologies if this isn't the best place.
Discussing w3c/screen-wake-lock#129 separately, as there was not enough time to address this at TPAC.
Agreement so far
getUserMedia()
integration does not fully address the use cases described so far and is not a very good fit for this feature.<video>
and granular brightness controlThe
<video>
use case initially described here is very different from the other use cases described in the GitHub issue. It might be better handled elsewhere and perhaps as a UA-specific control. We can discuss whether it makes sense to try to support it from a Wake Lock perspective, but I'd be careful not to spend too much time on this exclusively.Opens
requestFullscreen()
?WakeLock.request()
?Other useful information
Implementation support
Contrary to the existing wake lock code that just prevents the screen from being turned off, there is no code for doing this in Chromium. This may take quite some time to write.
OS support
KEEP_SCREEN_ON
which doesn't change the brightness level, but as mentioned earlier in this issue I guess we could useBRIGHTNESS_OVERRIDE_FULL
, but this means using the highest brightness value rather than something that may be high enough (see "how bright is too bright" above). There's also LayoutParams.screenBrightness.SetMonitorBrightness
function that might do it, but I am not sure if it works for non-external displays as well.The text was updated successfully, but these errors were encountered: