17:35:10 RRSAgent has joined #houdini 17:35:10 logging to https://www.w3.org/2017/11/09-houdini-irc 17:35:17 rrsagent, please make record public 17:35:19 astearns: disadv I can think of -> converters for each format were in each format. Simpler interface that allows you to convert btw represntations 17:35:30 trackbot, associate this channel with #css 17:35:30 Associated this channel with #css. 17:35:52 TabAtkins: designed such -> you can addas many converters as needed. All that is required is to define toRGB version. Tha you can use with some fidelity loss 17:35:55 dauwhe has joined #houdini 17:35:58 RRSAgent, make logs public 17:36:01 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 17:36:01 Date: 09 November 2017 17:36:07 TabAtkins: if you wanted to convert from HSL to RGB you may lose hue info.... 17:36:24 dauwhe has left #houdini 17:36:36 astearns: dont know enough about various information, looking at duping in spec text. partial version that could be a mixin of specific versions 17:36:50 TabAtkins: Things are currently relying on internal implementations 17:37:04 astearns: then there are details that I dont know much about. Ignore me. 17:37:13 Ralph has left #houdini 17:37:21 Rossen: 17:38:03 xidorn: i dont think we need hex color class - useless to RGB and .. colors. 17:38:25 TabAtkins: ditinctin that it preserves knowledge of how to serialize. Imp if you want specified color to be close to what you are .. 17:38:34 dbaron: syntax could be bool in single class 17:38:40 s/bool/bool or enum/ 17:39:04 TabAtkins: yes. I did distinguish RGB is 0 to 1 in channel, Hex can represent 0-255 (numbers) 17:39:17 dbaron: RGB doesnt allow outside of 0 to 1?? HAVE WE DECIDED 17:39:40 s/HAVE WE DECIDED/Have we decided?/ 17:39:43 TabAtkins: Putting that to the side, even within the 0-1 range rgb() allows more detail than hex 17:40:12 xidorn: if we want to preserver serialization - hex color has 3/4 ways to srialize. How canyou presever that? 17:40:20 TabAtkins: We are preserving general syntx 17:40:29 TabAtkins: fff -> serializes as ffffff 17:40:45 TabAtkins: this was before alpha was declarable in hex syntax 17:41:01 TabAtkins: if we want to preseve to that detail - need to track more information. 17:41:34 TabAtkins: we have the concept of specifed values - OM can remember the string they were generated from and can serialize to that. But once you manipiulate they serialize to standrd way 17:41:46 TabAtkins: so we can jsut rely on that? Authors can get syntax they put in 17:42:24 TabAtkins: Does that work for everyone? RGB fucntion too needs to track the diff values 17:42:35 dbaron: RGB allows either % or number but not a mix? 17:42:45 s/RGB/rgb()/ 17:42:59 TabAtkins: More flags that need tracking - to keep author syntax beyond what they put in. 17:43:31 dbaron: Hard to keep track of proposal - generally happier with fewer classes. No strong opinion other than dont break the other stuff 17:43:46 TabAtkins: Guarantee it wont break other contraints. Defo more classes approach. 17:44:02 surma: which is what we have with lengthvalues 17:44:14 TabAtkins: Nope that you specify the unit separately. 17:44:22 dholbert: Why not that approach for colors? 17:45:06 TabAtkins: Doing so because channels are named in conflicting - even if you use full name. HSL and LCH have different lightness notions 17:45:21 dholbert: Alterntive - enum saying this color is lCH/HCL. 17:45:26 TabAtkins: How you manipulate 17:45:41 dholbert: you know what it is internally. If you know somethign is HSL convert as so? 17:46:02 TabAtkins: API will ahve attributes for all channels and knows whqt to return depending onw hat channel 17:46:17 dholbert: Change represetation under hood depending on channel 17:47:34 dbaron: setters like that - you amy want to set multiple in sequence. If you want to set all of H,S,L then you want it to be like you specified all three separately. If underlying representation is somethign else - changing the color so thta if H or S or L is somthing. You dont get the needed HSL color 17:47:35 TabAtkins: MOst particularly, if your underlying valu eis rgb, and you set a saturation to 0, the hue information has disappeared and you can't get it back. 17:48:07 TabAtkins: More dramatic version of the specified is what you get. 17:48:34 TabAtkins: Not comfortable with the large tagged union. 17:48:50 fremy: crrentColor needs tobe represented but you cant set HSL on it. 17:48:56 TabAtkins: its just a keyword 17:49:09 surma: keywords liek red, bue are aliases? Or string? 17:49:16 TabAtkins: Turned into rgb/hex color. 17:49:45 TabAtkins: if you are setting that - the specified value will remember what it was generated from andsrialize approriately. 17:49:57 xidorn: How would you handle currntColor? 17:50:13 TabAtkins: return as CSSKeywrodValue. A Typed OM class 17:50:26 TabAtkins: you may get a keyword value for Color Vlaue 17:50:43 TabAtkins: Have to do that since currentColor is generally calculated at runtime, 17:50:55 s/runtime/used value time 17:51:51 Rossen: have you played with this in Paint? 17:51:58 TabAtkins: can do cause spec text i raw JS 17:52:42 RESOLVED: Tab works on Color value proposal he has, and we can look into it later. 17:52:52 Topic: What should CSSNumericValue.type() do? 17:53:04 Github: https://github.com/w3c/css-houdini-drafts/issues/482 17:53:28 TabAtkins: before calc stuff type was easy - returned string with unit or generic thing like length 17:53:38 TabAtkins: difficult due to calc stuff. Map of type to power. 17:54:10 TabAtkins: Q now is what form is type in JS. Simple answer: object literal from type to integer powers. 17:54:18 dbaron: omitt things that are 0? 17:54:33 TabAtkins: Not always. Type maps keeps track of 0 things. Cant add pixel to s/s 17:54:45 TabAtkins: incompatible expression . 17:54:58 TabAtkins: one type thaat is pixel. Other one is a mathdivide of s/s 17:55:05 dbaron: its unitless? 17:55:09 TabAtkins: its unit is still time? 17:55:14 dbaron: ... 17:55:29 TabAtkins: I remember preserving zero types for a reason... 17:55:57 TabAtkins: If I can remember why there may have been zero types at one point. 17:56:08 dbaron: will there be a simple way to access abstract dimension of unit? 17:56:25 dbaron: eg px diided by em. Remember that px/em but abstractally itss unitless 17:56:37 TabAtkins: yes that is what the type map tracks and returns 17:57:07 https://drafts.css-houdini.org/css-typed-om/#numeric-typing 17:57:17 TabAtkins: describes how to produce a type from various things... 17:57:23 TabAtkins: maps categories to powers 17:57:59 lajava_ has joined #houdini 17:58:35 TabAtkins: One limitaation - general caswe - where you are trying to handles % correctly. Hvave to do type inference to see if expression is avllid. There are some compocated div case that shoudl work but are rejected by my expression 17:58:46 dbaron: this is becaue you arent converting % to what it si equivalent to 17:59:12 TabAtkins: So i nedto checkthat if % wa converted to a valid typed would it be a valid type? 17:59:55 TabAtkins: Just returning a map is simple and does job - in simple cases it is more complicated than needed. this addressed general case? 18:00:09 fremy: Can we get a helper that gets type and returns whether the map is of that type? 18:00:25 TabAtkins: Yes to and to Sum fucntion takes input and throws if it cant convert. 18:01:10 RESOLVED: type() will be a map of units to powers 18:01:21 Topic: Add spec text for arraylike in CSSTransformValue 18:01:37 Present+ lajava 18:01:41 Present+ fantasai 18:01:51 github issue: https://github.com/w3c/css-houdini-drafts/issues/487 18:02:00 TabAtkins: have arraylike eg transformvalue, unparsed value. There will be more. 18:02:13 TabAtkins: Probem is WebIDL doesnt allow us to do typechecking on array. 18:02:44 TabAtkins: So working around is indexed accessors that invokes proxy machinery. Only way to not do expplicit type check 18:02:53 fantasai has joined #houdini 18:02:59 TabAtkins: It would also be annoyign to implemnt/spec up 18:03:41 TabAtkins: Propose to use indexed getters/setter - and then bring this up at TC39 meeting. Proposal to allow cheap accessto indexed props. 18:03:57 TabAtkins: Good discussion 10 years ago. Support from brosers at tht time. 18:04:09 TabAtkins: We can switch over to that - cheaper than full proxy. 18:04:17 zcorpan has joined #houdini 18:04:48 TabAtkins: Proposal is to start with indexed accessors, and then switch to just indexed propoerty interception when Tab propses it to TC39 18:05:09 TabAtkins: We then have good early type error for things like transform values. We can throw on appending. 18:05:39 TabAtkins: Also less typechecking logic in spec text . But proxies are more expensive. But we already use this in a few places in teh paltform. 18:05:50 Rossen: Seems reasonable. How likely TC39 will adopt? 18:06:19 TabAtkins: Dont know about when. But people supported it then and they qre still round. related proposals keep coming up. 18:06:35 TabAtkins: So something related would get accepted easily. 18:07:25 RESOLVED: use indexed getters/setter - and then bring this up at TC39 meeting to just indexed property interception 18:07:40 Topic: Simplifying expressions in CSSMathValue subclasses 18:07:42 GitHub: https://github.com/w3c/css-houdini-drafts/issues/503 18:08:03 TabAtkins: Math operations in class - you can say px.add(some other px value) 18:08:37 florian has joined #houdini 18:08:42 TabAtkins: some operations have shortcuts to return the operation. Have it for add, negate, sub. Dont have it for mul, div, invert, min, max 18:09:03 TabAtkins: Have a sketch in the issue of how to do it. Apply these shortcuts to all operations or none? 18:09:20 TabAtkins: Add always returns a CSSMathSum or a unit vaoue if easily computable? 18:09:38 Rossen: Similiar with what we do to calc? You simplify it down 18:09:42 https://drafts.css-houdini.org/css-typed-om/#dom-cssnumericvalue-add 18:09:42 TabAtkins: Yes 18:09:56 Rossen: would align with what we already expose 18:10:14 TabAtkins: People who want to increment length by 1 unit will still get a length unit and not complicated expression 18:10:30 dholbert: addition inside of a loop - would be a good idea 18:10:40 Rossen: it keeps expanding. 18:10:59 florian has joined #houdini 18:11:12 RESOLVED: mul/div/invert/max/min should have shortcut just like add/negate/sub 18:11:21 Topic: Do CSSMathValue subclasses copy their constructor arguments? 18:11:27 GitHub: https://github.com/w3c/css-houdini-drafts/issues/494 18:12:07 TabAtkins: When I first drafted math classes they converted to new objects when read out. People didnt like that. 18:12:46 TabAtkins: Algo assumptions depended on getting fresh valudes that werent modifiable. So a px and a s would throw. But you can change the unit later. G9oes undetected until later. 18:13:09 TabAtkins: We cant do checks at mutation time. object moght be used in multiple places, where some might be fun but not all. 18:13:29 TabAtkins: So proposal is to restrict changing the type of MathVaues. Stay within category at least. 18:13:46 TabAtkins: Dont even think there is need to change within category. Happy to make type readonlhy 18:14:11 TabAtkins: Impact - cant change 5 px to 5 em by changing type. Do by constructing a new value. 18:14:32 TabAtkins: Minimal addition API weight for someone wanting to do this. (change px to em) 18:14:50 Rossen: You can easily wrap what you just said 18:15:01 TabAtkins: to method already does that 18:15:17 TabAtkins: Objections to changing type to read only? 18:15:24 I'm generally happy with immutability. 18:15:48 RESOLVED: Change type to be immutable 18:19:15 lajava_ has joined #houdini 18:21:35 github-bot, end topic 18:21:43 github-bot, status? 18:21:43 dbaron, This is wgmeeting_github_ircbot version 0.2.9, compiled from b436c41d955d00313e7ec9e3e2541ba8949e29c6, which is probably in the repository at https://github.com/dbaron/wgmeeting-github-ircbot/ 18:21:43 I currently have data for the following channels: 18:21:43 #css (11 lines buffered on "none") 18:21:43 no GitHub URL to comment on 18:21:44 #fx (no topic data buffered) 18:21:44 #houdini (no topic data buffered) 18:21:44 #pwg (66 lines buffered on "Wrap of the meeting") 18:21:45 no GitHub URL to comment on 18:21:45 #svg (no topic data buffered) 18:21:45 #tt (2 lines buffered on "What fillLineGap does/ affects #254") 18:21:46 will comment on https://github.com/w3c/imsc/issues/254 18:23:02 github-bot, status 18:23:02 dbaron, This is wgmeeting_github_ircbot version 0.2.9, compiled from b436c41d955d00313e7ec9e3e2541ba8949e29c6, which is probably in the repository at https://github.com/dbaron/wgmeeting-github-ircbot/ 18:23:02 I currently have data for the following channels: 18:23:02 #css (no topic data buffered) 18:23:02 #fx (no topic data buffered) 18:23:03 #houdini (no topic data buffered) 18:23:03 #pwg (no topic data buffered) 18:23:03 #svg (no topic data buffered) 18:23:04 #tt (2 lines buffered on "What fillLineGap does/ affects #254") 18:23:04 will comment on https://github.com/w3c/imsc/issues/254 18:32:51 florian has joined #houdini 18:33:37 ScribeNick: TabAtkins 18:33:56 tantek has joined #houdini 18:34:45 Topic: What is the computed value of a in the middle of a layout dependent matrix decomposed interpolation? 18:34:59 GitHub: https://github.com/w3c/css-houdini-drafts/issues/425 18:35:18 Scribenick: nainar 18:35:51 TabAtkins: Problem - you have a rtanstition between translate 30% and rotation 30 deg. The 30% is less dependant on lyaout info. 18:36:05 TabAtkins: you are in the middle of transition - due to incomaptiblilty you get matrix 18:36:15 TabAtkins: What should CSSOM return for Computed value? 18:36:28 TabAtkins: string based computd vaue can return layout dependant, but typed om cant 18:37:10 dbaron: interpolatematrix in gecko internally. This is important for intepolation rules for transform Needs to interpolate between partial inter-polation results. So that you can change in the middle3of transtion 18:37:23 Samarth has joined #houdini 18:37:29 dbaron: There is other rationale for interpolation this. 18:37:42 dbaron: Thought we agrred to add this to transform spec? 18:37:49 TabAtkins: Happy to add it but not there currently 18:37:56 surma: why cant we interpolate on % value 18:38:07 dbaron: you cant represent computed value without layout 18:38:30 TabAtkins: GCS does used vaoue for this. We are trying to return ComputedValue which isnt representable as a list 18:38:48 surma: Sounds like you need to solve geenrically. 18:39:02 TabAtkins: Add interpolate function that interpolates between two values. Like cross fade 18:40:53 TabAtkins: Proposal name is blend 18:41:01 dbaron: Sounds too imge-y 18:41:13 mwoodrow: Happy to accept concept not name 18:41:54 dholbert: You could simplify calc in many cases. 18:42:05 lajava_ has joined #houdini 18:42:11 s/calc/to calc/ 18:42:18 TabAtkins: computed value from 10 px to 10 px should be a px value not the function 18:42:28 RESOLVED: Add generic interpolation function. Name TBD. For Units and Values spec. 18:42:51 s/Units and Values/Values and Units/ 18:42:54 Topic: var() references to type properties with font-relative lengths 18:43:05 GitHub: https://github.com/w3c/css-houdini-drafts/issues/315 18:43:23 TabAtkins: Issue has the case 18:43:56 TabAtkins: 18:44:30 TabAtkins: Preferr to lena on dependancy resolution. They should gain a dependacy on the font zie property and a cyclic dependacy would make the property invalid at computed time. 18:44:49 dbaron: This isnt ehe only case of unit type dependacy on property. 18:44:57 TabAtkins: Generalize to other properties too. 18:45:15 dbaron: Is this only for typed custom props? 18:45:18 TabAtkins: Yes. 18:46:00 Discussion about naming typed/registered custom propries 18:46:12 TabAtkins: Are we doing to get in this case 100px and 1000 px for font size and variable 18:46:27 TabAtkins: Or will we get somethign invalid with font size returning to 1 em? 18:46:41 dbaron: var reference is referencing a computed value it should be invalid. 18:46:58 TabAtkins: Make sure I capture all teh cases that dcan cause this and add to graph. I am down with this. 18:47:01 Rossen: 18:47:13 astearns: Property is invalid right? 18:47:29 TabAtkins: If invalidation happens font would be invalid and retun to inherit. 18:47:41 astearns: Typed property would be fine? 18:47:45 TabAtkins: Yes 18:47:59 dbaron: What about units that depend on font selection? 18:48:18 dbaron: What if you use a calc expression in one of those units? 18:48:37 TabAtkins: you can do this for font weight for e.g 18:48:58 TabAtkins: they are depdant on font peropeties and if you depend on that you have a cyclic dependacy 18:49:18 dbaron: Hard - that there is a dependacy graph in everyone's head - need to write this down 18:49:29 https://wiki.csswg.org/spec/property-dependencies 18:49:37 fremy: Can you define font size as a custom property and get in the same situation?> 18:49:53 TabAtkins: NO in that case you get a percent if y9ou ask for a computedvalue 18:50:08 fremy: so a % can stay as a % on computedtime 18:50:16 18:50:48 TabAtkins: These tables need to be translated to spec txt for completion 18:51:24 xidorn: color and currentColor comment in issue doesnt apply. currentColor should be computed at computedvalue tinme not used value time. 18:51:33 TabAtkins: Yes it does. 18:52:30 tantek: People want to specify full set of unit and depdancyies and using that in exisitng variable dependancy logic 18:52:40 s/tantek/??? 18:52:40 Rossen: Solution to this issue would fall out of it? 18:52:46 TabAtkins: ues 18:52:52 s/ues/yes/ 18:52:58 florian has joined #houdini 18:53:05 s/???/TabAtkins 18:53:28 RESOLVED: specify full set of unit and depdancyies and using that in exisitng variable dependancy logic. This issue is solved from there. 18:53:44 Topic: define how typed custom properties influence @support 18:53:47 GitHub: https://github.com/w3c/css-houdini-drafts/issues/118 18:54:08 TabAtkins: When you register a custom property with graammr - infrunece use in @SUPPORTS? 18:54:30 TabAtkins: Or go with current variable behaviour? And always supported? 18:54:52 TabAtkins: Latter is closer t oour agreemnt. Parsing wise allow everything. And invliadate at computed value time. 18:55:10 TabAtkins: Makes it annoying for when you are trying to do Shane's example. 18:55:14 div { 18:55:14 --foo: 3em; 18:55:14 --foo: 5newlengthunits; 18:55:14 } 18:55:27 Shane's example^ 18:56:02 dholbert: authors could hack around this by using width instead of --foo? 18:56:15 TabAtkins: yes, hacky. so dont force on authors? 18:56:29 dbaron: Does regitering a new custom property force a new parse of stylesheet? 18:56:32 TabAtkins: I think no? 18:56:55 iank_: Is the example valid? Thought it would take the last one? 18:57:05 dholbert: That is for CSSS variables not for ... 18:57:25 iank_: resolved that we were supposed to store everything. To avoid reparse? 18:57:49 isssue 63 was directly related 18:58:17 iank_: Thought we had the ability to take only the last one? 18:59:04 astearns: I'm not seeing anythign relavant in current draft 18:59:16 dbaron: is ther stuff that wold conceptually force you to reparse the stylesheet? 19:00:00 "issue 63" mentioned above is https://github.com/w3c/css-houdini-drafts/issues/63 (I hope that doesn't trigger the bot to put notes there) 19:00:07 https://lists.w3.org/Archives/Public/public-houdini/2016Feb/0004.html 19:00:39 astearns: Still need spec txt to explain this better? 19:01:16 TabAtkins: We do reparse custom properties. if you declare foo to be color we throw away any decalation that isnt a color. 19:01:32 But if you use "color: var(--foo)", it's valid regardless of registered type for --foo 19:01:48 dbaron: but you are only reparsing variable declationr? 19:01:59 TabAtkins: Yes not usage. As we didnt want to hold cascade. 19:02:28 dbaron: Hesitant as dont want to add ways that registering properties changes more of the stylesheet. E.g you ave stylesheets and script loads happen. 19:02:42 dbaron: this means yu now need to block stylesheet load on script load. 19:02:56 dbaron: Before you did it the oteer way round. 19:03:16 iank_: We only ever look at the second one. If it is invalid we return to initial value 19:03:27 s/did it the oteer way round/only needed to block script execution on style sheet loads/ 19:03:31 TabAtkins: We only keep the last one. 19:03:57 19:04:06 s/Chrome/Blink 19:04:14 https://gist.github.com/bfgeek/6e915f873eb30ed5e4e20e14a73cd5cb 19:04:39 fremy: there was a proposal to allow decalrion to be in stylesheet. If you do that you dont have to declare this in script? 19:04:54 TabAtkins: no you can always manipulate CSSOM .... 19:05:37 If you say that @custom-prop can influence @supports, but registerProperty() can't, and peopl ecan just use script to createe a @custom-prop rule, you haven't gained anything. 19:05:55 lajava_ has joined #houdini 19:05:55 xidorn: you can stop CSSOM fro chaingin ssomething. 19:06:05 xidorn: can you change namespace? 19:06:16 xidorn: we dont have charset rule in CSSOM for eg 19:06:36 TabAtkins: you can ccreate a script element in script and can insert it to doc 19:07:12 xidorn: if custom property @rule exisyts it only registers for that one property. Doesnt trigger repasrse of style but affects @supports 19:07:27 I've updated the gist to console.log the answers. 19:07:38 TabAtkins: We add something to add a type and value and allows us to return ifvalue is supprted by type 19:08:03 TabAtkins: if the type is exposed as the same thing as Typed OM uses. 19:08:40 TabAtkins: Proposal is custom properties are uselss in @supports and return true. But separately pursue another predicate that allows you test if a vaue matches a type 19:09:03 TabAtkins: ... where the types are drawn from the set of things custom properties can do. 19:09:13 TabAtkins: That way you need to know if new value is for eg a length type. but no reparsing is required. 19:09:35 TabAtkins: Address dbaron concern . Less hacky that finding . property that parses similarly. 19:10:06 @supports type(, 5px) { ... } 19:10:08 dholbert: Syntax to be dfined right? 19:10:25 TabAtkins: In some wrapper looks like 19:11:05 RESOLVED: custom properties are useless in @supports and return true. But separately pursue another predicate that allows you test if a value matches a type where the types are drawn from the set of things custom properties can do. 19:11:51 Topic: Allowing a default invalid initialValue when syntax is not "*" 19:12:01 GitHub: https://github.com/w3c/css-houdini-drafts/issues/453 19:12:31 TabAtkins: Syntx of custom props is *. This allows default invalid value too. 19:13:10 TabAtkins: Servo iplementor expected default invalid value to be allowed too. But I think no, you should declted an initial value 19:13:28 TabAtkins: I dont see why we should allow a bottom value to all properties like this. 19:13:48 TabAtkins: Proposal reject as no change? 19:14:31 astearns: if yu had alot of registere props of a particulat type. Make sure initial value is in every declaration. 19:14:38 TabAtkins: This is already required. 19:14:46 iank_: It's trivial to do this 19:14:48 smfr has joined #houdini 19:15:00 RESOLVED: Reject as no change. 19:15:13 ScribeNick: TabAtkins 19:15:22 github-bot, close topic 19:15:22 TabAtkins, Sorry, I don't understand that command. Try 'help'. 19:15:29 github-bot, end topic 19:15:34 Topic: Concrete object size should be the snapped pixel size? 19:15:51 github: https://github.com/w3c/css-houdini-drafts/issues/508 19:16:22 iank_: In th eissue, flackr has a detailed descriptionof what we want to do. 19:16:27 iank_: Involves pixel snapping of iamges 19:16:30 iank_: Happens a lot 19:16:49 iank_: Proposing #3 on this list, to adjust concrete object size to snapped pixel size / device pixel ratio 19:16:59 iank_: So if people just naively draw into the size get the expected beahvior. 19:17:40 iank_: If people want to draw a perfect pixel-aligned line, they can multiple by pixel ratio 19:17:57 TabAtkins: So they might get like a 10.5px value for th eobject size? 19:17:59 iank_: Yes 19:18:10 smfr: If you ahvea transformed ancestor this doesn't affect that, right? 19:18:17 iank_: Yeah 19:18:24 smfr: Like we do today with paintaing backgrounds? 19:18:30 iank_: Yes. Matches what we do internally. 19:18:47 dbaron: I think our transform behavior doesn't match this. We try in some cases to rasterize at higher resolutions. 19:18:51 dbaron: We might have changed that. 19:18:56 mwoodrow: We still do that. 19:19:01 smfr: We do that too 19:19:12 smfr: If you do scale(2) we'll rasterize at higher resolution 19:19:26 smfr: But I thin kthe snapping we do ignores transforms 19:19:35 TabAtkins: In the general case you have to; it might not be axis-aligned 19:19:51 dbaron: I think if the transform is only a translate/scale, we try to honor that with higher fidelity. 19:20:43 TabAtkins: Do we want to try and make the spec generic to platform behavior? 19:20:55 dbaron: Maybe - we should probably converge at some point. 19:21:30 iank_: Nice thing is that this approach lets naive behavior work right, regardless 19:21:45 TabAtkins: I can help with the spec text if we want to allow platform divergence here. Testing is harder tho. 19:21:51 TabAtkins: But if we want to spec a single behavior that's a different thing. 19:22:02 iank_: Yeah, that requires more convergence. 19:22:40 TabAtkins: So resolution is, *whatever* the browser's snapping bheavior is, it must apply in the way described in #3? 19:22:45 Rossen: And #4 means no snapping? 19:23:07 Rossen: Because backing stor epixel ratio is what gets you back to physical pixels, so conversion happens in user code, nobody has to muck around with adjust the size 19:23:17 Rossen: So whatever Gecko does... 19:23:28 iank_: If we give people physical pixels, that has a bunch more interop issues. 19:23:48 iank_: If we end up giving you a much larger backing store and Gecko doesn't, and you naively assume its the CSS size, it gives us interop pain. 19:24:10 iank_: It might be a better option later on to actually request physical pixels, but for now we have the naive possibly-fractional CSS px 19:24:58 TabAtkins: What does the backing store look like if we ahve a 2x pixel ratio? 19:25:08 iank_: First, it might be different from the device pixel ratio, due to scales 19:26:34 iank_: You can't see the underlying pixel ratio of the canvas in the worklet. 19:26:42 TabAtkins: Ah, that satisfies my concern. 19:27:03 iank_: And later we can add a flag to ask for th ephysical size if you really want to draw hairlines or something. 19:27:20 smfr: A general comment - you should get the same rendered result whether the UA stores a display list or a bitmap 19:27:30 smfr: Question - does the context start with a scale for the dpr? 19:27:47 iank_: That's how we do it internally. The backing size is the snapped pixel size scaled by the dpr. 19:28:13 iank_: So people can just use naive CSS px, which they like, and they still get sharp lines. 19:28:25 iank_: Can add a note suggesting that for impls. 19:28:36 smfr: Do you give the author enough info to reproduce the browser snapping behavior? 19:29:30 smfr: So when the brwoser pixel snaps, for us, we consult the rectangle origin - we'll snap both origin and width using some complex rules. 19:29:45 smfr: If the person using the paint worklet wants to snap in same way, that would be hard in a cross-browser way 19:29:55 iank_: I think we convinced ourselves internally that we didn't need to worry about th eorigin. 19:30:22 Because the origin is snapped and you know the number of snapped pixels you can match browser snapping 19:30:53 smfr: So say you want to paint a line halfway in the background, matching the browser behavior for a 50% width box with a border . 19:31:04 smfr: Matching the browser snapping behavior there is non-obvious. 19:31:23 smfr: Not saying we need to solve immediately, and probably would be hard to do and expose unsavory browser internals, but it should be an issue. 19:31:30 In the jsbin demo code I show how you'd convert to native size 19:31:37 iank_: Trying to read a big number-heavy thread right now for this. 19:32:21 smfr: could imagine a .snappedPoint/Rect() function, that you feed a point/rect and it returns a snapped one. 19:32:53 iank_: [reads out from teh thread, where a proposal matches what smfr just said] 19:33:01 iank_: So future level, but we should open an issue for that. 19:33:53 TabAtkins: So back to original proposal. 19:33:57 smfr: I like #3 19:34:05 dbaron: I don't think I understand all the details, but #3 seems to be okay. 19:34:16 TabAtkins: I don't either, but if you alter understand the details and disagree, we can revisit. 19:34:29 RESOLVED: Accept proposal #3 for pixel-snapping the backing store 19:34:45 RESOLVED: Add an issue for exposing the browser's snapping behavior via an API in a future level. 19:35:26 Topic: Check with folks that we are fine with PWGS going away 19:35:27 dbaron: We've talked aout having the backing store be a display list rather than a canvas. 19:35:32 TabAtkins: Yeah, we're already doing that. 19:36:07 Topic: Check with folks that we are fine with PWGS going away 19:36:13 github: https://github.com/w3c/css-houdini-drafts/issues/470 19:36:18 s/PWGS/PaintWorkletGlobalScope 19:36:46 iank_: In Worklets we say that the later specs should define the lifetime of the global scopes. 19:36:52 iank_: We didn'ta ctually do this for PaintWorklets. 19:37:09 iank_: Was out intention to be able to kill the global scopes, such as when a page is backgrounded, but not explicitly require that. 19:37:23 iank_: So proposal is to say you're allowed to kill them whenever, and give some examples of when UAs may decide to do it. 19:37:37 smfr: Is there any ability in worklets to store state between invocations? 19:37:44 iank_: Kinda, technically, but you shouldn't. 19:38:00 smfr: Maybe there should be an explicit API on worklets to stash state? 19:38:24 iank_: Problem is that if you have multiple threads, like servo's impl, do you expect that to be synchronized within a frame, or only visible next frame? 19:38:36 iank_: OUr handling is tha tin th econstructor you can do pre-work and pass things in. 19:39:08 iank_: We have non-deterministic selection of a global scope during painting, within a single frame, to discourage that behavior. 19:39:59 smfr: So I think we might want to solve that later. 19:40:01 TabAtkins: Yeah. 19:40:22