An element attribute proposal for increasing screen brightness

[beaufortfrancois]

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?

[tomayac]

Thanks, @beaufortfrancois, this reflects the consensus of the meeting well I think. Some remarks:

• On top of auto-boosting when the element becomes visible, we talked about UAs making an affordance like a button available that would trigger the actual brightness boost. This could be offered as an alternative UA behavior.
• The two first restrictions ("The website is in a secure browsing context." and "The element is NOT in a cross-origin iframe.") might not actually be necessary.
• The 1/4 of the screen size requirement could probably be formulated with more leeway for UAs to do what they think is best.

One additional idea might be to say that (i), dynamically inserted attributes in the user gesture that triggered a fullscreen request or (ii), statically already existing attributes in the fullscreen'ed element could be always honored, for example, for proprietary codes (example).

[reillyeon]

Thanks @beaufortfrancois for writing this up. Echoing what @tomayac said, I think we can weaken some of the normative requirements in favor of allowing UAs to decide how proactively they will brighten an area of the screen or provide UI suggesting that the screen could be brightened. Something like, "based on the following signals a UA may choose to proactively brighten an area of the screen or the whole screen, may provide an affordance for the user to brighten the screen, or ignore the attribute."

[beaufortfrancois]

Thank you @reillyeon and @tomayac for your feedback. I've updated #348 (comment). Let me know what you think.

You can see the diff by clicking "edited ▾" at the top of the post.

[willmorgan]

Thanks for organising this, @beaufortfrancois.

I have a few questions:

1. Should this affect only certain elements like img, canvas, video etc?
2. How should layering elements and z-index work? For example, a canvas element with a translucent div overlay.

For (2), here are a couple of scenarios I can think of:

Wrapper has increaseBrightness:

<div style="position: relative;" increaseBrightness>
    <canvas style="width: 640px; height: 480px; z-index: 1" />
    <div style="z-index: 2; position: absolute; top: 0; left: 0; width: 100%; height: 100%">
</div>

Lower layer has increaseBrightness:

<div style="position: relative;">
    <canvas increaseBrightness style="width: 640px; height: 480px; z-index: 1" />
    <div style="z-index: 2; position: absolute; top: 0; left: 0; width: 100%; height: 100%">
</div>

[beaufortfrancois]

Thanks for your feedback @willmorgan!

1. Should this affect only certain elements like img, canvas, video etc?

I can't think of a reason to allow it only on certain elements. In your example below, a <div> has the increaseBrightness attribute and it works fine. As long as the element has a "certain" visible size, it should be okay. Did you have some elements in mind you didn't want?

2. How should layering elements and z-index work? For example, a canvas element with a translucent div overlay.

I was thinking of using the bounding client rectangle of the element. It means we don't deal with layers at all.

[willmorgan]

As long as the element has a "certain" visible size, it should be okay. Did you have some elements in mind you didn't want?

I can't think of any element to explicitly disallow, but wondering how things like <br increaseBrightness /> might work.

Bounding client rectangle sounds good!

It would be useful to know if the brightness increased to provide alternative guidance if it isn't possible or supported.

[beaufortfrancois]

Following https://developer.chrome.com/docs/web-platform/region-capture/#deriving-a-croptarget, <br> has a "small" bounding client rectangle which should allow UAs to decide whether this is okay.

It would be useful to know if the brightness increased to provide alternative guidance if it isn't possible or supported.

Can you elaborate?

[willmorgan]

Sure, so if we know that screen brightness increased automatically, then we know that it is not necessary to provide extra guidance on how to increase brightness if an attempt fails.

On the other hand, if we know the element didn't have increased brightness, and the attempt fails for the user, we could offer some instruction on how to do this.

I can imagine us looking at the type of device (mobile or desktop) and the screen information object to know whether it makes sense to provide the guidance or not, and if so, in what format.

For example it would be unlikely to ask to increase brightness for external monitors because of the illumination area (and it would be too much to ask the user, IMHO), but we definitely would on mobiles.

[beaufortfrancois]

Sure, so if we know that screen brightness increased automatically, then we know that it is not necessary to provide extra guidance on how to increase brightness if an attempt fails.

On the other hand, if we know the element didn't have increased brightness, and the attempt fails for the user, we could offer some instruction on how to do this.

That's an issue with the current proposal indeed.

I'm not sure how to address this properly. Firing a single generic JS event (e.g. window.onbrightnessincreased) or a CSS media query (.e.g @media increased-brightness) would not help that much. Web developers don't know currently when the "increase brightness" request is fired. Using timers and/or IntersectionObserver is not great either as it depends on browsers behavior.

Thinking out loud, shall we have several JS events?

• window.screen.onbrightnessincrease when the request to increase screen brightness is about to start
• window.screen.onbrightnessincreasedone when the screen brightness has been increased by the element attribute
• window.screen.onbrightnessincreaseerror when the browser doesn't allow the element to increase screen brightness.

[reillyeon]

The idea here is that users can already increase their screen brightness manually. The purpose of this attribute is to provide a hint to the browser that the user is in a situation where it can provide a simpler UI for doing so. Sites shouldn't be depending on the browser providing that UI and should show platform-specific guidance for increasing brightness regardless. When the browser decides to provide the hint the user can ignore that guidance and follow the simpler path provided.

[willmorgan]

The idea here is that users can already increase their screen brightness manually. The purpose of this attribute is to provide a hint to the browser that the user is in a situation where it can provide a simpler UI for doing so.

My understanding is that there's no "simpler UI" - the browser calls the OS to increase the screen brightness if it satisfies the various conditions we're putting on this.

Sites shouldn't be depending on the browser providing that UI and should show platform-specific guidance for increasing brightness regardless. When the browser decides to provide the hint the user can ignore that guidance and follow the simpler path provided.

It would be useful to progressively enhance the experience by knowing if the brightness was increased, be that by the user or automatically by the browser following the site's request. This would de-clutter the UX.

Part of the motivation in requesting this functionality is that it's already quite difficult to come up with platform-specific guidance for every possible combination of:

• device
• operating system
• OS skin
• browser
• screen

Therefore having that capability would be a huge benefit to users and developers alike.

[marcoscaceres]

Could we move everything "brightness" to the WICG? We could incubate (and I can participate) there.

[beaufortfrancois]

Could we move everything "brightness" to the WICG? We could incubate (and I can participate) there.

@marcoscaceres I've started WICG/proposals#72

[beaufortfrancois]

As it's not possible to transfer issues between W3C GitHub org and WICG GitHub org, I've opened WICG/screen-brightness#1 to continue this discussion.