23:51:02 RRSAgent has joined #css 23:51:02 logging to https://www.w3.org/2020/12/02-css-irc 23:51:04 RRSAgent, make logs Public 23:51:05 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 23:51:47 dael has joined #css 23:53:54 present+ Florian 23:53:59 present+ 23:58:43 present+ 23:58:47 scribenick: dael 23:59:42 jarhar has joined #css 00:00:22 vmpstr has joined #css 00:00:34 Rossen: Hi everyone! We'll get going in a couple minutes 00:00:36 present+ 00:00:45 present+ 00:01:03 smfr has joined #css 00:01:12 present+ 00:01:18 dlibby has joined #css 00:01:36 present+ 00:01:37 present+ 00:01:40 present+ 00:01:48 present+ 00:01:58 Rossen_: Almost ready to get going. There's still people joining so let's give them another minute 00:02:01 present+ 00:02:06 + 00:02:21 alisonmaher has joined #css 00:02:22 Rossen_: It's a couple minutes past the hour 00:02:26 Rossen_: We should get going 00:02:26 present+ 00:02:30 present+ 00:02:38 Rossen_: as usual I wanted to ask if folks had additional agenda items or changes 00:03:15 present+ 00:03:16 present+ 00:03:17 Rossen_: Only extra I have, and we'll discuss next week as well, it's time to start planning our next F2F/virtual meeting 00:03:24 Oh, I have an item: 00:03:29 I'm preparing css-text-3 for CR 00:03:38 Huijing has joined #css 00:03:38 if anyone has any concerns with that 00:03:40 present+ 00:03:43 or wants to do a last review or anything... 00:03:46 present+ 00:03:47 Rossen_: We usually have more people showing up to regular call time so we'll decide there, but start thinking about times and drop a link to the private list 00:03:51 just a heads up, I'll be requesting a transition soon 00:04:02 present+ 00:04:05 Rossen_: I see fantasai adding something 00:04:14 Rossen_: Are you on and can you talk to us quickly? 00:04:27 Rossen_: I take it mostly that's an FYI. I'm not hearing if you're talking 00:04:35 Topic: [css-contain-2] Proposal: content-visibility: hidden-matchable 00:04:40 bkardell_ has joined #css 00:04:48 github: https://github.com/w3c/csswg-drafts/issues/5595 00:05:05 present+ 00:05:08 jarhar: Couple of things I'd like to resolve quickly 00:05:28 jarhar: Like to resolve 1) do we have agreement it's useful to have a way to spec hidden content that's searchable in general 00:06:10 jarhar: 2) Seems like in previous discussions we've talked what algos and things the searching should be exposed to. I'd like to get resolution that this feature should work for all methods of seatching UA provides and all web APIs for searching 00:06:27 jarhar: If we get those then we can discuss if content-visibility:hidden-matchable is right 00:06:36 jarhar: Issues with in general having this feature? 00:06:39 q+ 00:07:32 Rossen_: Question here, we're talking about searching and a lot of that doesn't lend naturally to css. Meta question for searching is if content presented visually is also available in the DOM so it can be indexed and searched 00:07:58 Rossen_: And how does that relate to assistive technologies and other layers using that approach. Those are the layers to hit before answering if searchable. Is that fiar? 00:08:30 jarhar: Was question about a11y? There has been discussion on GH about a11y. Earlier Chris mentioned previous discussion about how a11y tree shows content-visibility auto or hidden content 00:09:07 Rossen_: My question was if this hidden-matchable is presented to a11y it sounds like your answer is most likely yes it's visible so question is about if it's visible to search 00:09:44 chrishtr: Question is if it's good to have a way to have content in dom which is hidden from visual display but exposed to ways to search in the document, find in page, reader modes, a11y tools. Correct? 00:09:58 Rossen_: Yes. And how and where does css play a role since it's mostly visual layer 00:10:31 Rossen_: If what you're saying...if all the methods you desc will be able to get to the content besides what we paint on screen I think the answer lends easily for if it's available to search 00:10:41 Rossen_: I think I got my answer. Want to go to queue 00:11:52 smfr: Two points. One is content-visibility as I understand is optimization so UA doesn't hav e to build render tree. Issue with allowing finding inside is if UA on every page load tries to look for readerizable content it means every page load your hidden-matchable content will still need to be figured out enough to give right answer to indexing code. So you lose the optimization 00:12:16 [smfr mentions that 'visibility' and 'display: none' need to be resolved, for example] 00:12:57 smfr: Second, anybody who wrote browser code knows you have to think about is content hidden by style, hide from APIs not just visually. display:none does, visibility-hidden sometimes does. Now we have 2 more and I'm uncomfortable adding more variations to is this content available in this scenario 00:13:16 s/visibility-hidden/visibility:hidden/ 00:13:42 chrishtr: Yes, if UA on initial load always indexes and goes into hidden-matchable subtrees performance advantage is lost. I would recommend doing it in a smarter way that doesn't interfere with performance 00:14:25 chrishtr: This is an additional feature which is different and therefore has a cost of impl complexity. It is useful, though, b/c it's common to have collapsed sections or offscreen that's not rendered for performance but should still be searchable. For that reason I think it's justified 00:14:53 smfr: I think you said for first point that yes UA has to do the work and in some UAs the advantange can be lost but depends on what UA does. 00:15:16 chrishtr: I would say it depends on what UA is allowed to do and UA should be allowed to index. There are definitely performance footguns to avoid 00:15:20 [In the abstract, I feel confortable with the intent of proposed resolution 1 and 2 as initially exposed, but the concerns raised by smfr seem very relevant to me] 00:15:38 Rossen_: smfr does that satisfy your questions? 00:15:59 smfr: I guess. It seems unfortunate that the UA can trigger potentially expensive content building in this case 00:16:27 florian: Clarification question. smfr if I'm hearing you in your view searching and indexing are not separate. index powers the search. Or is index for something other than search? 00:17:13 smfr: Original obj was why is cmd+f special. There's more indirect. Safari indexes and in other parts of OS you search and get the webpage. And ideally the results would be the same as you cmd+F on the web page. That's why we're saying it should be same results. 00:17:34 TabAtkins: Seems like that's what htis is intending to do better. Something hideen-matchable is intended to be exposed. ctl+f is off of dom 00:18:10 smfr: It doesn't. ctr+f doesn't find display:none things. So we run off of display:none type things resolved. If you have display:none inside c-v:h-m content you don't want that to show 00:18:29 TabAtkins: So you're talking about expensive rendering is pulling something from dom so it shows up in structure for indexing 00:18:41 smfr: Right and thats up until you render which is fairly expensive 00:19:27 chrishtr: There is a significant cost, yes. UA should be allowed to index but do so in a way that doesn't harm perf. This is an additive thing b/c shouldn't index thigns that are display:none. It's an advantage to a11y but UA needs to be careful on how you schedule work 00:19:27 q? 00:19:31 ack smfr 00:19:32 q- 00:19:48 florian: Could do most of the page and have hidden-matchable as lazy parts. People don't search in ms of load 00:19:57 chrishtr: Right, something like lazy background processing 00:20:37 Rossen_: We're in the time allocated. I don't hear alignment to resolve on the two initial asks. I also see lots of conversation in GH. Happy to give it another 10 minutes next week if the general consensus is achieved on issue 00:20:54 Topic: [motion-1] The computed value of offset-path: path(' ') 00:21:04 github: https://github.com/w3c/fxtf-drafts/issues/392 00:21:30 fantasai: I don't know much on this, but it seemed we should resolve and fix. 00:21:51 heycam: The ultimate issue is we have path function which takes string value. string is svg data string. 00:22:27 heycam: Some strings are invalid. What does that mean for validity of path function. If you use invalid path string inside is it all parse as invalid and dropped or is string preserved and invalidity handled later 00:22:38 TabAtkins: If it's valid how to serialize and if not valid clarify that 00:22:45 florian: Precedint in other properties 00:22:55 fantasai: IN grid we throw out what's invalid after parsing 00:22:58 s/Precedint/Precedent/ 00:22:59 florian: Same here? 00:23:04 heycam: NO reason not to 00:23:22 florian: No architectural complexity so seems like right thing to do 00:24:30 TabAtkins: Larger question then what's asked in issue. If you have invalid pass it's a separate question. The empty string specifically is a valid path per svg grammer but it disabled rendering of paths. Question is how is it cannonicalized and serialized. In chomre it's serialized as none. All other paths stay as paths but none doesn't so doesn't create containing block 00:24:43 heycam: Surprises me. I think it then does not make sense to serialize as none 00:25:10 TabAtkins: If we decide to treat as invalid that's okay with me and this solves iteself. If we want that we should record it. It's about if empty path is valid or not. 00:25:14 florian: Is it useful? 00:25:15 TabAtkins: No 00:25:24 florian: THen make it invalid ad see if world breaks 00:25:35 TabAtkins: Invalid is probably more consistent with chrome behavior 00:25:39 fantasai: 2 resolutions? 00:25:51 heycam: IN issues it's also mentioned strings with only whitespace. Same? 00:25:54 florian: Suppose so 00:26:10 TabAtkins: Yeah. Regardless of specifics of svg grammar shouldn't treat different 00:26:22 Rossen_: can someone summerize? 00:26:32 TabAtkins: 1) Invalid path strings make the syntax invalid at parse time 00:26:37 Rossen_: Objections? 00:26:44 RESOLVED: Invalid path strings make the syntax invalid at parse time 00:26:48 present+ 00:26:59 TabAtkins: 2) The empty string is an invalid path string 00:27:11 florian: With whoever does the edits being careful for all empty types 00:27:17 fantasai: Basically 0 length path 00:27:25 fantasai: 0 length path description 00:27:35 TabAtkins: If we say it's empty we can deal with specifics lather 00:27:40 florian: Empty path not empty strong 00:27:46 s/strong/string 00:27:49 Rossen_: Empty path is considered invalid 00:27:53 Rossen_: Objections? 00:27:59 "a string with no path commands in it", maybe 00:27:59 RESOLVED: Empty path is considered invalid 00:28:03 s/lather/later/ 00:28:09 Rossen_: Anything else? 00:28:31 Topic: [css-pseudo] Privacy considerations for external resources 00:28:40 github: https://github.com/w3c/csswg-drafts/issues/5731 00:29:07 TabAtkins: rune realized that the spec for spelling-error grammar-error and related pseudo has privacy bits about not detecting spelling dictionary 00:29:29 q+ 00:29:39 TabAtkins: As written spec allows you to load a bg image which would allow trigger os spelling errors. He proposes we disallow loading of external resources for styling on spelling and grammar errors 00:29:48 florian: Existing definition of external resources? 00:29:50 q 00:29:54 TabAtkins: Probably not one we can link to 00:30:03 TabAtkins: I think it's reasonable to gloss over for now 00:30:18 florian: Thinking of things like data urls. If there's an existing definition we can work from it would be nice 00:30:22 q+ 00:30:32 ack hober 00:30:43 hober: We already have visited. We do a lot of restrictions on what can do on visited including loading of external resources. Why not limit in same way? 00:31:04 TabAtkins: I believe visited excludes loading other backgrounds. Okay witht hat restriction even if more than we need. 00:31:07 q+ to mention Spectre 00:31:18 hober: I think consistency is valuable. Even if it's a little more it simplifies model 00:31:23 fantasai: Isn't visited underdefined 00:31:35 TabAtkins: Some of details yes but what properties is well defined. 00:31:44 fantasai: I think a lot of your ideas were in a PR we couldn't merge 00:31:54 TabAtkins: That was about how we apply them, not what properties 00:31:59 q? 00:32:13 ack jyasskin 00:32:13 jyasskin, you wanted to mention Spectre 00:32:27 q+ 00:32:31 jyasskin: Wanted to ask how much worrying about Specter which can detect color changes. I've heard about particioning visited whoch wouldn't work for spelling 00:32:49 TabAtkins, https://drafts.csswg.org/selectors-4/#link doesn't seem to have any details 00:32:58 florian: Both are fingerprinting risk but data from visited is more valuble. If it's easy to be consistent that's interesting. but more important to hide visited 00:33:08 s/Specter/Spectre 00:33:20 https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector is relevant (to the extent that it's accurate, which I think it is?) 00:33:27 florian: I'm saying it's related. We're less worried about the attack then on visited 00:34:06 florian: I think this is privacy sensitive only b/c fingerprinting. visited is privacy not just fingerprinting but the actual data. Protecting the data itself is relevent on visited. I don't think it is here. 00:34:29 ack dholbert 00:34:56 s/more valuble/itself valuable independently of fingerprinting/ 00:35:02 dholbert: I think visited restrictions could be problematic here. afaict it just limits you to properties that control colors and wouldn't allow add/remove underline which is main thing you want with spelling/grammar. It limits you to a couple properties and doesn't say you can't use external 00:35:07 q? 00:35:08 Yeah, you're right fantasai, we don't actually have the list in the spec, I was misremembering 00:35:19 Rossen_: What do we do with this 00:35:45 fantasai: I think we can't align with visited. Current definition is the UA can do stuff to hide the visited-ness of the link. There's no details. 00:35:58 fantasai: We can be more precise here and say not loading external resources 00:36:33 fantasai: I can draft up wording what you can do stuff to preserve privacy such as not loading external resources and then we can have a more complete definition in the future that's general and we link to it 00:36:35 florian: wfm 00:36:38 Rossen_: Other opinions? 00:36:45 Rossen_: Is there a 1 line resolution we need? 00:36:52 Rossen_: Or continue in thread 00:36:58 hober: Depends on the text 00:37:06 fantasai: I'll draft up text and we can come back 00:37:14 Topic: [css-pseudo] Problems with styling ::first-letter with punctuation 00:37:23 github: https://github.com/w3c/csswg-drafts/issues/2040 00:37:47 fantasai: Let's skip for now. 00:37:50 github: none 00:37:59 Topic: [css-grid][css-flexbox][quirks] Avoid percentage height quirk in new layout models 00:38:08 github: https://github.com/w3c/csswg-drafts/issues/5545 00:39:05 Rossen_: We'll need to do this in EU time 00:39:08 github: none 00:39:15 Topic: [css-sizing-4] Allow specifying only one dimension for intrinsic sizing 00:39:23 github: https://github.com/w3c/csswg-drafts/issues/5432 00:39:51 vmpstr: Added contain-intrinsic-size property. Takes 2 values. Can take 1 to apply to width and height. Got feedback it can be confusing if dev only wants to spec in 1 direction 00:40:17 vmpstr: Proposal is to make c-i-s be a shorthand for additional values like c-i-with and c-i-height 00:40:22 florian: Which would have normal value 00:40:38 vmpstr: Yes. ANd b/c only during size containment it falls back to what hte size would be 00:40:49 vmpstr: Other is do we add width, height, and block sizes 00:40:57 florian: I'd go logical only. Or maybe all 4 00:41:07 vmpstr: Don't have preference. Feel like fewer is better 00:41:14 florian: I wouldn't do pshycial only 00:41:38 fantasai: Reason why physical is to be consistent with size property we end up having. Main reason we dont' have size property is naming conflict. 00:41:44 q? 00:41:52 fantasai: Anticipation is size would be physical. That's why ended up making physical 00:42:06 florian: Sure. It's a mess so let's stick with the mess. Concept is reasonable and easy 00:42:12 vmpstr: Logical, physical or all 00:42:22 florian: I think what fantasai said overrides. We're in physical land 00:42:27 vmpstr: Both? 00:42:30 Rossen_: I think both 00:42:50 fantasai: There's a size property with all. If we have c-i-s with a longhand it should presumably have all 00:42:55 vmpstr: Makes sense. That's the proposal 00:43:26 heycam: Confused from comment in issue if you say c-i-s 500px shouldn't it be like none 00:43:35 vmpstr: Only takes effect during size containment 00:43:50 florian: I think it should be normal or none. Intrinsic size can be non-0. 00:44:13 vmpstr: I was giving when it would be 0. Should be defautl intrinisic width with a specified intrinsic height 00:44:32 florian: I'd go with normal. None seems to override. Normal seems to be do whatever you'd do if we didn't spec this 00:44:48 heycam: Is there a distinction where you might want to say there is no intrinsic size? 00:44:53 florian: If you want none you can say 0 00:44:58 heycam: But is that different? 00:45:08 fantasai: I think if there's overflow scroll it's different. 00:45:25 florian: I think we can resolve on normal and come back to if there's a use case for none 00:45:27 heycam: Sounds good 00:45:44 Rossen_: Sounds like we've arrived at resolution. heycam are you happy now? 00:45:50 heycam: okay 00:46:10 florian: Prop: Property takes 4 longhands, logical and physical, which have a normal value 00:46:16 Rossen_: Objections? 00:46:22 RESOLVED: Property takes 4 longhands, logical and physical, which have a normal value 00:46:35 Topic: [css-contain-2] apply containment on `content-visibility: visible` ; use `normal` as initial value 00:46:43 github: https://github.com/w3c/csswg-drafts/issues/5695 00:47:06 auto? 00:47:35 TabAtkins: The issue here is that the hidden-matchable value switches content between 2 behaviors. One idential to hidden and one that's indescribable in current. That feels weird, don't normally have auto that goes to unrepresentable value 00:47:47 TabAtkins: Prop the other behavior that makes things visible have an explicit keyword 00:48:19 TabAtkins: Original proposal in thread is name that visible and change the default to normal. Chris points out that it's been shipped in Chrome so visible may be locked. 00:48:29 TabAtkins: I don't specifically want a name but I think we need the property 00:48:36 Rossen_: Is there data if it shoudl be frozen? 00:48:54 TabAtkins: content-visibility as a property is 1% of page loads. That gives reasonable sense there would be problems if we change 00:49:36 q+ 00:49:40 fantasai: Cases where likely to break seem unusual. You have to set it away from inital value and you would have to not be using containment. Seems like most of use cases you'd use containment with this or have explicit width and height in which case no change in behavior if we made this change 00:50:10 fantasai: I don't know for sure, but I think there's a change its safe. If there's a better keyword fine, but I think the properties are better if we make normal the default value 00:50:32 TabAtkins: I prop if people think general idea of the mode having a keyword we resolve on that. Then move back to GH on name and bring it back in a week or two 00:50:33 q- 00:50:38 Rossen_: Works for me 00:50:53 s/change its/good chance its/ 00:50:54 Rossen_: Okay, let's continue there 00:51:11 TabAtkins: Can we get the resolution to make a keyword for this behavior? 00:51:27 fantasai: Prop: Have separate keywords for the visbile and contained value vs initial value 00:51:36 Rossen_: Objections? 00:51:42 RESOLVED: Have separate keywords for the visbile and contained value vs initial value 00:51:53 Topic: [css-contain-1] do we need size containment in a single dimension to enable container queries? 00:52:00 github: https://github.com/w3c/csswg-drafts/issues/1031 00:52:43 miriam: The context is in thinking about container queries and starting from dbaron initial proposal a few years back 00:53:07 miriam: Easy to imagine how it works with full size containment, but doesn't work for most cases. Works in app-like cases but otherwise falls apart. 00:53:24 miriam: prop is 1d containment so can contain width of element and query against that but allow height to adjust. 00:53:45 miriam: Several cases where height of children changes width of ancestors. Scrollbars and % in padding 00:53:54 miriam: A lot of talk about that making it quite difficult 00:54:00 miriam: anders and I have been pushing on that. 00:54:31 miriam: Going through the ideas backwards b/c 2nd one is thinking through how to address issues as they arrise. If we want 1d can we always trigger scrollbar on ancestors, resolve % to auto 00:54:42 miriam: Not full proposals, but want to push conversation forward 00:54:56 miriam: That's a start on how might address issues as edge cases so 1d containment would work 00:55:36 miriam: anders proposed the pinky-promise approach. Idea here is what if we don't require containment on container queries and we resolve the query as if we have full size containment but allow you to make changes so you get different final size then reported 00:55:40 q+ 00:55:58 miriam: trade offs between but not exclusive of each other. A lot more to resolve on both. Anders isn't here but that's basic context 00:56:28 florian: Author usibility I think pinky-promise works. Cases where children effect cross axis size are rare and easy to avoid. 00:57:13 ack florian 00:57:28 florian: Concerned about implications on impl b/c makes layouts effectively stateful. if doing partial layout you have to do a relayout to figure out size if you hadn't instearted the children you did insert. Order becomes meaningful as well which brings us back to having to do a layout of the anti-page 00:57:52 q+ 00:58:02 florian: Not impossible, but could be expensive. I'm concerned. THe plug the leaks one by one seems more possible. We haven't come up with so many examples. We've so far had 2. Maybe can plus one by one 00:58:35 florian: Seems that by far dominant of 1d is query inline size, not block. The leaks for inline and block are not same. Easier to plug inline leaks. If we jsut worry about those maybe slightly easier problem 00:58:39 zhengxu has joined #css 00:58:59 bkardell_: In the pinky-promise thing doesn't that wind up negative auto-height? 00:59:11 ack bkardell_ 00:59:35 florian: No, the pinky-promise case you do a container query against width and then you say I won't do anything in layout what would change the width of the parents. As long as you don't have the cases that is does change width of parents everything is fine 01:00:09 miriam: One other complication is inside of floats that shrink wrap, container query would return 0 but layout is quite a bit different 01:00:30 florian: Yeah. But for shrink-wrap this is fundamentally problematic. 01:00:33 +1 01:00:39 florian: If there is a use case for that it's a whole different can of worms 01:00:56 Rossen_: We're at time. not sure if we have a resolution we could call. I would urge you to continue discussing on GH 01:00:57 I'm somewhat not convinced the pinky-promise will yeild the results web-developers expect. 01:01:06 TabAtkins: Not looking for resolution yet, just general information 01:01:08 Topic: end 01:01:15 Rossen_: Thank you all for calling. Talk next week 01:07:21 Zakim, end meeting 01:07:21 As of this point the attendees have been Florian, dholbert, dael, Rossen_, astearns, TYLin, plinss, vmpstr, brandon, dlibby, chrishtr, heycam, alisonmaher, jarhar, smfr, miriam, 01:07:24 ... Huijing, jyasskin, bkardell_, hober 01:07:24 RRSAgent, please draft minutes 01:07:24 I have made the request to generate https://www.w3.org/2020/12/02-css-minutes.html Zakim 01:07:26 I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye 01:07:30 Zakim has left #css 02:17:41 projector has joined #css 02:18:12 leaverou has joined #css 02:18:42 Rossen has joined #css 02:19:12 shans has joined #css 02:19:43 sylvaing has joined #css