A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

[Proposal] Transparent window

BenjaminAster
2022-05-26

I am proposing a way to enable a transparent window background effect for webpages.

More than a week ago, I submitted a proposal to the CSS Working Group (see issue #7281 on the csswg-drafts repo) and got no response, so I want to start a discussion about it here. Depending on how this would get implemented, it might, however, not be the responsibility of the CSSWG at all. The following is the copy-pasted original issue for the CSS Working Group:


Proposal: Transparent window

Another missing key feature of the web platform in comparison to native applications is the ability to create transparent windows. This issue discourse aims to elaborate ideas on possible implementations of transparent windows. The goal is to provide a mechanism on how authors can create a transparent window effect resulting in the following:

Additionally, authors should then be able to, for example, set a transparent background-color and a backdrop-filter: blur() on the :root and/or <body> element to achive an effect like this:

An implementation of this feature would allow for a richer and more modern visual experience for users.

Possible implementation ideas

The following are possible ideas on how authors could be able to enable the transparent window effect:

  • A new property in the viewport <meta> tag, e.g. transparent-window=yes.
  • A new CSS property that is only valid in the :root and/or <body> element, e.g. window-transparency: transparent.
  • A new Web Application Manifest member, e.g. "transparent_window": true, which would only be applied in the context of a standalone installed Progressive Web App.

Privacy implications?

A key concern here should be that there is no way for the website to view stuff underneath the window. However, since there is no way to read pixel data of the client’s viewport in JavaScript, I do not think there are extra privacy implications to consider here.

easrng
2022-06-13

If you know what the user’s wallpaper is you can fake this by checking the window position and size. Try setting your wallpaper to the default windows 7 one and loading https://progress-page.glitch.me/

BenjaminAster
2022-06-13

Alright, but

  • normally, you don’t know the user’s background
  • you don’t see other opened windows behind your current window (see example screenshots)
  • this solution feels slow and unresponsive

I think it’s very clear that this is not a replacement for my original idea.

alinnert
2022-06-15

I had a similar idea recently: What if we were able to use system level materials on individual elements just like native applications do that. E.g.:

.sidebar {
  background-material: blur;
}

I don’t think background-image works because the result of background-material does depend on the window position. Also, background-material could accept a list of values where the first available material gets applied (similar to font-family). I think that’s a good idea since every system has its own set of unique materials. Many do have some kind of blurry transparency, but (I think) only Windows has something like Mica (a blurry version of the desktop wallpaper). In that case we could write background-material: win-mica, blur;. This uses win-mica if available, and blur otherwise.

That is unless we can agree on a standardized set of materials that work across all operating systems. And I think some materials even have additional settings (blur strength, tint color, …). Those should probably also be adjustable.

A fully transparent window could be one of these materials (e.g. background-material: transparent;).

I just don’t know if that’s so easy to implement or if that requires some heavy hacking to get this to work.

Also, I think this should only work in PWAs that run in their own window. In a browser context this can be very confusing and could potentially be used maliciously: Imagine a transparent website on top of another application. The user thinks they interact with the application unerneath but in reality the malicious website gets all the user inputs etc.

tabatkins
2022-06-16

Privacy concerns are indeed moot. (There are timing-channel attacks you can do with compositing if you can force compositing against a particular layer, but we’d obviously treat the browser window itself as isolated, so you can’t do special composites against anything behind it.)

But security concerns are extremely important here - if you can make the window transparent you can trick people into clicking things when they think they’re clicking on their desktop or whatever. This isn’t something arbitrary web content should be able to invoke.

That said, CSS doesn’t care what color the background canvas is; it recommends white/black, but allows the UA to decide. The UA can definitely provide a transparent canvas, just like it does for iframes, so this sort of thing would be possible to invoke via manifest for installed webapps, for example. It’s just not something for CSS itself to control.

BenjaminAster
2022-06-17

To prevent the website from tricking the user into thinking they are interacting with another application, the user agent could maybe provide blurring out-of-the-box. For example, one could specify "transparent_background_blur": <number> in the PWA manifest. The number would be the blur radius in pixels. The user agent could then decide that a minimum blur radius of e.g. 20 pixels is required, so it would take the maximum of 20 and the given number. To make the background darker (like in my second example image), you could then still specify a semitransparent CSS background-color on <body>. This way, the cool-looking effect that I was aiming for would be possible while still providing the right security measures.

I also like the idea of @alinnert, but I don’t think this would be easy to implement for browser vendors. Mixing native materials into the browser-rendered canvas doesn’t seem like a straightforward task.