15:51:35 <RRSAgent> RRSAgent has joined #css
15:51:35 <RRSAgent> logging to https://www.w3.org/2019/10/30-css-irc
15:51:37 <trackbot> RRSAgent, make logs public
15:51:37 <Zakim> Zakim has joined #css
15:51:39 <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:51:39 <trackbot> Date: 30 October 2019
15:53:20 <bgirard> bgirard has joined #css
15:56:52 <dael> dael has joined #css
15:58:30 <Rossen_> present+
15:59:07 <rachelandrew> present+
15:59:34 <dael> present+ dael
15:59:38 <dael> ScribeNick: Dael
16:00:00 <AmeliaBR> AmeliaBR has joined #css
16:00:17 <rego> present+
16:00:22 <dael> Rossen_: We're at 9amPT. We'll delay a couple minutes to give a chance for more folks to join
16:00:37 <bdc> bdc has joined #css
16:01:11 <plinss> present+
16:01:15 <smfr_> smfr_ has joined #css
16:01:24 <dael> Rossen_: One more minute until we go
16:01:30 <antonp> Present+ antonp
16:01:46 <chris> chris has joined #css
16:01:53 <chris> present+
16:01:57 <AmeliaBR> present+
16:02:10 <dael> Rossen_: I think we're ready to start
16:02:10 <leaverou> present+
16:02:11 <chrishtr> present+
16:02:12 <dholbert> dholbert has joined #css
16:02:20 <astearns> present+
16:02:33 <cbiesinger> present+
16:02:34 <dael> Rossen_: As usual let's go ahead and start with a call for any additional items or changes.
16:02:48 <dael> smfr: The first item has been closed so we can skip
16:02:54 <teleject> teleject has joined #css
16:03:03 <dael> Rossen_: Curious why TabAtkins added
16:03:04 <dlibby-> dlibby- has joined #css
16:03:04 <smfr> smfr has left #css
16:03:17 <dael> chrishtr: He added it a couple days ago and now there's consensus.
16:03:24 <dbaron> Present+
16:03:26 <dael> s/ chrishtr / chris
16:03:30 <teleject> present+
16:03:40 <smfr> present+
16:03:49 <dael> Topic: Prevent fingerprinting with deprecated system colors
16:03:52 <dael> github: https://github.com/w3c/csswg-drafts/issues/3873
16:04:05 <bdc> present+
16:04:29 <dael> AmeliaBR: Already in fonts 4 there's a vague warning about how system colors have some fingerprinting potential b/c they review user settings
16:04:33 <dauwhe> present+
16:04:38 <dbaron> I'm getting basically unusable audio via WebEx
16:05:09 <dael> AmeliaBR: I think browsers haven't followed up with changes. I suggest now that we have a decision on which system colors are useful for a11y and which are legacy we go one step further and say UI should not expose any fingerprintable data in the deprecated ones
16:05:23 <dlibby-> present+
16:05:27 <dael> AmeliaBR: Esp true b/c some deprecated ones are so vague that hte data from browsers can't be used in a useful way.
16:06:01 <dael> AmeliaBR: CHange from vague wording to normative requirement. These colors would still have to result in a reasonable value, but that should be determined by nothing more than the combo of UA and OS. It shouldn't have any individualized colors.
16:06:15 <dael> fantasai: Not quite
16:06:28 <dael> fantasai: Also consideration in cases where can map toa  user color they should do that
16:06:37 <dael> fantasai: If you map all background to canvas that seems reasonable
16:06:39 <dael> AmeliaBR: Okay.
16:07:13 <dael> AmeliaBR: You suggest that the deprecated ones could be consistently mapped to one of the theme colors we are undeprecating. As long as UA is consistent not addtional fp
16:07:42 <dael> dbaron: One notes is there was comment about how not defined well. We do know how to define them well. I tried to propose the defintions ~17 years ago. WG wasn't interested in better definitions
16:07:52 <dael> TabAtkins: WE accepted the definitions at least 6 years ago. They're in spec
16:07:59 <dael> dbaron: I think some, not sure if all
16:08:21 <dael> TabAtkins: All ones in email we found when we transferred to github are in the spec. If you've got more, great, we're glad to take them
16:08:40 <dael> AmeliaBR: Might not be definitions, but that no one updated implementations. There are one sentence definitions, not sure when added
16:08:58 <dael> AmeliaBR: Background is one I brought up with different results between browsers about which OS theme was exposed
16:09:07 <dael> TabAtkins: Chrome is nonsensical on background.
16:09:50 <dael> TabAtkins: I'm hapy with this sort of change. We mandate deprecated system colors most not be more user specific then good colors. THey must map to good colors or is not user specific. I'd be happy to do that and spec in more detail how they work and what should look like.
16:10:10 <dael> TabAtkins: Given current lack of interop it's not like anyone is depending on them so might as well give reasonable definition for browsers.
16:10:14 <dael> TabAtkins: Sounds good to me all around
16:10:30 <dael> chris: Sounds good if browsers will do it
16:11:04 <dael> TabAtkins: No one uses the colors because no one can use them so they're not high to work on. But they're good first blood for someone to work on a browser. So I'm happy to give definitions so that it can be done
16:11:11 <dael> myles: web platforms need motivation
16:11:22 <dael> AmeliaBR: Making this normative and with tests are the keys to get browsers to change
16:11:50 <dael> TabAtkins: Unless we mandate what the colors or mappings are I don't see how to test besides run this on 2 machines and see if it's different and that's not something test engine can do
16:12:10 <dael> AmeliaBR: Good point. Testing isn't set for you to control OS settings. And even then we don't know which expose the fingerprint
16:12:41 <dael> AmeliaBR: If we normatively say these colors must not be certain values or must match a non-dprecated keyword we can test. Might get false passes on a default install that doesn't have user customizations
16:12:50 <dael> chris: [missed]
16:13:03 <dael> TabAtkins: I'm fine with specific colors. I want one for light and one for dark
16:13:09 <dael> chris: White and black!
16:13:23 <dbaron> clearly the default set of colors should be whatever those colors were in the default theme of Windows XP :-)
16:13:23 <dael> Rossen_: This was stated as something used for FP for people with a11y needs?
16:13:55 <dael> AmeliaBR: Not jsut a11y. Certain system colors have a11y needs but that's separated. We have list of undeprecated ones with use cases. THis is ones still deprecated. Some expose user theme settings
16:14:08 <dael> TabAtkins: Not a11y. It's a fingerprinting vector with no gain
16:14:18 <dael> Rossen_: I want to separate and make sure rest [missed]
16:15:03 <dael> TabAtkins: She's saying previously mix of used for a11y and just legacy. a11y ones are separated out. The remaining only exist for backwards compat. We can remove fingerprinting there because there's no value to them. THey have no reason to be user dependent
16:15:32 <dael> AmeliaBR: THey are FP risk for everyone. Ones we're keeping for a11y benefits they still have a FP risk but enough benefit to justify the risk. These have no benefit to jsutify the risk
16:15:44 <dael> Rossen_: That's fine. I think we're still abusing user a11y here but keep going
16:16:10 <dael> TabAtkins: Prop: We come up with a set of mandated color mappings for deprecated system colors, put in spec, and write tests
16:16:14 <dael> many: sounds good
16:16:16 <dael> Rossen_: Objections?
16:16:27 <dael> RESOLVED: We come up with a set of mandated color mappings for deprecated system colors, put in spec, and write tests for them
16:16:27 <dbaron> Worth noting that some UAs might want to make different fingerprinting tradeoffs for the nondeprecated ones.
16:16:33 <dael> Topic: end
16:16:48 <dael> Rossen_: Do we need item 1?
16:16:54 <dael> TabAtkins: No, looks good
16:16:58 <dael> Topic: Make system color keywords compute to themselves
16:17:05 <dael> github: https://github.com/w3c/csswg-drafts/issues/3847
16:17:13 <tantek> tantek has joined #css
16:17:22 <tantek> present+
16:17:40 <dael> TabAtkins: Back in the day system colros could become rgb at computed value time. Now that we can switch user themes using color-scheme you can turn it on and off at subtree. That changes what system colors resolve to
16:17:49 <dael> TabAtkins: Thus they should act like currentColor
16:17:55 <dael> TabAtkins: Talked to our impl and it's fine
16:18:09 <dael> chris: Issue about animation, but can animate currentColor
16:18:16 <dael> AmeliaBR: Don't have interop on currentColor
16:18:45 <dael> AmeliaBR: As far as making system color keywords inherit as keywords we want them same as currentColor. We just need impl to go through details of making currentColor and these inherit as keywords
16:18:53 <dael> AmeliaBR: Right now FF does it. Chrome and I think WK do not
16:19:17 <dael> TabAtkins: Chrome appears to. I tested yesterday. We're doing it sufficiently close to look correct in a test
16:19:27 <dael> AmeliaBR: DOesn't when you animate or you're newer chromium version
16:19:35 <dael> TabAtkins: Might be jsut passin gmy straightforward test
16:19:50 <tantek> interesting, thought we had enough currentColor tests to get interop. curious about the test cases that demonstrate non-interop
16:19:57 <fantasai> dbaron, getComputedStyle would return a resolved color
16:19:58 <dael> AmeliaBR: Complexities with animations; if we still agree currentColor spec is right those same rules would apply to making system colors inherit as keywords
16:20:02 <dael> chris: Makes sense to me
16:20:04 <teleject> teleject has joined #css
16:20:16 <dael> myles: Does that mean fingerprinting is no longer necessary?
16:20:27 <dael> TabAtkins: Nope because they always show as rgb in gCS
16:20:36 <dbaron> s/fingerprinting/fingerprinting stuff we just resolved on/
16:20:41 <dael> TabAtkins: THat's hard compat requirements, people have been relying on it
16:20:52 <dael> chris: Need animation on current and system colors?
16:20:54 <dael> TabAtkins: Sure
16:21:03 <AmeliaBR> s/animation/animation tests/
16:21:41 <dael> AmeliaBR: With the cavaet that we need more tests, any obj to making system color keywords behave like currentColor and inherit as keywords?
16:21:46 <tantek> inherit as keywords makes sense to me
16:22:00 <dael> RESOLVED: Make system color keywords behave like currentColor and inherit as keywords
16:22:02 <fantasai> +1, we need this for them to behave correctly in the presence of forced-color-adjust / color-scheme
16:22:14 <dael> Topic: text system color conflicts with background-clip
16:22:20 <dael> github: https://github.com/w3c/csswg-drafts/issues/4465
16:23:00 <dael> TabAtkins: When we introduced the set of new good system colors we names one text. Means in BG shorthand supplying color text conflicts with clip of text.
16:23:16 <dael> TabAtkins: It's goingt o be a problem when we unprefix
16:23:37 <dael> TabAtkins: Proposal is rename text to canvas-text which matches other pairs. canvas-text is unambig and resolves situation
16:23:46 <dael> TabAtkins: And I dont think text was an old word
16:23:47 <dbaron> s/canvas-text/CanvasText/
16:23:52 <dael> fantasai: Anyone shipped?
16:24:03 <dael> TabAtkins: No. FF wanted to but ran into grammar
16:24:06 <dael> Rossen_: Same for us
16:24:20 <dael> fantasai: In favor. Makes sense and less likely to conflict
16:24:24 <dael> leaverou: Agree
16:24:39 <dael> myles: Worth tryign to come up with system to discover these ambig automatically?
16:24:42 <tantek> that's what CR is for, right? ;)
16:24:50 <dael> TabAtkins: Sounds like it would be valuable, but a bunch of work
16:25:01 <dael> AmeliaBR: TabAtkins write a bikeshed extension for all grammars ^-^
16:25:11 <dael> Rossen_: Objections to rename text to CanvasText?
16:25:30 <dael> smfr: I think WK has shipped text since KHTML days. Someone might be using it in the wild
16:25:30 <dbaron> Such a tool wouldn't have caught this because we haven't actually written the grammar for the background shorthand in backgrounds level 4.
16:25:43 <dael> TabAtkins: Really? Never appeared in list from Color 3. I didn't realize it was live
16:25:48 <dael> Rossen_: Sounds like only in WK
16:25:56 <dael> smfr: Don't know if Chrome removed it post-branch
16:26:00 <dael> Rossen_: I don't see in Chrome keywords
16:26:19 <dael> smfr: Other comment is I thought background clip text was being replaced by something in fill and stroke?
16:26:23 <dael> TabAtkins: Replaced but can't remove
16:26:49 <TabAtkins> Looks like Chrome has removed it: <body style="background-color: red; background-color: text;"> is red.
16:27:00 <dael> AmeliaBR: Shipped in FF unprefixed. One thing is issue is allow background clip text, but don't allow in the shorthand. More complicated to impl and spec vs changing the color keyword. If there is compat issue we want to know what the impact is
16:27:18 <dael> chris: Possible to have old text value as an alias so it works in the longhand but not allwoed in shorthand
16:27:21 <tantek> what about WindowText? noticed that's in the MDN docs: https://developer.mozilla.org/en-US/docs/Web/CSS/color_value
16:27:29 <dael> TabAtkins: Possible, but complexity we like to avoid if we can
16:27:42 <leaverou> UIText may work too
16:27:45 <dbaron> this is presumably different from WindowText since WindowText was a CSS 2.1 value
16:27:51 <TabAtkins> tantek, window/windowtext aren't a pair we chose to use
16:28:11 <tantek> cool TabAtkins, I guess we need to update MDN
16:28:20 <dael> fantasai: I think we should rename this. It's better usability and less complex. If we need to support a text keyword that means the same thing if we need it for compat we've got a bunch of mappings we have to do. WE should check and see if need to address. If not maybe WK drops. If so we figure out a way to handle
16:28:34 <dbaron> CSS 2.1 list is at https://www.w3.org/TR/CSS21/ui.html#system-colors
16:28:36 <dael> fantasai: AS far as system colors we're promoting CanvasText makes sense as will have less problems going forward
16:28:41 <dael> smfr: I'm okay trying to rename
16:28:41 <AmeliaBR> s/thing is issue/thing suggested in the issue/
16:28:50 <tantek> FYI Moz also has -moz-default-color     User's preference for the text color.
16:28:53 <dael> Rossen_: Objections to renaming?
16:29:16 <dael> RESOLVED: Rename text keyword to CanvasText
16:29:18 <TabAtkins> tantek, windowtext is one of the deprecated colors; just not one of the good ones we're using for forced colors. MDN is fine.
16:29:29 <dael> Topic: Color 4
16:29:37 <dael> Rossen_: fantasai did you say want to republish?
16:29:40 <dael> fantasai: Ready for a WD
16:29:49 <dael> Rossen_: How about we publish a WD with these
16:30:02 <dael> fantasai: Hold off on FP until sorted but the last 2 we can do quickly
16:30:13 <tantek> TabAtkins, MDN should label it as explicitly deprecated then
16:30:24 <dael> chris: There's other things I'd like to get in
16:30:26 <dael> fantasai: Which?
16:30:28 <tantek> do we have a changes section ready?
16:30:38 <dael> chris: A couple close to resolution. I also wanted to update issues list
16:30:55 <dael> fantasai: Can publish next week. THinking good to get system color stuff onto a WD since people want to ship
16:31:04 <dael> AmeliaBR: You've got 40 open issues so I'm sure multi publish
16:31:23 <dael> chris: I don't want to close all, there's some possible and I'd liket o get them in
16:31:24 <dael> fantasai: Yeah
16:31:33 <dael> fantasai: Wait until next week?
16:31:37 <dael> chris: Friday is fine
16:31:52 <dael> RESOLVED: Publish a new WD for Colors 4
16:31:59 <TabAtkins> tantek, yeah, a bunch of those should be labeled as such
16:32:02 <dael> Topic: Current Color as an input to paint worklets
16:32:10 <dael> github: https://github.com/w3c/css-houdini-drafts/issues/921#issuecomment-546459060
16:32:37 <dael> AmeliaBR: Related to what we talked about earlier. About CurrentColor having a computed value of the keyword
16:33:24 <dael> AmeliaBR: For typedOM it's supposed to expose computed values, not resolved. TypedOM doens't have a proper model for a color value so for the Houdini APIs that are getting computed values using TypedOM objects they're jsut getting the superclass version.
16:34:08 <dael> AmeliaBR: The issue is what happens if your Paint API relies upon a color property and author uses CurrentCOlor. Example: Use Paint API for a fancy border and relying on border color property. What happens if border color is default currentColor?
16:34:33 <dael> AmeliaBR: IN Houdini currently that's exposed as a keyword and then in your Paint worklet you'd need to depend on color to get the keyword's value
16:35:07 <dael> AmeliaBR: IN shipped Chrome the value exposed isn't a keyword but it's where two string is rgb function which means current Paint worklets are happily using that as a color string they can pass to canvas. but it doesn't match spec
16:35:58 <dael> AmeliaBR: Suggestions are first we change the spec to not talk about currentColor as a keyword which means for now currentColor is treated as a vague superclass where all youg et is a string. Eventually when we have a color value class defined currentColor would be represented in the class same as any other color type.
16:36:21 <dael> AmeliaBR: Somehow at time we define this we make sure two string value always gives us rgb function when applied to computed style object
16:36:49 <dael> TabAtkins: Want to avoid inventing new resolved style. As much as possible I'd like to keep computed style map returning computed styles. That means Chrome impl is wrong and needs to be changed
16:37:21 <dael> TabAtkins: Happy with currentColor becoming a CSS color value. It's compat with that. I don't want to have the value coming out of computed style map be a used value.
16:37:36 <dael> TabAtkins: It is clunky, but I prefer to provide a function that lets you resolve color values in Paint worklets
16:38:26 <dael> AmeliaBR: Other option is to say Paint worklet knows how to resolve keyword values. Covers most cases where someone grabs computed style and uses it directly in the Paint commands. So long as whatever string from typed OM is valid in Paint commands covers most use cases. Wouldn't cover parse and do math, but that's rarer
16:39:19 <dael> TabAtkins: Sounds good too. WE can cover all use cases by having Paint API canvas painting methods be able to take contextual keywprds directly and have Paint worklet have a function to manuallyr esolve colors into rgb for you. Then keep computed style map actually a computed style
16:40:01 <dael> AmeliaBR: Are you okay...right now there's text in Typed OM that curretnColor is a css value keyword object can we say it returns as superclass css value type even if string reflects string of keyword until color models are specced?
16:40:05 <dael> TabAtkins: Yes, I think we should
16:40:13 <dael> TabAtkins: Need to make sure system colors do same thing
16:40:35 <TabAtkins> 1. Specify that the PaintWorklet's canvas-ish methods can take color keywords and do the right thing.
16:40:46 <dael> AmeliaBR: Actual change at this point would be remove all property specific rules in typed om that require currentColor to be returned as a css key value
16:40:50 <TabAtkins> 2. Add a PaintWorklet global function that can resolve color keywords into RGB.
16:41:25 <dael> AmeliaBR: Separate note for Chrome impl to match spec as far as returning computed values which happens at same time as change to paint API which allows keywords to be used in the paint color properties. That's the other normative change
16:41:28 <TabAtkins> 3. Fix Typed OM spec to ensure that currentcolor and system color keywords reify as CSSStyleValue, not CSSKeywordValue, until we have CSSColorValue for them to reify as.
16:41:47 <dael> smfr: Other cases where authors want to convert currentColor to rgb? Only Paint worklets sounds limited
16:42:28 <dael> TabAtkins: Problem is that if we want computedStyleMap to return computedStyles we're going to have these cases where some values at time being passed can't be resolved further because of state. Layout worklets might want this. OTher worklets are in the same boat.
16:42:39 <dael> TabAtkins: Similar to resolving % and other use time values that are useful.
16:43:03 <dael> TabAtkins: Colors are resolvable jsut after inheritience so might be a special case that's handled badly by concept of computed values
16:43:34 <dael> TabAtkins: UNless we define a 4th value mode and say computed style map returns that I'd rather less conevnient but consistent rather then arbitrary mismatch
16:43:49 <dael> AmeliaBR: smfr had good point about universal way to get resolved color keywords relative to context elements
16:44:05 <dael> AmeliaBR: WOuld expect that's part of spec how colros work in TypedOM and also part of other color format conversations
16:44:22 <dael> AmeliaBR: With that in mind maybe don't do gloabl function in Paint worklet.
16:44:42 <dael> AmeliaBR: What we do need in short term is simple case within PAint workelt if you use currentColor it works correctly
16:45:19 <dael> TabAtkins: Issue with resolve agaisnt element wedon't pass anything that's an element into a worklet. Can implicitly resolve with a context. I think works for custom Functions
16:45:53 <dael> AmeliaBR: Model I suggested in issue for resolving values is that the computed color value object is associated with a palette that defines what color values represent for keywords so it's passed in at that time
16:46:27 <dael> TabAtkins: At computedv alue time we don't know that yet. You could say here's the possible values, but you don't know what it ends up as. Unless we have anothe value stage between computed and used we can't express that in a meaningful way
16:46:56 <dael> AmeliaBR: When you know computed values you also know value for color and color shceme. From those you know the palatte that desc what kewyrods mean for any other color property
16:47:20 <dael> TabAtkins: I think you're right. I take it back. We can call this a computed value that knows it's a keyword, but it knows what it will turn into b/c we know other valyes
16:47:33 <dael> TabAtkins: Implies new dependency edges and need to think about how to do those
16:47:40 <dael> TabAtkins: I do think there's a path forward
16:48:15 <dael> TabAtkins: THe used value time colors should downgrade to generic supercalss. Paint API takes those and acts appropriately. I'll work on how to solve getting you the colors properly
16:48:31 <TabAtkins> 1. Specify that the PaintWorklet's canvas-ish methods can take color keywords and do the right thing.
16:48:36 <dael> TabAtkins: I listed several things, I'll put 2 to resolve on
16:48:43 <TabAtkins> 2. Fix Typed OM spec to ensure that currentcolor and system color keywords reify as CSSStyleValue, not CSSKeywordValue, until we have CSSColorValue for them to reify as.
16:49:01 <dael> AmeliaBR: Do the right thing means when you use...
16:49:17 <dael> Rossen_: I jsut wanted to know if we were resolving. If not, we can just resolve on these
16:49:31 <dael> Rossen_: propsed resolution 1 is Specify that the PaintWorklet's canvas-ish methods can take color keywords and do the right thing
16:49:38 <dael> Rossen_: Objections?
16:49:53 <dael> AmeliaBR: Do we understand do the right thing in this context? It's using context of element you're painting
16:49:55 <dael> RESOLVED: Specify that the PaintWorklet's canvas-ish methods can take color keywords and do the right thing
16:50:04 <dael> Rossen_: Second is Fix Typed OM spec to ensure that currentcolor and system color keywords reify as CSSStyleValue, not CSSKeywordValue, until we have CSSColorValue for them to reify as.
16:50:28 <dael> fantasai:This is change to typed OM?
16:50:42 <dael> TabAtkins: Yes. Currently says it's css keyword and we're going to superclass instead
16:50:56 <dael> fantasai: Wasn't point of typed OM is when you ask for comptued you get computed
16:50:57 <AmeliaBR> s/css keyword/CSSKeywordValue/
16:51:13 <bkardell_> bkardell_ has joined #css
16:51:21 <dael> TabAtkins: Yes, which is currentColor keyword. But we used the superclass when we don't have something represented specifically
16:51:30 <dael> fantasai: It's a keyword but expose as somethign else?
16:51:41 <dael> AmeliaBR: As a generic css computed value where all you can do is expose the string
16:51:44 <dael> fantasai: Okay, gotcha.
16:52:08 <dael> Rossen_: Prop: Fix Typed OM spec to ensure that currentcolor and system color keywords reify as CSSStyleValue, not CSSKeywordValue, until we have CSSColorValue for them to reify as.
16:52:18 <dael> Rossen_: Objections?
16:52:24 <dael> RESOLVED: Fix Typed OM spec to ensure that currentcolor and system color keywords reify as CSSStyleValue, not CSSKeywordValue, until we have CSSColorValue for them to reify as.
16:52:40 <dael> AmeliaBR: All other things will turn into a proposal for L2
16:52:44 <dael> TabAtkins: Or L1, but later.
16:52:52 <dael> Topic: Table row resolved width and height.
16:52:59 <dael> github: https://github.com/w3c/csswg-drafts/issues/4444
16:53:24 <dael> Rossen_: emilio opened.
16:53:38 <dael> TabAtkins: If emilio fremy and alex aren't on we can't discuss reasonably
16:53:50 <TabAtkins> s/alex/aleks/
16:53:54 <dael> Rossen_: Fair. Looking through webex I don't think they are
16:54:13 <astearns> skip shapes
16:54:25 <dael> github: none
16:54:42 <dbaron> I think the broken audio is actually a WebEx problem and not our connections to WebEx...
16:54:43 <dael> AmeliaBR: astearns wants to skip shapes
16:54:46 <dael> topic: end
16:54:54 <dael> Topic: proposal new transform-style: detached
16:55:17 <dael> github: https://github.com/w3c/csswg-drafts/issues/4242
16:55:32 <dael> AmeliaBR: We introduced last week, but wanted to hold for Rik
16:55:42 <dael> github: none
16:56:12 <astearns> we could probably resolve on https://github.com/w3c/csswg-drafts/issues/675, but my audio apparently isn't working
16:56:36 <dael> Topic: Provide a way to specify rastered content scale for transformed content
16:56:40 <fremy> fremy has joined #css
16:56:43 <dael> github: https://github.com/w3c/csswg-drafts/issues/236
16:57:05 <dael> smfr: Browser have traditionally rasterized elements to gpu texts when authors apply something like 3d transforms.
16:57:39 <drousso> drousso has joined #css
16:58:18 <dael> smfr: Various attempts by impl to choose a good scale. User says scale-3d 2,2,1 At least in WK we don't re-rasterize so it becomes pixelated. Re-raster is hard because if content is dynamic what scale? Right thing is let the author decide since they're only one that really knows what's going to happen?
16:58:51 <dael> smfr: This issue proposes a new property to let authors spec rasterization scale. Reasonable. UA should be able to decide not to use that scale for reasons like memory
16:59:36 <TabAtkins> chrishtr: I'm not sure what the right API shape should b eand how we should describe it
16:59:53 <TabAtkins> smfr: I assume it would be `scale-suggestion: 2` or something
16:59:57 <TabAtkins> (i made up the property name)
17:00:09 <TabAtkins> AmeliaBR: I assumed `max-expected-scale`
17:00:30 <TabAtkins> AmeliaBR: Transforms are cumulative tho; needs some detail about how much accumulation is expected.
17:00:54 <TabAtkins> dbaron: Gecko at some point in the past tried to do smarter things, and we did occasionally hit things where devs had an expectation of the simpler WebKit behavior.
17:01:16 <TabAtkins> dbaron: One example was a very quick zoom-in animation; it loads by starting big and quickly shrinking to the correct size.
17:01:22 <drousso_> drousso_ has joined #css
17:01:36 <TabAtkins> dbaron: We had a bug where we were rasterizing with too much memory in that situation. This animation was on the firefox home screen so it was detected.
17:01:58 <TabAtkins> dbaron: So we did see some cases where authors didn't want the logical rasterize to be at the highest density point, because it was zoomed thru quickly enough to not matter.
17:02:17 <TabAtkins> chrishtr: I wonder if it would work to have someting that declares it will animate, with the curve or the balance.
17:02:26 <TabAtkins> AmeliaBR: Maybe add more info to will-change
17:02:39 <abalasubramaniyan_> abalasubramaniyan_ has joined #css
17:02:39 <TabAtkins> AmeliaBR: will-change:transform isn't a lot of help; different optimization for transform vs scaling
17:03:11 <TabAtkins> dbaron: I think will-animate isn't necessarily enough. Some animations are slow and you want detail; others are fast and you don't.
17:04:07 <TabAtkins> Rossen_: So we're over time. Take this back to the issue.
17:05:00 <Rossen_> trackbot, end meeting
17:05:00 <trackbot> Zakim, list attendees
17:05:00 <Zakim> As of this point the attendees have been Rossen_, rachelandrew, dael, rego, plinss, antonp, chris, AmeliaBR, leaverou, chrishtr, astearns, cbiesinger, dbaron, teleject, smfr, bdc,
17:05:04 <Zakim> ... dauwhe, dlibby-, tantek
17:05:08 <trackbot> RRSAgent, please draft minutes
17:05:08 <RRSAgent> I have made the request to generate https://www.w3.org/2019/10/30-css-minutes.html trackbot
17:05:09 <trackbot> RRSAgent, bye
17:05:09 <RRSAgent> I see no action items