16:57:19 RRSAgent has joined #css 16:57:19 logging to https://www.w3.org/2021/01/20-css-irc 16:57:21 RRSAgent, make logs Public 16:57:22 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:58:40 present+ 16:58:43 ScribeNick: dael 16:59:11 fremy has joined #css 16:59:23 sanketj has joined #css 16:59:26 present+ 16:59:32 present+ 16:59:34 present+ 16:59:36 present+ 16:59:45 sounds good Alan 16:59:59 jfkthame has joined #css 17:00:07 present+ 17:00:15 present+ 17:00:21 astearns: Thanks to everyone for calling in on time. We'll wait a couple more minutes to get the list of people online to fill out 17:00:23 present+ 17:00:47 present+ 17:01:00 present+ 17:01:04 alisonmaher has joined #css 17:01:09 present+ 17:01:30 dlibby has joined #css 17:01:42 bkardell_ has joined #css 17:02:15 present+ 17:02:22 present+ 17:02:44 drousso has joined #css 17:02:54 astearns: Let's start. Any changes to the agenda? 17:02:56 present+ 17:03:01 present+ 17:03:01 Topic: [css-color-4] What serialization should be used when using color(lab ...) syntax to specify a lab color? 17:03:10 github: https://github.com/w3c/csswg-drafts/issues/5825 17:03:26 present+ 17:03:42 chris: I added some comments before the call to clarify the options. two questions, what to do for lab and lch and what do for extended precesion 17:03:52 una has joined #css 17:04:21 chris: Spec says if you use lab and lch lch serializes to lab. But if you do color (lab) it serielizes to color. Suggested is all three serialize to lab. I'm willing but wanted feedback to if it's an improvement 17:04:44 leaverou: On one hand have the rule values serialize to shortest form. Might be helpful for authors if number of formats returned is fewer than ones spec. 17:04:45 We shouldn't change the specified function like this - color() should remain color() 17:05:07 leaverou: I can see arguments for serializing anything that doesn't need backwards compat as color 17:05:15 present+ 17:05:27 astearns: TabAtkins mentioned something on IRC. I believe color emains color and it's only when serialized with a bare lch or lab 17:05:28 present+ 17:05:29 present+ 17:05:30 chris: correct 17:05:48 Tab, not a proposal 17:05:50 astearns: I can see argument for shortest that if your color happens to have a lab we could serialize to that 17:06:04 TabAtkins: Confused. First post on thread asks for that. Color with lab color space to serialize to lab function 17:06:16 TabAtkins: My assumption is lab should be used when refer to color of lab space 17:06:35 chris: I hadn't read as meaning that. I read as unclear and said spec says what to do. Then it drifted to should we harmonize 17:07:09 oriol has joined #css 17:07:12 TabAtkins: WE shoudln't change function in a major way. They should get back out what they put in. Color function has a lot more functionality than individual color functions. Would be strange to lose that. In TypedOM it would serialize to form w/o fallbacks 17:07:37 chris: Agree. If you look at my A and B options I don't propose do away. A is continue as is. B is serialize as color(lab) 17:07:42 chris: Clearer? 17:07:43 TabAtkins: Yes 17:07:57 smfr has joined #css 17:08:07 TabAtkins: Taking that opinion we shouldn't do B because unexpected. I think maybe not A b/c I find it weird 17:08:08 IanPouncey has joined #css 17:08:18 chris: When discussed previously seems to be what people want. 17:08:21 TabAtkins: That's true 17:08:39 present+ 17:08:43 i like option B as well 17:08:50 present+ 17:09:15 plinss: I agree with TabAtkins it's strange if functions changed. If we get to world with typed om where it serliazes as the same function the author created. Will make a world of hurt if functions change, esp if inconsistent 17:09:20 leaverou: hsl() also serializes as rgb(), so lch serializing as lab is the same 17:09:54 astearns: argyle you mentioned you like changing in IRC? 17:10:31 Note that the TypedOM will give trivial conversions to whatever function form you want. 17:10:49 argyle: I like it. I am acknlowedging hsl serializes to rgb. It is the common space. Most common is where tried to serialize. I like in option b you can write in either syntax and get the superset. You get the higher order. It seems like it upgrades colors not downgrade or transfer. 17:11:30 of the two I like B better too, I think - but it's really hard to say without actually using it and living with it for a while :-p 17:11:38 chris: I see a comment the typed om gives color conversion functions. That's not clear to me. I thought that was case but I think I see it gives a null string. Discussion on twitter it should be separate spec. 17:11:48 chris: I believe in future there will be color conversion functions, though. 17:12:01 chris: That's broader. I could type hsl and get lab. That's much broader. 17:12:02 That Twitter discussion is not reflective of the current spec or my continued intention, fwiw. 17:12:43 leaverou: Even though typed om helps b/c authors don't parse manually, they still have to handle different formats b/c closely tied. If lab serializes as color(lab) it's unclear to me what typed om class will corrispond. serialization or specified? 17:13:03 TabAtkins: typed om reifies to the class function it would serialize to. spec you get what you put in and computed it's rules for conversion 17:13:33 TabAtkins: Another reason not to change into color is class corrispondant to color is more difficult to work with than lab or lch class. If people using anything else would prefer to give easiest to work with. 17:13:48 What TabAtkins just said makes a lot of sense to me 17:13:50 leaverou: The more different classes and author could expect they need to handle. If they don't know color thye have to handle out 17:13:56 TabAtkins: Can convert to any form they want 17:14:12 astearns: And if they return color they would still need to deal with first param with all the variations 17:14:28 chris: Hearing arguments on both sides but no clear consensus. 17:14:34 smfr: Can you summarize? 17:14:43 options: https://github.com/w3c/csswg-drafts/issues/5825#issuecomment-763722847 17:14:53 chris: The ones in GH. Option A is serialize lab and lch with shortest form which is lab. 17:15:02 chris: Option B i slbal and lch as color(lab) 17:15:21 I was worried about that because Sam proposed it in the original post. ^_^ 17:15:21 chris: TabAtkins was an option c that serializes color(labl) as lab. I only see objections to that. 17:15:37 s/was an option/was worred about an option/ 17:15:56 smfr: Have to consider along with serliazation of rgba and srgb. If you look at comment from 3 days ago from Sam he suggests [reads] and lab is odd one out 17:16:12 smfr: One of the considerations is if you used color for srgb you want to round trip precision. 17:16:48 chris: Agree in general. color 3 required round to 8 bits. Currently min is 8 bits on both. Happy to increase for color which might make sense. I don't know how much existing code exists elsewhere but none for color form. 17:16:58 chris: It's always been 0 to 1 so you had precision 17:17:10 leaverou: If this is higher precision we could consider opt in to other handling 17:17:12 My preferred option: serialize lab() to lab(), lch() to lch(), and color(anything) to color(). I'd accept serializing lch() to lab() if necessary, but would prefer to avoid that. 17:17:26 smfr: One approach would be consider rgh/hsl as legacy and all newer colors serialize with color function 17:17:29 chris: I can see that as clear 17:17:38 leaverou: TabAtkins would you argue for changing how hsl serializes? 17:17:44 TabAtkins: Long past impossible at this point 17:17:53 TabAtkins: In an ideal world yes, but the compat is out of our hands 17:18:19 chris: I quite like smfr suggestion. Color rgb serialzes as itself. Therefore lab serializes as color(lab). 17:18:30 smfr: That falls out. Can see it's annoying for authors 17:18:38 chris: That's the case in both suggestions. We could change that 17:18:49 TabAtkins: Only reaon lch serializes to lab is analogy? 17:18:50 chris: Yes 17:19:17 smfr: My thought was color function is used to describe the color space and therefore lab and lch are lumpped together. Maybe not great for serialization 17:19:33 chris: Little legacy, but ongoing impl. Time to change it is now. In 6 months it's too late to change 17:20:06 TabAtkins: b/c you came in later, I'm moderatly against normalizing to color function because typed om form is a lot more complicated than individual color functions. I would prefer to give the simplier forms if they put them in. 17:20:09 smfr: Reasonable 17:20:45 Omitting the srgb keyword is stadnard "shortest form serialization" stuff, I'm fine with that. 17:21:07 chris: Since talking about sRGB. The first param is the color space and it defaults to srgb. Two ways to default it. If code is looking at this in serialized forms maybe it's cleaner if it always has an explicit color space. I can argue either way. Shortest serializable or explicit color space 17:21:25 smfr: Question, if you spec rgba with % which means >8 bit. If that serializes do you maintain precision? 17:21:43 Proposal: the sRGB functions all serialize to rgb() (partially legacy, and partially consistency). All other functions serialize to themselves. 17:21:57 chris: Currently, in color 4 they are no longer int. You can do 137.5 and it's supposed to go to highest possible with a min of 8 bits. Most impl seems ot truncate 17:22:01 TabAtkins: hwb() too? 17:22:10 smfr: IN WK we use color function to trigger higher precision storage. 17:22:17 TabAtkins: it's an sRGB function, but no legacy implications 17:22:29 chris: Lots of int precision on the web. I've read people worry about blowing up dom if it's bigger 17:22:30 leaverou: Yes, that's the "partially consistency" I mentioned. ^_^ 17:23:01 astearns: TabAtkins has a proposal to have all legacy rgb serialize to rgb and all new serliaze to themselves. Sounds like people are okay with new functions serialize to themselves 17:23:10 chris: That would amount to option A. 17:23:13 astearns: Option A except lch serializes to lch 17:23:14 But I'm also fine with just "the current legacy functions serialize to rgb(), everything else to itself" 17:23:16 chris: Okay 17:23:31 leaverou: If we do srgb to itself it also makes sense to keep lab as itself. It's same thing, really 17:23:33 chris: Right 17:23:49 astearns: One person I haven't heard from in a bit is plinss. Would you be okay with this? 17:24:02 plinss: That's what I argued for. I don't believe functions should change to other functions 17:24:10 👍🏻 17:24:12 astearns: Prop: All new color functions serialize to themselves 17:24:18 present+ 17:24:20 RESOLVED: All new color functions serialize to themselves 17:24:43 tantek has joined #css 17:24:46 color(srgb 1 0 0) should seiralize to color(1 0 0), per shortest-serialization 17:24:54 chris: Follow up on that. If I say color(srgb) it's same as color(rgb) if i just give rgb. Should they both go to the same form and if so which? 17:25:03 astearns: TabAtkins says shortest omitting defaults 17:25:05 regrets+ 17:25:10 +1 lea 17:25:11 leaverou: Not sure it's good to have this form without a color space 17:25:17 +1 lea 17:25:20 chris: I see both arguments. Strong opinions? 17:25:29 +1 lea 17:25:33 smfr: I would prefer srgb as explicit 17:25:51 I'd be fine with removing the optionality of the keyword 17:25:52 plinss: We're talking about the color function optionally losing srgb? 17:25:56 chris: Making it mandatory 17:26:03 plinss: When it serializes out you don't have it 17:26:14 chris: That's one option. We're talking if you want srgb you have to say so 17:26:21 leaverou: And I see agreement for that in irc 17:26:24 +1 17:26:26 plinss: Gotcha. no strong opinion 17:26:33 chris: I think it's consistent with your argument plinss 17:26:53 plinss: It's fine. If color space is optional in function I'm fine if it serializes without, but also fine with it not optional 17:27:03 leaverou: Can make optional in the future. If we start optional we cna't change 17:27:08 chris: I'm fine removing the optionality 17:27:19 What’s the reason Zakim pinged me? 17:27:20 astearns: Make the first param in the color funciton, the color space, required 17:27:29 RESOLVED: Make the first param in the color function, the color space, required 17:27:33 chris: I can edit this in 17:27:41 astearns: Something about precision? 17:27:52 Just clarifying - does the first resolution apply to hwb() serializing as itself? 17:28:07 chris: Yes, if you use srgb you expect higher precision. Min is 8 bits right now. I'd like to increase. P3 min is 10 bits per component. COuld make same 17:28:36 astearns: Prop: Hvae the minimum precision raised to 10 bits 17:28:43 RESOLVED: Have the minimum precision raised to 10 bits 17:28:57 chris: hwb is same as hsl where it comes out as rgb or rgba 17:28:57 I'm fine either way fwiw 17:29:10 non-sRGB functions 17:29:22 astearns: Resolution about all color functions is ammended to different way of expressing rgb? 17:29:29 chris: I see hwb as same as hsl 17:29:43 astearns: Amended resoltuion is now non-rgb color functions serialize to themselves 17:29:43 s/I see hwb as same as hsl/I see hwb as similar to hsl/ 17:29:44 chris: Yes 17:30:00 astearns: Is that first part of issue or all covered? 17:30:05 chris: Covered that. I think I'm good 17:30:53 leaverou: If color srgb has higher precision and difference between that and srgb is maintained can the colors opt into better interpolation? Right now we have backwards compat but doing it in lch is far better. If they don't have backwards compat concerns maybe they can opt into better 17:30:56 well said Lea! 17:31:09 astearns: leaverou can I ask you to open a separate issue? That way people can weigh in on GH 17:31:18 Topic: [css-pseudo] Who is currently using CSSPseudoElement and what events can target them? 17:31:24 github: https://github.com/w3c/csswg-drafts/issues/4619 17:32:08 florian: This is more of a request for information. CSS Pseudol Element class exists and is an event target, but it's not clear what API uses and what events it recieves. When the issue was raised I think intent was figure out who should we talk to when we refine events on Pseudos 17:32:13 q+ 17:32:32 florian: This has been sitting in GH for a while without feedback. This is a louder call to figure out who is the crowd interested 17:32:53 emilio: I think main consumer is web animations. like css animations that target css pseudo elements. Not aware of other consumers. 17:33:18 florian: I'm a little fuzzy on this b/c decision to stop using pseudo elements as a class on animation, but pointed out there still is. But that would be the group 17:33:41 astearns: One of the reasons we pushed to have css pseduo element historically is we thought regions could be made out of pseudo elements but that's moot at this point 17:33:56 florian: I see reasons why it's useful, but before drafting new things it would be good to know what's done 17:34:03 gregwhitworth: Are yous aying you can't animation pseudo elements? 17:34:31 florian: No, but I believe API shape of animations has changed and it's no longer done through pseudol element class set up in pseudos 4. I could be wrong. A bit out of my area 17:34:50 astearns: Anyone else with a known dependency or use case for css pseudo element as an event target? 17:35:04 aja has joined #css 17:35:10 astearns: So it may be down to whatever use case web animations might have? 17:35:19 florian: Plus what sanketj and I want to add 17:35:50 sanketj: Does anyone use pseudo element not as an event target? Web animation sis only thing I could tell which has since been dropped. I didn't find any users of pseudo element at all 17:36:09 florian: I have use cases, but not existing usage 17:36:38 iank_: I think this has been one of the things that's an obvious gap on api side. Nice to get target if it's exposed but not high priority so hasn't been impl 17:37:02 sanketj: Should we try to remove css pseudo element and come at it again in a different way? Not sure the process 17:37:29 astearns: If there are no consumers and little impl interest it's plausable to remove it and retain intent of fixing the hole in the API. Need motivating use cases to spur impl interest 17:38:11 florian: I don't know. If we suspect API shape is wrong maybe remove. but I believe there are use cases that we're slowly getting ot. Having a place where we accumulate our way to useful thing it would be good. If we start by deleting it doesn't speed up getting there 17:38:16 astearns: Fair point 17:38:24 astearns: sanketj do you have an argument for deletion? 17:39:07 sanketj: Not specifically. originally looked around highlight api and there are not highlight events. pseudo element being an event target prompted us to look. I don't think I have a way to have it useful in highlight, but I don't have a strong reason to delete or keep 17:39:28 florian: I have other use cases to look into in the near future. I'd like to keep working. For now it's hear so no rush to delete 17:39:55 iank_: One thing to keep in mind is only before and after pseudo elements make sense with this API. Perhaps merging in that this might change is a path 17:40:14 sanketj: Yes, only tree abiding was designed originally I think. I don't believe it works for range based 17:40:25 iank_: Yeah, for example doesn't make sense for ::first-line 17:40:59 fantasai: Would work for any, but only defined for tree abiding. Every pseudo element has originating element. If you highlight it will cross multiple pseudo elements as you cross multiple elements 17:41:18 iank_: In related to geometry apis and event propegation the tree abiding ones are much siplier 17:41:42 florian: I'd suggest slap a warning across this area of the spec saying don't rush to impl but if you have use cases or problems bring forward 17:41:50 sorry sanketj :) 17:42:16 thanks for covering it :) 17:42:20 astearns: As a way forward put a warning on this part of the spec that this is early and needs fleshing out. Do we close this issue with a reoslution to have a warning or do we need to dive into web animations usage more 17:42:34 florian: Since we're not resolving to delete it I don't think we need the explaination urgently 17:42:44 astearns: Prop: Add a warning to the section and close this issue 17:42:47 astearns: Objecitons? 17:42:57 RESOLVED: Add a warning to the section and close this issue but continue work 17:43:05 Topic: should CSSPseudoElement have a pseudo() method? Would it be worth considering having two separate properties, Element element and Element|CSSPseudoElement parent 17:43:12 github: https://github.com/w3c/csswg-drafts/issues/3836#issuecomment-502344378 17:43:43 florian: Because it is now possible to have pseudo attached to pseudos. In addition to element class having pseudo pseudo element class has apseudo. 17:44:08 florian: Another question, pseduo element class has an element method that returns originating element. Pseudo on a pseudo do you want originating or parent pseduo? 17:44:43 florian: Original thought is return the parent. Later proposed we should have both. Element returns originating element, but also have a parent method that returns parent pseudo if there is one and if there isn't returns originating 17:44:52 florian: Got thumbs up so proposal is accept 17:45:01 astearns: If it's not nested parent returns nothing? 17:45:06 florian: Returns same as element 17:45:17 astearns: First is element ancestor and second is immediatate parent 17:45:19 florian: Yes 17:45:56 fantasai: One thought, if we extend to non-tree-abiding parent is not quite the right word. If you select first-letter element parent is the first line or some weird nesting. We could call it parent and say these things are special 17:46:11 florian: It would be walking up hierarchy step by step. Just need to define weird cases 17:46:34 fantasai: As long as people say it can be repurposed to not quite a parent it's fine to me. Just wanted to point out it's going to be a bit weird 17:46:38 astearns: Other opinions? 17:46:50 astearns: Hearing people in favor 17:47:20 astearns: Prop: Use the existing parent function in css pseudo element as returning fifrst element ancestor and add an immediate parent that could poss return a pseudo element 17:47:35 RESOLVED: Use the existing parent function in css pseudo element as returning firrst element ancestor and add an immediate parent that could possibly return a pseudo element 17:47:42 Topic: Link "Applies to", "Canonical order" in propdef tables 17:47:50 github: https://github.com/w3c/csswg-drafts/issues/3827#issuecomment-759849067 17:48:04 https://drafts.csswg.org/css-cascade-4/#changes 17:48:21 fantasai: Have some text we can link to. Cascade 4 has a nice section of it. Needs to be republished as a WD. Changes here ^ one issue still being discussed so may not be able to publish today 17:48:39 fantasai: Other major changes we did is define processing of elements not in tree and define term property 17:49:04 fantasai: Other problem is that canonical order is only defined in cssom editors draft. That's far ahead of tr and it is behind on edits. 17:49:29 fantasai: In order to crosslink we need to republish cssom. But I don't know state of draft and if it should be published or needs more edits. 17:49:41 fantasai: We can't make fix to propdef tables as long as spec is out of date 17:49:57 astearns: emilio do you have an idea of if we could publish cssom draft as is? 17:50:10 emilio: I think we could publish. A few fixes i'd like but they interact with HTML 17:50:23 astearns: Could resolve to publish a new WD of cssom as-is? 17:50:39 TabAtkins: One edit that might be good to pull in which is remove color serialization so we can defer to color 4 17:50:57 chris: I have removed it. But there's a related issue where it keeps linking to color 3 and I want to stop it. But the edits are in 17:51:15 astearns: Prop: Fix the draft of cssom so it points to color 4 and then publish 17:51:20 astearns: Objections? 17:51:24 +1 17:51:28 RESOLVED: Fix the draft of cssom so it points to color 4 and then publish 17:51:37 astearns: What do we want to do on cascade? 17:52:06 https://drafts.csswg.org/css-cascade-4/#changes 17:52:12 fantasai: Cascade has an open issue on same-origin check for the quirks mode. After that we should be ready to publish. That should be most of the outstanding edits. Changes list is here^ 17:52:19 fantasai: We made 5 or 6 changes 17:52:25 astearns: Resolving that one issue will take what? 17:52:30 fantasai: TabAtkins would know 17:52:43 TabAtkins: I'd have to review to see if Ana responded 17:52:46 fantasai: He did 17:52:53 s/Ana/Anne/ 17:53:02 TabAtkins: Is he saying I'm right? If yes it's easy 17:53:02 https://github.com/w3c/csswg-drafts/issues/4838#issuecomment-762052244 17:53:14 fantasai: I don't know. There's the comment ^ 17:53:28 fantasai: Do we want to take a resoltuion to publish once you and Anne decide wording 17:53:41 astearns: Prop: Publish cascade after resoltuion of 4838 17:53:50 RESOLVED: Publish cascade after resolution of 4838 17:54:17 astearns: Anything else on this? 17:54:27 Topic: [css-overflow-3] Clarify when overflow-clip-margin has an effect 17:54:36 github: https://github.com/w3c/csswg-drafts/issues/5800 17:54:46 astearns: Let's try 17:55:10 vmpstr: Clarifying a sentence in overflow that says [reads]. Clarifying what "this property" refers to 17:55:23 vmpstr: Paint containment clips, would like overflow:clip to extend paint containment 17:55:37 florian: Yes, contain:paint applys. Poorly worded, editor will make it better 17:55:48 astearns: Will handle by making it explicit contain:paint applies? 17:56:03 florian: Not sure how I'll rephrase but the answer is it applies and we'll fix the sentence 17:56:08 vmpstr: Maybe remove the sentence? 17:56:24 florian: Possibly. It's 3am so I'm not awake enough to draft the sentence on the fly. 17:56:47 fantasai: Can't remove the sentence b/c it doesn't apply to most elements. Some clipping effects it applies and some where it doesn't 17:57:04 Topic: [css-sizing-4] Expected size of replaced element with aspect-ratio but width/height auto 17:57:09 github: https://github.com/w3c/csswg-drafts/issues/5721 17:57:26 dauwhe has joined #css 17:57:45 fantasai: cbiesinger brough up case of image with intrinisic size. Set a-r that's not that of the image. Previously not possible. Question is what is this supposed to do? Have a jpeg that's 100x100, set a-r as 1-1. What does it render 17:58:12 fantasai: No clear answers. leaverou made a poll with inconclusive results. We need an answer. Looking for opinions and ideas about why it should be an answer 17:59:09 TabAtkins: I have a preferred answer here. The a-r property by virtue of it being explicit it should be honored and then we round sizing as normal. Use ratio determining, take natural size, process trhough spec a-r and use it. Added a comment on GH 17:59:38 TabAtkins: In the jpeg example of 1x1 a-r we set width to natural width and then we make it square. You asked for it to be square so I think people would expect that 17:59:48 LGTM too 17:59:49 iank_: I agree with TabAtkins' analysis 17:59:55 wfm 18:00:19 astearns: Some consensus. Might be easiest to get a good answer by declaring an answer and use the get an answer by saying something wrong and getting people to say why wrong 18:00:33 astearns: Prop: Take TabAtkins's last comment in GH and resolve on that 18:00:40 cbiesinger: Takes writing mode into account? 18:00:56 TabAtkins: Yeah, ratio determining for axis takes writing mode into account 18:01:09 RESOLVED: Take TabAtkins's last comment in GH 18:01:36 astearns: Thank you everybody 18:01:39 Topic: end 18:02:18 zakim, end meeting 18:02:18 As of this point the attendees have been dael, argyle, cbiesinger, vmpstr, sanketj, fremy, Morgan, TYLin, gregwhitworth, miriam, alisonmaher, dlibby, bkardell_, drousso, 18:02:21 ... rachelandrew, plinss, dholbert, una, jfkthame, smfr, oriol, emilio 18:02:21 RRSAgent, please draft minutes v2 18:02:21 I have made the request to generate https://www.w3.org/2021/01/20-css-minutes.html Zakim 18:02:23 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 18:02:27 Zakim has left #css 18:07:37 OK Tab, thanks! 18:10:43 technically the inauguration is already over, I think 18:59:29 gtalbot has joined #css 19:00:37 gtalbot has left #css 20:36:43 Morgan has joined #css 22:21:49 atrigent_ has joined #css 22:33:24 atrigent__ has joined #css 23:57:40 dauwhe has joined #css