Re: [csswg-drafts] [css-color] "transparent" keyword being a special color value, which resolves to rgba(0, 0, 0, 0) by default?

The Working Group just discussed `"transparent" keyword being a special color value, which resolves to rgba(0,0,0,0) by default?`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> topic: "transparent" keyword being a special color value, which resolves to rgba(0,0,0,0) by default?<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/2722<br>
&lt;dael> chris: One point TabAtkins  was [missed]<br>
&lt;TabAtkins> Calling in<br>
&lt;dael> chris: It's if what TabAtkins did was right [missed]<br>
&lt;dbaron> lea: ... wifi accidentally ... we'll drop off for ...<br>
&lt;dael> TabAtkins: You remember back when we did gradients and there was an issue with transparent and I made it so gradients do a transtion through pre-multiplied space. THat has weird implications. All impl do non-pre-multiplied<br>
&lt;dael> TabAtkins: To fake pre-multiplied you have to put in a number of additional stops to do it they way transparent intends.<br>
&lt;dael> TabAtkins: I've come to regret this because transparent wants to be special in more places. When I wrote edits for cross-fade from last F2F I realized that crossfading with transparent would darken the image half way through. Same exact case. WHen you fade to transparent you expect ti to become more transparent not change color<br>
&lt;dael> TabAtkins: Don't want a special case where if you leave it blank you get a differnet behavior<br>
&lt;dbaron> q+<br>
&lt;dael> TabAtkins: Solution is slightly change original resolution. Transparent retains itself as a spcieal keyword through computed value. Some cases use it as meaning something special some can be to a more transparent version but otherwise it can act the same where it's rgba(0,0,0,0). Any opinions or in particular compat concerns?<br>
&lt;dael> dbaron: More concerned about if it's giving right behavior. IN particular sounds like you define cross fade so not in pre-multiplied.<br>
&lt;bradk> New keyword: “transparent-2”<br>
&lt;dael> TabAtkins: Most likely, yes. I suspect most libraries we're using aren't so we want to match<br>
&lt;AmeliaBR> Concern: How does this affect partially transparent colors? Can you divide an animation from red to transparent into a midpoint of #f008 and still get the same results?<br>
&lt;dael> dbaron: Not so sure on that. And if you're crossfading 2 images and one has area that's almost but not quite transparent you get bad results. Suppose you're looking at one region of the image and it happens to be mostly a solid. And in another image light and opaque and you could get darkening and then lightening. seems not good.<br>
&lt;dael> dbaron: Also I think a lot of compositing is done with pre-multiplied.<br>
&lt;dael> TabAtkins: Fine with defining in pre-multiplied<br>
&lt;dael> dbaron: Worth researching<br>
&lt;dael> chrishtr: Crossfade paints the bottom image with source overoperator<br>
&lt;dael> TabAtkins: It's not. It's not a source over it dissoves and plus operation<br>
&lt;dael> s/chrishtr/??<br>
&lt;dael> TabAtkins: You're not drawing one and then fading a separate image over it. If that's true the first image always shows if there's any transparent areas in the second and that's not right<br>
&lt;dbaron> ok, yeah, that makes it sound like premultiplied doesn't even matter<br>
&lt;dbaron> s/??/smfr/<br>
&lt;dael> Rossen_: We're running out of time. I don't want to go to overtime so I encourage people to go back to github<br>
&lt;dael> TabAtkins: I'll talk with graphics people and find out how our image fading works in the platform<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2722#issuecomment-411479113 using your GitHub account

Received on Wednesday, 8 August 2018 17:02:28 UTC