An element attribute proposal for increasing screen brightness

[beaufortfrancois]

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:

• The website is in a secure browsing context.
• The element is displayed fullscreen.
• The element is visible.
• The element is "scannable" (e.g. QR code, barcode).

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

• The element is not visible anymore.
• The element is not "scannable" anymore (e.g. QR code, barcode).
• The website abuses of the increaseBrightness attribute and fires too many requests.

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:

• Unlike other proposals, the screen brightness can be increased without a user gesture. Shall we require one?
• What happens when there are multiple elements with the increaseBrightness attribute? Shall we boost both partial screen regions or one only?

[ljharb]

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]

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]

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

[marcoscaceres]

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]

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]

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]

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]

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

[beaufortfrancois]

@marcoscaceres gentle ping

[beaufortfrancois]

#2 has been merged. Thank you @marcoscaceres

[beaufortfrancois]

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

[beaufortfrancois]

@marcoscaceres (gentle ping)

[dearsina]

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]

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]

I could think of some other use cases:

• acne detection apps (or facial feature recognition in general) that might require front camera access and increased brightness is a plus
• improved game dev if screen brightness can be controlled on a numeric scale

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

[maruel]

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]

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]

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]

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!