[css-background-4] Switch to opt into transparent canvas for additive displays

[cabanier]

On passthrough devices such as Magic Leap One or Hololens, the browsing experience in "dark" mode is more pleasant if the browser canvas itself is transparent.

By default, the canvas is white and the [css-color-adjust] spec just inverts that to black.
Can there be a way for an author to specify that the canvas color is transparent? Or can the canvas always be transparent for passthrough devices?

[tabatkins]

Black or white being transparent on passthru screens and the like is already allowed just in general.

[cabanier]

@tabatkins I don't follow. We want authors to opt their pages into being transparent using the meta tag.
Are you saying that this is already possible?

[cabanier]

I think for transparent displays, the root color of the canvas should be transparent and not black but I'd like that to be reflected in the spec.

[tabatkins]

What I mean is, transparent displays already are allowed to handle CSS's black (or white, depending on the nature of the screen) by instead rendering transparently. We even have a proposed MQ in level 5 to expose when this is happening: https://drafts.csswg.org/mediaqueries-5/#environment-blending

So 'color-scheme' doesn't have any effect on this.

[cabanier]

I know of that one (since I proposed it :-)) Since it's a media query, it doesn't change anything; it just allows switching to a different style for transparent devices.

environment-blending doesn't influence the color of the canvas backdrop since it's specified to be white or black for now. I'm happy to change our implementation to so the canvas is transparent for dark mode when the meta tag is present but would like to see that reflected in the spec.

Just to be clear: this is not about how to handle the black color, this is about the default canvas color (= the color on which all the elements are painted)

[tabatkins]

Right; I'm definitely not saying that the MQ changes anything about the page!

What I'm saying is that the existence of the MQ implies that rendering engines can already render black/white as transparent, if that's ideal for their display. There's nothing stopping you from rendering any way you'd like, as long as it makes your users happy.

Just to be clear: this is not about how to handle the black color, this is about the default canvas color

Sure. Similar story tho. Color Adjust does not prescribe any particular colors, it just gives guidelines for what "light" and "dark" should mean. If a transparent canvas is the best way for your display to implement a "dark" mode, then go for it.

[jonjohnjohnson]

Or can the canvas always be transparent for passthrough devices?

@cabanier guessing you might get clarification by adding your questions to the discussion in #3983?

Also,

If the canvas background is not opaque, what shows through is UA-dependent. - https://drafts.csswg.org/css-backgrounds-3/#special-backgrounds

[cabanier]

If the canvas background is not opaque, what shows through is UA-dependent. - https://drafts.csswg.org/css-backgrounds-3/#special-backgrounds

That wording is...odd and not in line with the css color spec.

[tabatkins]

Can you elaborate? What do you think contradicts it in CSS Color?

[cabanier]

css-color specifies that the color of the document canvas is recommended to be white.
css-backgrounds specifies that color of the canvas is inherited from body.

Maybe these are 2 different definitions of 'canvas'?

[fantasai]

@cabanier There does seem to be some confusing wording. CSS Backgrounds (like CSS2 before it) assumes the canvas has a "background", which is taken from the root element and painted over whatever the UA has below that. CSS Color calls that UA default the "color" of the canvas.

It seems we need a clearly defined term for the color of the canvas underneath the background specified by the root element to avoid the confusion between the two concepts. (But in any case, the specs do not conflict.)

[cabanier]

I agree. From CSS Color:

The default background of the root element must be transparent. The default color of the canvas (the surface on which the document is painted) is UA-dependent, but is recommended to be white, especially if the above color rules are used.

We need to define what "the surface on which the document is painted" is called.

[fantasai]

Maybe "canvas surface" as opposed to "canvas background"?

[cabanier]

sound good. Then white is the initial canvas surface color with an option of making it black or transparent.

[fantasai]

s/white/Canvas/ https://drafts.csswg.org/css-color-4/#valdef-system-color-canvas but yes :)

[fantasai]

Filed #4863 and adjusted css-color-adjust-1 and css-backgrounds-3 to consistently refer to the surface of the canvas.

@cabanier Do these edits resolve your concerns?

[cabanier]

Partly :-)
Right now the language allows it to be UA dependent but in reality every UA uses white.
I would prefer if the spec just says it should be white and that the author can put in a hint (ie through a meta tag) to change it.

[faceless2]

This also applies to fxtf filters; it may be worth making the same change there.

[cabanier]

This also applies to fxtf filters; it may be worth making the same change there.

What do you mean by "this"? Filter and blending operations must be independent of the initial canvas surface color

[faceless2]

Sorry, that was half-remembered. I've just checked my notes; specifically it was the backdrop-filter in css-filters-2, which has to build the Backdrop Root Image. Obviously that image will be different depending on whether the background is white or transparent. All the current web-platform-tests for this property presume it's white.

However on re-reading this issue and filter-effects-2, I don't think there's any action to be taken there. It's explicit that the background color of the root is an input into that algorithm. So if the background color of the root is changed as a result of this issue, no changes will be required to filter-effects-2.

To sum up: please ignore my earlier comment.

[cabanier]

Sorry, that was half-remembered. I've just checked my notes; specifically it was the backdrop-filter in css-filters-2, which has to build the Backdrop Root Image. Obviously that image will be different depending on whether the background is white or transparent. All the current web-platform-tests for this property presume it's white.

That would be incorrect. The default stylesheet for the root is transparent.
The white is applied AFTER all compositing, blending and filtering.

You can see it in this codepen: https://jsfiddle.net/2vf1d6jt/
If you hover over the text, the color of the root is set to white and you will see that compositing looks different.

However on re-reading this issue and filter-effects-2, I don't think there's any action to be taken there. It's explicit that the background color of the root is an input into that algorithm. So if the background color of the root is changed as a result of this issue, no changes will be required to filter-effects-2.

Changing the color of the canvas surface will not change document colors. It's a special case that needs to be handled differently.

[fantasai]

@cabanier It isn't always white, though. Sometimes it's transparent. :) Isn't that what you wanted when filing this bug originally, to allow the canvas to be transparent?

[cabanier]

@cabanier It isn't always white, though. Sometimes it's transparent. :)

It's sometimes black, if there's a meta tag for dark mode :-)

Isn't that what you wanted when filing this bug originally, to allow the canvas to be transparent?

yes, I wanted a meta tag to opt into transparent. Since then, a meta tag for dark mode was proposed and @tabatkins said that it could be used to signal transparent on certain UAs. I'm unsure that's the right approach though...

[grorg]

It would be nice if we used a term other than "canvas" in this discussion. "Surface" was suggested above. We're talking about the color (or, in this case, lack of color) used for the surface of the final rendering/compositing destination.

[grorg]

I'd like to know what is expected to happen on a pass-through display for a page that the user requests to be shown in mode other than the default. e.g. a white background is normally not rendered on this device - if the user requests dark mode for a page, should they now see the background?

[css-meeting-bot]

The CSS Working Group just discussed [css-background-4] Switch to opt into transparent canvas for additive displays.

The full IRC log of that discussion

<dael> Topic: [css-background-4] Switch to opt into transparent canvas for additive displays
<dael> github: https://github.com//issues/3949
<dael> Rossen_: Brought up by Rik. I don't believe he's on the call
<dael> Rossen_: Silence suggests no
<dael> Rossen_: Anyone here who wants to take this?
<dael> dino: I asked some questions, but I don't think it needs to be discussed
<dael> myles: I think call doesn't have right people
<dael> Rossen_: Doesn't feel like it
<dael> dino: Unless you just want me to make a decision ^-^
<dael> dino: General use case makes sense. I haven't quite understood behavior and what people would expect with meta tag. I look forward to a bit more explination
<dael> Rossen_: This'll go in minutes, hopefully more will come in github

[cabanier]

It would be nice if we used a term other than "canvas" in this discussion. "Surface" was suggested above. We're talking about the color (or, in this case, lack of color) used for the surface of the final rendering/compositing destination.

That's right. "canvas" is what is used in the spec so if we start talking about surface, people might think they are 2 different things

[cabanier]

I'd like to know what is expected to happen on a pass-through display for a page that the user requests to be shown in mode other than the default. e.g. a white background is normally not rendered on this device - if the user requests dark mode for a page, should they now see the background?

dark mode doesn't make much sense on an additive device. Such a UA should only support light mode.

[grorg]

dark mode doesn't make much sense on an additive device. Such a UA should only support light mode.

That's good. But what about a "fake" additive device. e.g. it's showing a camera feed on the display, and the web content floats above that. Most of the time you'd want a solid background, but I can imagine widgets and other smaller UIs would want to cut through.

This also makes me wonder what happens to partially transparent backgrounds.

[cabanier]

dark mode doesn't make much sense on an additive device. Such a UA should only support light mode.

That's good. But what about a "fake" additive device. e.g. it's showing a camera feed on the display, and the web content floats above that.

That's not an additive device since it can blend the web content with the real world using source-over.
For instance, this means that black text can still be visible.

Most of the time you'd want a solid background, but I can imagine widgets and other smaller UIs would want to cut through.

If you want parts to push through (and leave the initial background opaque), I don't think there's currently a way to do this.

This also makes me wonder what happens to partially transparent backgrounds.

I'm unsure why those are special. Can you list the scenario you're thinking of?

[cabanier]

dark mode doesn't make much sense on an additive device. Such a UA should only support light mode.

That's good. But what about a "fake" additive device. e.g. it's showing a camera feed on the display, and the web content floats above that. Most of the time you'd want a solid background, but I can imagine widgets and other smaller UIs would want to cut through.

To elaborate on my previous reply, a device that combines the background with the web content in hardware, could support dark mode and a transparent surface/canvas but it would depend on the brightness of the environment if light or dark mode would work well.
For instance, at night light mode is preferable but during bright conditions, dark mode would be better.

[FremyCompany]

One idea is an additional transparent keyword to color-scheme which, when present, switches to a style where controls might be semi-transparent and the browser knows that the page renders well on a transparent canvas (same as when you specify dark the browser knows it can draw you on a black background).

[cabanier]

One idea is an additional transparent keyword to color-scheme which, when present, switches to a style where controls might be semi-transparent and the browser knows that the page renders well on a transparent canvas (same as when you specify dark the browser knows it can draw you on a black background).

Yes, if a page is transparent, it makes sense to have an additional color scheme for it.

[astearns]

@cabanier this one keeps going on the agenda then getting passed over because you aren’t on the call. Could we either get things to a point where we could resolve something on this issue in your absence, or have you commit to a particular meeting? Both at once would be best :)

[cabanier]

@cabanier this one keeps going on the agenda then getting passed over because you aren’t on the call. Could we either get things to a point where we could resolve something on this issue in your absence, or have you commit to a particular meeting? Both at once would be best :)

Because I switched companies, I'm no longer a member of the CSSWG. Is this important enough for me to join?