search

WICG / screen-brightness

Other
6 stars 3 forks source link

An element attribute proposal for increasing screen brightness #1

Open beaufortfrancois opened 2 years ago

beaufortfrancois commented 2 years ago

Moved from https://github.com/w3c/screen-wake-lock/issues/348

Following TPAC Devices and Sensors WG discussion, this issue explores a declarative approach for allowing web developers to ask the browser to increase the screen brightness.

An element attribute proposal was suggested. Let's call it increaseBrightness for now. Naming is hard. 🚲

Last updated: 2022/09/21

Proposal

[Exposed=Window]
partial interface Element {
  [Reflect] attribute boolean increaseBrightness;
}

Example

<div id="my-qr-code" increasebrightness>
    <img src="qrcode.png" width="256" height="256">
</div>

Feature support

You can check for this element attribute support with:

const supported = Element.prototype.hasOwnProperty("increaseBrightness");

Behaviour

When an element with the increaseBrightness attribute becomes visible to the user, the browser would take care of boosting the screen region that matches the element bounds OR increasing the overall screen brightness level if the device does not support partial screen brightness boosting.

Only elements with the increaseBrightness attribute would trigger this behaviour. This way, web pages such the Wikipedia QR code article, would not suffer from automatic detection.

Security and privacy considerations

Based on the following signals, the browser MAY choose to proactively brighten an area of the screen or the whole screen, provide an affordance for the user to brighten the screen, or ignore the increaseBrightness attribute:

Based on the following signals, the browser MAY choose to restore screen brightness automatically:

To avoid possible user fingerprinting issues, a website is not able to detect when screen brightness is increased.

Open design issues

The following issues (on top of the existing ones) remain open for discussion:

ljharb commented 2 years ago

I’ve never known the screen brightness on my iOS or Mac devices to change due to an application’s intervention. Is that a capability that even exists on Mac, Windows, iOS, Android, etc?

tomayac commented 2 years ago

It is a common feature of, for example, travel apps, where the app brightens the screen up for reading the ticket barcode. Here’s a concrete app that shows this for iOS: https://apps.apple.com/de/app/db-navigator/id343555245?l=en.

ljharb commented 2 years ago

Thanks for clarifying! I didn't realize that was a capability on iOS.

marcoscaceres commented 2 years ago

I wonder if we should restrict the attribute to particular elements? E.g., visual ones like HTMLImageElement and HTMLCanvasElement.

Also, the attribute name seems a bit long... maybe just bright?

marcoscaceres commented 2 years ago

With the requirement of it being full screen, it should also cater for installed web applications being in "display mode" set to fullscreen (i.e., you don't need the element to be fullscreen).

With regular web apps with display mode that is not fullscreen: we should make it clear that exiting fullscreen disables the capability.

beaufortfrancois commented 2 years ago

Thanks for the feedback @marcoscaceres!

I wonder if we should restrict the attribute to particular elements? E.g., visual ones like HTMLImageElement and HTMLCanvasElement.

The user agent may decide already to reject the request to increase brightness if the element is not visible to the user. Restricting it to particular elements does not necessarily mean it is visible to the user (e.g. it could be not added to the visible DOM or outside of the viewport).

Also, the attribute name seems a bit long... maybe just bright?

I don't feel strongly about the attribute name. Let's propose the bright name among others and ask developers to vote. WDYT?

With the requirement of it being full screen, it should also cater for installed web applications being in "display mode" set to fullscreen (i.e., you don't need the element to be fullscreen).

With regular web apps with display mode that is not fullscreen: we should make it clear that exiting fullscreen disables the capability.

Good catch! How would you update the explainer to accommodate this?

marcoscaceres commented 2 years ago

Good catch! How would you update the explainer to accommodate this?

Let's move the proposal to markdown file. I can send a PR.

beaufortfrancois commented 2 years ago

As suggested, I've moved the current proposal to https://github.com/WICG/screen-brightness/blob/main/explainer.md.

beaufortfrancois commented 2 years ago

@marcoscaceres gentle ping

beaufortfrancois commented 2 years ago

https://github.com/WICG/screen-brightness/pull/2 has been merged. Thank you @marcoscaceres

beaufortfrancois commented 1 year ago

@marcoscaceres Shall we continue discussing the element attribute proposal for increasing screen brightness? Please let me know what is blocking you for https://github.com/WebKit/standards-positions/issues/19 and we'll work on this.

beaufortfrancois commented 1 year ago

@marcoscaceres (gentle ping)

dearsina commented 1 year ago

Any update on this issue? Surely for those security conscious, screen brightness could be treated like geolocation is treated, with a user prompt if adjustments are required? This seems like a problem we have a solution for already.

therealshark commented 4 months ago

I wonder if we should restrict the attribute to particular elements? E.g., visual ones like HTMLImageElement and HTMLCanvasElement.

Also, the attribute name seems a bit long... maybe just bright?

There are libraries (and uses cases) where QR-codes are generated with basic HTML elements, e.g. tables or divs using display: grid. This can be useful if the backend needs to generate the QR code on a html/templating level. Scoping this attribute to img or canvas would block that use-case.

frunkad commented 2 months ago

I could think of some other use cases:

Generally I'd want a navigator. API, trigger-able upon user gesture

maruel commented 1 month ago

Thanks a ton @beaufortfrancois for all the legwork you've done in the past two years to unblock this feature. It's heartbreaking to see how much struggle it is to add this feature because of a single vendor.

beaufortfrancois commented 1 month ago

Thank you @maruel for the kind words. Funnily enough, I was reading/watching your post this morning ;)

FWIW, with HDR support in WebGPU, I've managed to fake screen brightness increase with https://bright-qrcode.glitch.me/ It's just a demo to see how we can use HDR with WebGPU to emulate it and it is sadly not as straightforward as an element attribute but it still works on my Android phone and my macOS machine with HDR display. Let me know if that works for you too!

VastBlast commented 1 month ago

Thank you @maruel for the kind words. Funnily enough, I was reading/watching your post this morning ;)

FWIW, with HDR support in WebGPU, I've managed to fake screen brightness increase with https://bright-qrcode.glitch.me/ It's just a demo to see how we can use HDR with WebGPU to emulate it and it is sadly not as straightforward as an element attribute but it still works on my Android phone and my macOS machine with HDR display. Let me know if that works for you too!

Was thinking of this and was going to implement it to test, nice to see someone else built it. Unfortunately it doesn’t work for me on iOS 17.6.1 (iPhone 15 Pro).

beaufortfrancois commented 2 weeks ago

For info, by enabling "WebGPU support for HDR" in latest Safari Tech Preview, the https://bright-qrcode.glitch.me/ demo works great as well!

Thank you @mwyrzykowski!

image