22:58:39 RRSAgent has joined #css 22:58:39 logging to https://www.w3.org/2022/04/06-css-irc 22:58:42 RRSAgent, make logs Public 22:58:43 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 22:59:02 present+ 22:59:05 ScribeNick: dael 23:00:16 present+ 23:00:44 smfr has joined #css 23:01:22 astearns: We'll wait a few minutes for a few more people to join 23:01:36 dholbert has joined #css 23:01:55 heycam|away has joined #css 23:03:04 present+ 23:03:12 present+ 23:03:20 astearns: Hopefully we'll get more people, but still seems light 23:03:26 khush has joined #css 23:03:29 alisonmaher has joined #css 23:03:54 present+ 23:04:04 present+ 23:04:05 present+ 23:04:08 oriol has joined #css 23:04:34 astearns: Since it's 4 after we should start. We'll see what we can get to with who is on the call 23:04:41 present+ 23:04:48 astearns: Announcement- We are going to have a physical TPAC with hybrid meetings 23:05:10 present+ 23:05:20 astearns: W3C management made the decision today they are going to hold the physical meeting. Working with A/V contractors for better cameras and mics for the event and to get good ventalation 23:05:32 astearns: Agenda-wise we'll skip item 4 23:05:49 present+ 23:05:52 (via phone) 23:05:57 astearns: Got a request to move item 6, but I don't see Chris yet. We'll move up to #3 unless someone else can take 23:06:04 vlad: go for it 23:06:10 astearns: Okay, let's put it as item 3 23:06:14 astearns: Other changes? 23:06:20 Topic: [css-contain-3] container :/ size 23:06:28 github: https://github.com/w3c/csswg-drafts/issues/7142 23:06:43 miriam: Since last week the spec is now up to date with current state of all the syntax changes 23:06:59 miriam: Only thing missing from ED is CSSOM resolutions. All syntax is up to date which should help with this convo 23:07:40 miriam: Sebastian pointed out in thread currently it allows the shorthand syntax for container which takes name and type...currently both are optional meaning it could be empty as well as original issue where if only a type have to start with a \ 23:07:53 miriam: Proposal here is we could require a container name in the shorthand 23:08:19 miriam: since we are right now container type of style is default on every element and heavily encourage names. If you just need a type you can use the longhand 23:08:26 miriam: That's the prop. Open for questions 23:08:48 astearns: If I recall correctly have plenty of places where shorthands cannot express every possible value longhands can do 23:09:02 miriam: And you could express it, but have to explicitly use 'none' in name of syntax 23:09:24 astearns: Prop: Require the container name in the shorthand syntax 23:09:26 miriam: Right 23:09:48 astearns: Any concerns? 23:09:55 astearns: Obj? 23:10:01 RESOLVED: Require the container name in the shorthand syntax 23:10:11 Topic: [css-content] Implementing content:none on elements is not web-compatible 23:10:19 github: https://github.com/w3c/csswg-drafts/issues/6503 23:11:04 dholbert: Basically we arrived at a point where wondering if content:none and normal should be 2 alues as computed style or if it should be alias 23:11:13 gtalbot has joined #css 23:11:15 dholbert: Seems everyone impl as 2 values. I think that's new information 23:11:23 dholbert: I think we want to stick with that unless reason to change 23:11:43 dholbert: Some subtilty around how none resolves to normal and browsers disagree a bit but I think it's mostly known bugs. 23:11:52 q+ 23:12:01 liam has joined #css 23:12:05 dholbert: I think this issue is no change, but not 100% sure. oriol has done more investigation and left useful comments. Curious his thoughts 23:12:46 oriol: The thing is that in Blink while content:noen and normal are diff computed values you cannot observe it from webpages. One resolves to the other. Possible this could change. When I impl none I didn't want to risk compat but I didn't try. 23:13:18 oriol: In WK there's a recent change from Jan where if set content:none gCS provices none. Otherside get normal. So get diff in WK and they didn't have to revert so seems it's web compat 23:13:35 oriol: I think FF impl and that's web exposed. So maybe can consider different and say resolve to themselves 23:13:41 ack florian 23:14:14 florian: I think historically the 2 main contexts were regular elements where content:none did nothing and before and after pseudo. marker forces difference where normal isn't empty but none is. 23:14:41 florian: From there I think should try for as distinct as we can. if we have compat issues we can do to the extent required but should keep separate by default 23:14:51 astearns: dholbert you suggested close no change? 23:15:31 dholbert: I had forgotten what oriol mentioned. I tend to think we should wait to see how the WK change survives. If they can keep as distinct in gCS that's the simpliest and I'm sure easy change for Gecko and Blink 23:15:55 dholbert: Potentially resolve in favor of that but might be premature since WK has recently shipped so I don't know how much exposure it has got 23:15:59 [seems reasonable to me] 23:16:05 astearns: Make no resolution and leave issue open for now? 23:16:36 dholbert: Yeah. Might re-agenda+ for another question. i think original request to make them compute to same I think have decided we don't need to. now question of if we can keep them distinct 23:16:40 s/before and after pseudo/before and after pseudo where "normal" was empty/ 23:16:42 dholbert: I can add a summary on the issue 23:16:52 astearns: Could resolve we're not going to have them compute to each other 23:17:01 dholbert: Happy on that since it matches existing impl 23:17:11 astearns: Prop: none does not compute to normal 23:17:22 astearns: Will leave issue open with summary from dholbert on what we need to see with time 23:17:24 astearns: Obj? 23:17:31 RESOLVED: none does not compute to normal 23:17:44 Topic: [css-images-4][css-overflow-3] How do object-overflow and object-view-box interact with overflow and overflow-clip-margin? 23:17:54 github: https://github.com/w3c/csswg-drafts/issues/7144 23:18:13 khushal: supporting css overflow and overflow clip 23:18:35 khushal: all replaced elements clip to content box by default. each except svg don't support overflow. When overflow is on svg it diverts 23:18:48 khushal: svg clips to content box and we don't support properties that make it scrollable 23:19:13 khushal: discussion on issue toward supporting overflow for all replaced elements sim to SVG. All values supported except those that make it scrollable 23:19:23 dlibby has joined #css 23:19:44 khushal: Ways in clipping diverges instead of doing the behavior in engine retail with UI css. Because it's in UI CSS devs can override 23:19:50 q+ 23:19:52 q+ 23:19:58 q- later 23:20:04 khushal: Want to mention that we brought up this question with overflow for replaced elements and talked about adding object-overflow to permit 23:20:28 khushal: In trying ti explain interaction with overflow we realized it was easier to do similar so we can remove this property from the spec 23:20:32 ack smfr 23:20:53 smfr: Sounds like in prop that you're allowing author to set overflow:visible on replaced element. Is that true? 23:21:09 khushal: If a website had overflow:visible today and defaulted to clip, it would now apply and cause visible 23:21:15 smfr: Seems like could be compat issue 23:21:49 khushal: Did come up that it might break backwards compat. Applying this prop on existing page wouldn't have worked and does now. Could try and get use counter for how often it's used to confirm compat isk is minimal 23:22:08 smfr: 2nd question is UA applys overflow:hidden. Does that allow scripts to progmattically scroll? 23:22:21 khushal: that's a way replaced have behaved differently. Script won't be able to 23:22:29 smfr: Sound UA stylesheet use overflow:clip? 23:22:31 khushal: Yes, you're right 23:22:42 smfr: Thought I saw issue on iframes. IS this proposed for that? 23:23:10 khushal: Another issue about which elements to limit this. Security reasons for iFrames so could make it !important so devs can't override for something like iframe 23:23:24 smfr: When a replaced element has overflow b/c overflow:visible, ink or layout? 23:23:27 khushal: ink overflow 23:23:35 smfr: Different to overflow on normal element, irght? 23:23:51 khushal: Right. Had discussed for object overflow that overflow for replaced should be considered ink 23:24:02 smfr: I think b/c list of issues I'm not a big fan, but want to hear others 23:24:03 ack florian 23:24:26 florian: I overlap with some of smfr. You said all values except scroll. but all of overflow other than visible and clip support scrolling 23:24:32 is it enough to support just overflow:clip & overflow:visible ? 23:25:01 florian: You talked about UA using overflow:clip, but it said in issue if author did overflow:scroll it was like hidden but hidden is scrollable. 23:25:04 what about overflow-x & overflow-y? 23:25:14 khushal: It should say clip. Anything that defines scroll maps to clip for replaced elements 23:25:39 astearns: And for values of overflow that are not clip or visible do we want them to work and make a scrollable thing or should they all function as overflow:clip 23:25:49 khushal: later. All overflow:clip for replaced elements 23:25:55 astearns: So they only get clip and visible 23:26:04 khushal: Right. Either clipped or visible 23:26:22 astearns: q on IRC about overflow-x and -y. If we set -x are things visible in -y? 23:26:31 GameMaker has joined #css 23:26:43 khushal: I think it's reasonable for overflow clip and visible to be different in x or y direction 23:26:48 present+ 23:27:02 khushal: I'm interp if you set overflow-x:clip and -y:visible it will clip in x and not y 23:27:08 I think part of the question is if you do overflow-y: scroll for example 23:27:10 florian: Yeah, Id on't see why different for this 23:27:14 smfr: Yeah, sounds okay 23:27:22 astearns: Other questions or concerns? 23:27:42 iank_: I think part or a question that needs to be answers if you set overflow-y:scroll what happens 23:27:42 q+ 23:27:49 iank_: There's various fixup today 23:28:19 florian: I guess either you first fixup the other dimension to be a scrolling value and then they both become clip or you coerce scrolling to slip immediately and other remains visible 23:28:22 ack chrishtr 23:28:42 chrishtr: 3rd alternative could be ignore values other than visible and clip. Can set but don't do anything. Compute to visible 23:29:04 chrishtr: May be less confusing than apply some behavior but not all. It would clip but not scroll and might not know why 23:29:26 astearns: Use counter suggested for overfow:isible. If we want that need a use counter for all the other values on replaced elements 23:29:46 chrishtr: Then alternative is we could go with new css property to avoid the concerns. Does seem behaviors are similar to svg 23:29:57 liam has joined #css 23:30:11 iank_: chrishtr if I understand correct and we just do visible and clip are there compat concerns since clip hasn't been out long 23:30:28 chrishtr: Good point. coerce hidden and scroll to visible then it's only sites with overflow clip 23:30:35 smfr: Isn't compat issue overflow:visible? 23:30:44 vmpstr: Right, it's the other side 23:30:44 my bad sorry. 23:30:53 smfr: And object:fit would leak pixels 23:31:04 khushal: I think it's something like object:position that would leak 23:31:28 smfr: a/r resize version of object:fit doesn't that cause bits of image to leak and if it's overflow:visible it adds ink overflow 23:31:50 khushal: right. If dev used overflow:visible and object-fit:cover they would get slipping now but overflow visible would start after this 23:32:40 florian: Back to visible in 1d and scroll in the other...I suspect doesn't matter for use case b/c you can get one behavior so for impl PoV seems easier to add conflict resolution as is. Visible in 1 and scroll in other leads to visible dimension hidden and now both behave as clip 23:32:40 Present+ 23:32:52 florian: Suggest to me we don't need to change style computation ass 23:32:57 s/ass/pass 23:33:32 khushal: 2 issues. 1 how to deal with overflow in x and y direction being different. If 1 d says visisble and other scroll we coerce to scroll and then clip 23:33:59 khushal: second is if it's set to visible in both directions where previously ignored and now visible. Is there a way to check or is thisa deal breaker 23:34:14 florian: Need use counter. If it's a lot it's a deal breaker but if it's rare maybe not a problem 23:34:25 smfr: Do we know if reset stylesheets set overflow:visible 23:34:33 ack fantasai 23:34:33 fantasai, you wanted to bring up Tab's point about content-edge vs padding-edge 23:34:33 iank_: I don't think it's common. Might be wrong 23:35:13 fantasai: I want to bring up opint from TabAtkins in thread. Overflow as a property currently clips to padding edge. Type of clipping we're looking at is content box. Replaced elements are special magic or do we need 2 properties? 23:35:31 https://github.com/w3c/csswg-drafts/issues/7188 23:35:42 fantasai: oriol mentioned 7188 with a use case for clipping replaced elements to padding box. Haven't looked in detail but woth considering before we decide to merge to 1 prop 23:36:24 wonder if it would be difficult to make the use counter check for overflow:visible only if there's ink overflow 23:36:27 khushal: Suggestion on issue for changing ref box is UI CSS rule. The discussion on issue was toward if start allowing overflow on replaced elements makes sense for overflow to work as well. Idea was default behavior is done with existing properties and devs can change 23:36:29 fantasai: Okay 23:36:29 that makes sense to me 23:36:43 astearns: [reads IRC from heycam] 23:37:18 astearns: I think use counter is of overflow:visible is set on replaced elements at all. if it is can eval us to see if introducting ink overflow is going to be unacceptable change 23:37:30 heycam: Just looking to see if can skip manual step to check influence 23:37:57 astearns: Before we collect use counter, say the use counter gives it as very rare. Would anyone continue to have a problem with this change? Is it worth the use counter? 23:38:10 smfr: Need use counter data b/c would be compat. If use counter data is okay I'm okay with it 23:38:50 astearns: use counter seems like the next step. Given the details about various values and which replaced elements this impacts and overflow-x and -y and writing all that down. Once we have use counter data we can come back 23:38:57 chrishtr: So accept pending use counter? 23:39:09 astearns: Resolution is collect data and wait to resolve until it's anayzed 23:39:19 fantasai: With a bias toward accepting if use counter says it's okay 23:39:35 chrishtr: I think reasonable in my opinion to accept change and if use counter says otherwise we revert 23:40:39 plinss: Quick point on use counter data. I think if use counter shows a lot of usage it's easy to say no. If use counter shows little usage that doesn't mean it's clear Could be a lot of data behind something like corporate firewalls. If use counter is extremely low fine, but if use count is marginal might be breaking more than we think 23:40:59 astearns: As far as accept change for now and revert I do like having spect ext as opposed to a summary 23:41:12 chrishtr: I would point out failure is showing more ink overflow which is not that bad 23:41:29 astearns: But could obscure content. Making things unreadbale that used to be readable is something we have to avoid 23:41:38 dino has joined #css 23:42:12 q+ 23:42:22 fantasai: Example from smfr about cover image that is visible outside of image suddenly could be significant data loss. If we do find singificant use. Currently doesn't have effect but if someone used overlay general could have effect 23:42:44 florian: I think use counters are in engine so could get behind corporate firewalls, but wouldn't get offweb like epub. 23:42:55 s/overlay genera/overly-general selectors/ 23:43:01 iank_: not necessarily. Depends on if org has opted into metrics collection. Orgs typically do opt out 23:43:13 s/image suddenly/img element suddenly/ 23:43:44 ack smfr 23:43:47 iank_: other point is we do have some usecounter blindness. I don't think will be case for this. Corps tend to use frameworks so if we see something on public likely to see it in the blindspot as well. Fair bit of correlation for these rendering changes 23:43:52 +1 to iank, unlikely to find this problem on intranets if open web doesn't show the problem 23:44:06 smfr: I think might be first time we allow contents to overlap border. Makes me wonder if we spec the paint order 23:44:09 fantasai: Same as other elements 23:44:15 smfr: So paint on top of borders? 23:44:29 khushal: Was going to add sg allows overflow today and I think they draw on top of border 23:44:30 smfr: Okay 23:44:38 present+ 23:44:43 iank_: So replaced elements paint in content phase? 23:45:01 astearns: We have spec a content phase in painting? 23:45:09 CSS2 appendix Z 23:45:30 khushal: Another question - earlier resolved having new behavior thought object overflow which is new prop where if set to visible only contents of replaced element can overflow. 23:45:33 s/Z/E/ 23:45:53 https://www.w3.org/TR/2011/REC-CSS2-20110607/zindex.html#q23.0 23:46:02 The painting order of border vs replaced content is already defined 23:46:03 khushal: If we do see use counter usage is high enough that change is risky, would it be good to continue using object overflow and come back to group on how to handle if visible is defined? 23:46:31 astearns: Makes sense to me. If what discussed today dones't work we figure out how object overflow would work as a sep property for this use case 23:47:05 khushal: Issue was if object-overflow as defined in spec exists how does overflow interact with replaced and my take away is it continues as is. We can come back for more concrete resolution 23:47:17 astearns: So adding the path of using overflow on replaced elements in a draft 23:47:32 fantasai: Add and mark as tentative pending data with a link to the issue 23:47:41 astearns: Remove object overflow or put an issue on that? 23:48:00 fantasai: I would go with remove from spec and mentioning in issue that if we can't go in direction we're trying we may reconsider 23:48:15 astearns: Obj to Add this path forward to the spec with a note linking back to this issue 23:48:26 RESOLVED: Add this path forward to the spec with a note linking back to this issue 23:48:52 Topic: [css-text] Syntax for percentage-of-width-of-space for 'word-spacing' 23:49:16 Topic: [css-ui] Should the cursor property support image-set()? 23:49:24 github: https://github.com/w3c/csswg-drafts/issues/5831 23:49:32 florian: Has always supported url production to point to image 23:49:48 florian: Since css ui 3 spec says it's allowed to support image production to do image sets, gradients, etc 23:50:00 florian: It's as a may b/c as of time for css ui 3 no one did it 23:50:27 florian: Since then we have 1 shipping and 1 experimental of more than urls but supporting image-set function as long as image-set only contains links to urls. 23:51:13 florian: one poss is we keep spec as is. Other is we explicitly call out now that there's 2 impl is you can do url and this version and may the rest. 3rd is switch entire spec to using image production and encourage browsers to fill in what's missing 23:51:20 astearns: Opinions? 23:52:12 florian: I'm inclined to spec what is impl. We were refaining b/c no one had done it. Still not all impl but since we have more spec that would be nice. Can't just use imace-set production b/c no one does gradients. 23:52:22 florian: Since we have multiple implementations we should spec it 23:52:35 astearns: I think fine to spec what's impl. I assume there's no tests in wpt 23:52:48 florian: I haven't checked. As a spec writer Id idn't create 23:53:01 iank_: This just coveres image-set. Also the image function. Was that impl? 23:53:16 florian: Don't think so. Only seen image-set with URLs. spec allows more but I don't think anyone has impl 23:53:38 astearns: Prop: Add a URL param-specific version of image-set function to the cursor property 23:53:42 astearns: Obj? 23:53:59 RESOLVED: Add a URL parameter-specific version of image-set function to the cursor property 23:54:15 astearns: Please do add tests 23:54:17 florian: Sure 23:54:45 Topic: [css-cascade] Should 'revert' really treat animation origin as author origin? 23:54:52 github: https://github.com/w3c/csswg-drafts/issues/7083 23:54:59 https://github.com/w3c/csswg-drafts/issues/7083#issuecomment-1083631261 23:55:06 astearns: Suggested resolution at the end from TabAtkins 23:55:55 fantasai: We suggest for revert-layer no change. There are use cases and how set is most natural way. This issues is around revert. We suggest close no change b/c this is spec and impl. If people thik treat same as revert-layer that is reasonable behavior; main problem is it's a change 23:56:12 astearns: Prop: Close no change 23:56:18 +1 close no change 23:56:28 fantasai: Yeah. unless someone feels significantly better to behave same as revert-layer 23:57:12 oriol: Initially I filed this b/c impl that way had some performance cost in WK and in Blink there was a comment saying it disabled optimization. In discussion of issue turned out changing wouldn't improve perf in Blink b/c disabled due to em units. 23:57:23 oriol: So I think changing would not improve perf so we can close no change 23:57:35 astearns: dbaron you commented. Is this okay? 23:57:46 no objections 23:57:56 astearns: objections to Close no change 23:58:05 RESOLVED: Close no change 23:58:20 Topic: [css-logical][css-cascade] revert/revert-layer with logical properties 23:58:34 github: https://github.com/w3c/csswg-drafts/issues/7054 23:58:40 fantasai: Prop: Spec what's implemented 23:58:52 astearns: Is that the whole things? 23:59:16 oriol: The thing is what happens if you have mix of logicial and physical and set one to revert-layer do you roll back to same ignoring pairing property? 00:00:00 oriol: I looked at impl and all agree that first they run the escape and when have final writing mode turn them phsyical ones. Logical and physical properties convert into same mapping. Once resolved you revert into resolved property 00:00:22 oriol: If you have margin-left and revert-layer and previously you set margin-start you revert to that. 00:00:29 oriol: Prop is revert after resolving the properties 00:00:54 fantasai: Makes sense to user. revert is rolling back value on this property to what would have been if UA stylesheet didn't exist and this has that effect 00:00:58 astearns: Thanks oriol 00:01:06 astearns: Obj to specify what browsers currently do 00:01:06 s/UA/author/ 00:01:13 RESOLVED: specify what browsers currently do 00:01:15 topic: end 00:01:24 astearns: Thanks everyone for calling in and we'll talk next week 00:06:37 Hmmm. css-image-4 defines image-set() as "no change from [css3-images]." But level 3 doesn't define it… 00:15:06 ha. css-images-4 does define image-set(), in the ED, but not on the TR version, which is 5 years out of date 00:16:02 fantasai, TabAtkins, leaverou do you think you could do something about ^ in the not-too-distant future? 00:24:16 oriol has joined #css 01:02:23 oriol has joined #css 01:52:07 dauwhe has joined #css 02:30:09 Zakim has left #css 03:10:20 plh has joined #css 05:05:24 dholbert has joined #css 06:49:26 I have made the request to generate https://www.w3.org/2022/04/06-css-minutes.html tantek 06:49:52 I'm logging. I don't understand 'make minutes public', tantek. Try /msg RRSAgent help 07:10:11 plh has joined #css 08:39:52 projector has joined #css 08:40:18 shans has joined #css 09:21:33 plh has joined #css 11:15:17 dauwhe has joined #css 11:50:46 dauwhe has joined #css 12:58:00 dauwhe has joined #css 14:10:03 tantek has joined #css