w3c
Proposal: Transparent window
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:
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
:rootand/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.
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.
Just here to say that even though this was from a long time ago, I'd be all about it.
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.
@Loirooriol I believe that's a problem for the page's designer to solve and not a strong enough argument against this proposal.
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.
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.
@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.
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).
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.
@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?
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.
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.
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.
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).
@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.
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.
Can I ask is the desire of the proposal really to expose total transparency to the browser or rather to allow elements on the page to adopt appearances that native applications today can?
MacOS apps often adopt a vibrant (blurred + increased saturation) underneath sidebars while content backgrounds stay opaque or simply tinted. These provided materials also obey system settings like allowing window tinting and light/dark modes so querying prefers-reduced-transparency and prefers-color-scheme should probably be part of the conversation too.
With total transparency you're still going to have a drop shadow and/or a border around the window provided by the OS, as well as the browser chrome so I'm not sure exposing it really gets us to the goal of making the page feel more appropriate to the platform and more native. My suggestion, instead, would be to offer some standardized (cause not everyone is on a mac) computed background appearances that any element on the page could adopt (including the root) to get the effect of punching through the window without even needing to set total transparency on the root. Maybe its a scale of varying vibrancies for uses like primary content vs nav or auxiliary content (similar to how we have System Colors provided by the OS now). These predefined appearances could offer a degree of contrast needed for semi-transparency and a11y but still bring in the feel of the environment similar to native apps.
For me, it's about accepting that Browsers don't only run on desktops like OSX, Windows 11, or Linux. They also end up on mobile and new platforms like AR/VR/XR.
The trend is for applications to have a 'glass' and 'frosted' glass-like appearance, and the WEB should fully support native looks so that web tech can be used to deploy desktop apps and so web pages can be fully hosted apps as well.
If I make a WEB XR app, then it should look amazing on a Meta Quest 3 or Apple Vision Pro.
Looking even further into the future, the tech we should look out for are Transparent displays, AR Apps, Widgets, etc...
The browser should support this either as a full browser environment or when the 'browser' is just a micro wrapper to deploy a native app.