- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Nov 2020 17:33:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-color-5] Add `currentBackgroundColor` Variable``. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-color-5] Add `currentBackgroundColor` Variable<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5292<br> <dael> una: The idea behind currentBG came from work in color 5 with color mix. Use case I see commonly is unity within and element where you want a border or a shadow to be related to the primary color of an element which is usually the bg<br> <dael> una: Right now need a separate variable. currentBG would be useful here to use the BG color.<br> <dael> una: A bit of discussion on issue. Way I see it is b/c transparent is default value you look for closest parent with a color and use that<br> <Rossen_> q?<br> <leaverou> q+<br> <dael> una: leaverou had a great comment about a current function to take any inherited keyword. That would work for things like font weight for text decor.<br> <dael> una: Would love questions, comments, thoughts<br> <Rossen_> ack leaverou<br> <dael> leaverou: The clarify my prop is not for current function to take any property as an arg. I said this is useful but since in future we want similar perhaps syntax should allow for us to add more keywords in future<br> <dael> leaverou: I suggested starting with color and bg color. It's no more complext hen keywords but it's more extensible for the future. If it's a funtion that's like any property or longhand that's harder to impl. I wouldn't want to stall this very useful feature by making it complex<br> <Rossen_> q?<br> <TabAtkins> q+<br> <dael> una: Agree. Starting with subset of arg for current is a great route<br> <emilio> q+<br> <Rossen_> ack TabAtkins<br> <dael> TabAtkins: I have a slight objection to trying to generalize to a current function b/c behaviors won't be same. Discussion in thread about if currentBGColor would comput to self or would compute at computed value time and inherit as that color.<br> <dael> TabAtkins: Suspect for BG color b/c transparent we wouldn't want hte behavior of currentColor. Tying together in one syntax implies similar behavior. Since our two examples are divergent I'm not convinced we'd have coherence in our 3rd or 4th<br> <dael> leaverou: Keyword that looks like currentColor also suggests might be same?<br> <dael> TabAtkins: Yes, but we can't avoid that much similarity. A brand new current has a more implicit guar of similar I think<br> <Rossen_> q?<br> <dael> emilio: I want to say xidorn concerns about impl complexity vs benefit. hesitant about mode dependencies b/c get complex. Not sure the use case warrants another one<br> <Rossen_> ack emilio<br> <Rossen_> q?<br> <dael> una: I think it's a common pattern to have a base color for a component, cards, sidebar, whatever where you have a color theme and additional color values for items in that component based on the theme. I've mostly seen that primry color be the background. That's the inspiration on existing common UI patterns<br> <dael> Rossen_: Going back to meta point of do we want to pursue...handling semantics later...is this something we want to pursue as part of color 5?<br> <dael> Rossen_: Use cases and usefulness. Do we have enough merit we can say it sounds like good to put in?<br> <emilio> q+<br> <emilio> dbaron: huh, wfm on nightly<br> <chris> q+<br> <leaverou> +1 would want to pursue<br> <brandon> +1 this would be very useful<br> <dael> fantasai: Question is if the use case is strong enough it outweighs dealing with impl complexity. You have to look through transparent things. If you have image BG the base color is not nec the color b/c might have semi-transparent on top so it might not rep the color you want. Also issues with how and when this computes<br> <emilio> q- was going to mention mostly what fantasai is saying<br> <emilio> q-<br> <leaverou> q+<br> <dael> fantasai: otoh we have the use case. I believe una it exists. You can work around with a variable but it's more work for author to establish a convention and stick to it. I haven't read deeply into impl complexity. I think that's what it boils down to. Does it balance out.<br> <dael> chris: My point was about you can...first if you look at examples in color 5 for contrast they implicitly use bg as the first color for contrast. Simplifies things. otoh you've got partial transparency and you could have an image color bg color isn't used.<br> <Rossen_> ack chris<br> <dael> chris: At the moment we're sticking a color in there and it's author convention that it's the bg. An improvement is good even if not bullet proof<br> <Rossen_> ack leaverou<br> <dael> leaverou: I wanted to say fantasai raises valid concerns. Would it be possible to have a syntax for compositied bg color. Start from current and go up until you meet opaque and composit. Use cases from una in need of that, as is the contrast case<br> <dael> fantasai: What about an image? Have to narrow to a point<br> <smfr> q+<br> <gregwhitworth> do we mean true composition because that comes far after style<br> <gregwhitworth> so that would need a round trip to compute<br> <dael> leaverou: Images makes it more complex and we don't want to deal. But there's an algo for a single color which you can plug into color functions.<br> <una> q+<br> <chris> maybe we need a NaC (Not a Color) value<br> <gregwhitworth> +1 to smfr<br> <dael> smfr: Running algo leaverou desc is expensive. You'd have to re-eval every frame with animations. I don't think practical.<br> <dael> Rossen_: Given convo this generated and the thread on GH we can go back to GH and continue there and don't resolve pursue or not now. I see decent support in IRC and decent amount of concern.<br> <gregwhitworth> we investigated this for a dynamic accessible focus rect and decided to not pursue it although I think that still has a higher likely hood of implementation given it only applies to focusable elements<br> <Rossen_> ack smfr<br> <dael> Rossen_: I rec we continue on GH and bring back in a week or two<br> <Rossen_> ack una<br> <dael> una: sgtm. Answering about compositing I do think it'll be heavy to calc that b/c happens after paint. We could still do it with alpha included and we don't use that value and apply style declarations using that. Lots of places where want alpha and it multiplies on bg color alpha. I don't htink it's as complex as figuring out composited color. That would be great, but I understand complexity<br> <dael> Rossen_: Thanks<br> <dael> Rossen_: Sounds like we should go back to GH. Okay?<br> <dael> una: Yep<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5292#issuecomment-725558168 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 November 2020 17:33:16 UTC