WICG / screen-brightness

Other
6 stars 3 forks source link

An element attribute proposal for increasing screen brightness #1

Open beaufortfrancois opened 1 year ago

beaufortfrancois commented 1 year 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 1 year 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 1 year 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 1 year ago

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

marcoscaceres commented 1 year 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 1 year 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 1 year 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 1 year 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 1 year ago

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

beaufortfrancois commented 1 year ago

@marcoscaceres gentle ping

beaufortfrancois commented 1 year 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 2 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 4 weeks ago

I could think of some other use cases:

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

maruel commented 6 days 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 6 days 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!