BenjaminAster commented 2 years ago

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 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:

a browser window with a completely transparent background

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:

a browser window with a darkened, blurred background

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.

jDavidnet commented 9 months ago

The browser could compute the colors in 'alpha-space' and then let the browser do the final composite with the background. This way, when the browser tries to inspect a pixel color or snap a screen shot, it would compute an alpha channel version of that pixel or image.

If you were, say, using Canvas then any images produced could be a transparent PNG or transparent JPG. Only the browser's final render would have access to the final composite and display output.

You could also have the min-blur be a global browser setting, so pages would never be able to drive a 'desktop-replacement' sort of look.

andreamorales commented 1 month ago

Just here to say that even though this was from a long time ago, I'd be all about it.

Loirooriol commented 1 month ago

It seems pretty bad that the text may be unreadable if the user is using a wallpaper with the same color the author chose for the text.

zaygraveyard commented 1 month ago

@Loirooriol I believe that's a problem for the page's designer to solve and not a strong enough argument against this proposal.

Loirooriol commented 1 month ago

The page designer can't solve it well without having access to the underlying data which obviously can't happen. And designers won't try with all possible wallpaper combinations, so the ones who will suffer will be the users. Have you seen the image at the top? Completely unreadable. So I don't see how this would "allow richer and more modern visual experience for users", IMO it's just worse for the user.

kizu commented 1 month ago

I don't think it is safe to allow the complete page transparency. A malicious actor could use it to fake OS UI and easily overlay them on top of the desktop/other windows.

If something like this was to be implemented, there should be a certain level of opaqueness required that would guarantee that the content is at least partially obscured and/or blurred, with the User Agent deciding how exactly this should look (overlay? blur? something else?).

And, of course, it would need to follow the “reduced transparency” setting.

zaygraveyard commented 3 weeks ago

@Loirooriol

The page designer can't solve it well without having access to the underlying data which obviously can't happen.

I disagree, a simple way to solve the problem would be to ensure all content has a defined background while the page is transparent (which would look like islands or widgets)

And designers won't try with all possible wallpaper combinations

Of course not, nor should they

so the ones who will suffer will be the users

Users are suffering today from the flexibility offered by CSS, but the suffering can be limited by adding restrictions and allowing user overrides (like @kizu suggested in https://github.com/w3c/csswg-drafts/issues/7281#issuecomment-2424083934)

Have you seen the image at the top? Completely unreadable.

What about the one below it?

I'm not advocating for this feature, but I just don't think the wallpaper (or any background) issue is strong argument against this proposal.

andreamorales commented 3 weeks ago

I think what's exciting about this is the ability to take the web even more into OS land, which is what Wasm is slowly taking us to. I think it'd be super cool to be able to develop small programs that could stay in windows that are a sixth or a seventh or even smaller of the total screen, but look like circular interfaces, or interfaces in odd shapes. Not so much rectangles everywhere. It would open up a lot of possibles for us designers (I'm one).

Loirooriol commented 3 weeks ago

What about the one below it?

@zaygraveyard I bet it would be completely unreadable if the user had a white wallpaper.

I just don't think the wallpaper (or any background) issue is strong argument against this proposal.

I do.

I think it'd be super cool to be able to develop small programs that could stay in windows that are a sixth or a seventh or even smaller of the total screen, but look like circular interfaces, or interfaces in odd shapes

@andreamorales I don't think this proposal introduces non-rectangular windows.

It would open up a lot of possibles for us designers

Can you provide examples? Because I'm not seeing the usefulness of this.

andreamorales commented 3 weeks ago

example here you go

zaygraveyard commented 3 weeks ago

@Loirooriol

I bet it would be completely unreadable if the user had a white wallpaper.

Given that the "w3.org" is mostly white and that the two windows overlap, we can look at the overlapping section to observe that the white text is still readable on a white background. But there's no point in trying to reason with you on that subject, is there?

tabatkins commented 3 weeks ago

But there's no point in trying to reason with you on that subject, is there?

Reminder that the W3C Code of Conduct is enforced in this repo.

tabatkins commented 3 weeks ago

More directly, look at both of the images in the OP. The second one is readable, because it uses a partially-transparent black + a blur. The first is completely unreadable, because it has white text overlapping a white or nearly-white page. While authors are of course free to produce unreadable content on their own, we try to avoid giving them abilities that make it easy for things to become unreadable by accident.

But overall, I echo @Loirooriol in requesting examples of actual use-cases. Applications can get value out of transparent backgrounds because they can also suppress all the other window decorations, and designate custom areas to be grabbable/etc; WinAmp is the classic example of putting this ability to good use. But webpages can't do that; even if the page is transparent, the tab/UI bar will be opaque, rectangular, and floating up there at the top. It's much less obvious what useful things one can do under that constraint.

Loirooriol commented 3 weeks ago

Given that the "w3.org" is mostly white and that the two windows overlap

Your response wasn't constructive but I also apologize for not looking at the image in detail. Instead, I read the description, which says

set a transparent background-color and a backdrop-filter: blur()

By itself this will not darken anything, so if an author has white text and they only test with dark background windows/wallpaper, then they may think it will look good but it will be unreadable with light wallpaper.

andreamorales commented 3 weeks ago

I really think there could be a max transparency that would still keep things accessible, and then designers could make sure that only accessible elements are shown (for example, the blue button in my mockup).

zaygraveyard commented 3 weeks ago

@Loirooriol I apologize for my unnecessary and non-constructive remark 🙇‍♂️, it was out of line. Thank you for taking another look, and thank you @tabatkins for the reminder.

I also do agree that examples of actual use-cases are needed.

zaygraveyard commented 3 weeks ago

This feature might be better suited for installed PWAs as they can have more control over the user agent's UI, like when using "display": "standalone" and "display_override": ["window-controls-overlay"]. And as suggested in the OP, this can be implemented as an option in the web app manifest. Although I'm not sure if the CSSWG is the right place for a web app manifest proposal.

w3c / csswg-drafts