15:57:13 RRSAgent has joined #css 15:57:13 logging to https://www.w3.org/2020/09/09-css-irc 15:57:15 RRSAgent, make logs Public 15:57:16 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:57:33 chris has joined #css 15:58:44 present+ 15:58:57 present+ 15:59:01 ScribeNick: dael 15:59:27 futhark has joined #css 16:00:10 present+ 16:00:27 bkardell_ has joined #css 16:00:32 huijing_ has joined #css 16:00:48 present+ 16:00:50 present+ 16:00:55 present+ 16:01:05 present+ 16:01:49 alisonmaher has joined #css 16:01:52 present+ 16:01:55 present+ 16:02:09 Guest60 has joined #css 16:02:11 dholbert has joined #css 16:02:15 GameMaker has joined #css 16:02:19 astearns: I think we have enough people to start 16:02:28 present+ 16:02:29 present+ 16:02:31 present+ 16:02:40 present+ 16:02:42 astearns: One extra item is a reminder we're having an extra meeting tomorrow to talk MathML topics 16:02:52 astearns: Same time, just tomorrow 16:03:01 bkardell_: Looking forward to it. invited some CG members 16:03:07 astearns: Any changes to today's agenda? 16:03:16 Topic: [css-conditional-3] Let's finish the specification 16:03:21 github: https://github.com/w3c/csswg-drafts/issues/5315 16:03:44 present+ 16:03:45 chris: CSS Conditional 3 is almost ready and almost done. Very few open issues 16:04:08 oriol has joined #css 16:04:09 chris: Test suite is fully passed but API section doesn't have tests. Can write script test easily. 3 must items are untested but fairly easy 16:04:21 chris: Most open issues don't look hard. Maybe push some until further level. 16:04:59 chris: One problem, don't currently have an editor. If needed I could do the work and happy to help. if there's a bunch of work we can finalize 16:05:10 myles has joined #css 16:05:13 fantasai: Vaguely recall 14 or more open issues but not sure if they're in GH 16:05:27 dlibby has joined #css 16:05:32 present+ myles 16:05:32 chris: 7 open, 22 closed. I did a bunch of getting out of older requests and putting into GH a year ago 16:05:35 fantasai: Okay 16:05:39 present+ 16:05:40 present+ 16:05:51 present+ 16:06:06 fantasai: I think we should invite dbaron as an invited expert if he'd like. If he wants to edit is separate question. I'm happy to help with editing. I think I did make a list of issues at some point 16:06:09 una has joined #css 16:06:14 chris: That would help, thank you 16:06:40 chris: Call for dissenting opinion, help is appreciated. Unless there are dependent issues I think we can finish this topic 16:06:49 astearns: Anyone else volunteering to edit? 16:07:05 TabAtkins: I'm interested in general. I'll be happy to look if you need help on something specific 16:07:09 chris: thanks 16:07:25 present+ 16:07:28 astearns: Agree we should get dbaron back as invited if he likes, but I believe he's on parental leave too 16:07:39 chris: This was last published in 2013 so it needs some tlc 16:07:47 astearns: Shall we make fantasai and chris editors? 16:07:50 chris: fine for me 16:07:53 smfr has joined #css 16:08:01 RESOLVED: Add chris and fantasai as editors to CCSS Conditional 3 16:08:07 present+ 16:08:12 s/CCSS/CSS 16:08:20 Topic: [css-pseudo-4] Add a highlight pseudo-element for find-in-page or scroll-to-text 16:08:24 antonp has joined #css 16:08:28 github: https://github.com/w3c/csswg-drafts/issues/5233 16:08:41 xiaochengh has joined #css 16:09:06 tab go for it, my mic is broken 16:09:07 TabAtkins: I can run with it 16:09:48 TabAtkins: Thread talks about general highlight API. This is about find in page or scroll to text stuff. That they're not exposed is inconsistent and means authors can't have consistent highlight. Proposal is expose those two under same or separate times. 16:09:50 Present+ antonp 16:09:56 q+ 16:10:06 TabAtkins: If same group like UA-selection. Is separate ::find-in-page and ::scroll-to-text 16:10:12 q+ 16:10:19 TabAtkins: Opinions? Okay to pursue? 16:10:54 TabAtkins: how does this relate to https://drafts.csswg.org/css-highlight-api-1/ ?? As this was created for that if I recall correctly 16:11:05 florian: We talked a month ago. This question doesn't take into account that conversation. If I recall find in page effects by browsers are way beyond highlight pseudo element. Safari does whole page darkening. Not something normal pseudo could do. 16:11:12 gregwhitworth, this one hooks into the browser UI 16:11:18 gregwhitworth: It doesn't, and that's not - that's for a *generic* highlighting mechanism controllable by authors 16:11:32 gregwhitworth: ahhh 16:11:36 florian: Conceptually similar but style is very different. We should do some research abotu what browsers do and what authors want to do and if that fits within existing things 16:12:24 q+ 16:12:30 TabAtkins: Browsers do go beyond but they all currently do the same selection-ish highlight. May have other styling but still highlight the selection. It's a pretty basic UX that we feel will be stable across time. being able to customize highlight still seems reasonable to do 16:12:31 q- 16:12:50 ack GameMaker 16:13:22 GameMaker: My comment is that Safari does darken page. Also I'm not entirely on board where we'd need 2 to do what Chrome does. Highlight whole page in one color and the one you're at is in a different color. this only suggests one thing 16:13:24 present+ Chris & Lea 16:13:33 present+ 16:13:56 GameMaker: Browsers do different things. If we make this a highlight element, elements are styled in more ways. With selection you can do more, but opening to highlight pseudo element there's a whole host of things we can do 16:14:17 q+ 16:14:17 GameMaker: I can see why we're considering. I don't know what devs are asking for. I don't know right thing to do it 16:14:51 present+ 16:15:13 GameMaker: Summary- Chrome would need 2 colors b/c they highlight all words and the one you're looking at is different. Opening to full pseudo highlight is more than just color and it's opening more than we can do. Need to be cognizant of that and I'm not sure devs are asking for this 16:15:15 q+ 16:15:18 tantek has joined #css 16:15:19 ack smfr 16:15:32 smfr: One question is if author provides styles does that disable browser built in find highlighting? 16:15:40 TabAtkins: What would be tricky about that? 16:15:59 q? 16:16:02 smfr: If styling is simply color no but if more involved later there might be something like appearance where browser decides to turn off built in 16:16:32 myles: Related point where if some elements have pseudo and others don't do we auto-darken the page when at elements that don't have this and when you cmd + G to the next would we change darkening? 16:16:42 q+ 16:16:57 TabAtkins: I don't think we'd turn off darkening. I was wondering if problems darkening and turning on author supplied highlight colors 16:17:00 ack chrishtr 16:17:07 dlibby_ has joined #css 16:17:42 q- 16:17:46 chrishtr: Like to point out there are 2 use cases. Find in page and scroll to text. Chrome has recieved dev desire on scroll to text. When you use this it will highlight bg of selected content in yellow for short period. Many devs find that color doesn't fit with theme 16:18:06 q+ 16:18:06 chrishtr: Added find in page b/c thought would be good to think together. Agree find in page is more complex. I think scroll to text is pretty simple 16:18:15 ack gregwhitworth 16:18:50 q+ 16:18:50 present+ 16:19:04 gregwhitworth: I've likewise heard developer request for this. Having a browser hook would be good. Very valid points on open questions. Feel it warrents a more concrete proposal. As you denoted chrishtr it may vary between the two 16:19:15 ack florian 16:19:15 gregwhitworth: For a use case there is developer interest and worth exploring 16:19:54 florian: How it would work if it's a highlight is defined. But details on use case would be good to see if they fit. It was mentioned it's a fading yellow highlight. If the fading exposed, timing, control? Knowing this would help us figure out if this is the right thing to do 16:20:32 florian: We know what pseudo highlights do but we kknow less what we're trying to achieve. Good to document. Probably different between find in page and scroll to text. Maybe document both separately. See if it fits the use case 16:20:38 ack una 16:21:27 una: Bringing this up as opportunity to be consistent. Some browsers highlight all words, some only active. Some difference in colors cross browser. Lots of considerations here. Not jsut contrast but browser experience. And what happens with dark mode, how do we make sure the highlighted word stands out. 16:21:49 q? 16:22:01 leaverou: Another thing is this is a pseudo element that will spawn multiple sub elements. Is there precenent. Is it a special pseudo element? 16:22:05 florian: There's precedent 16:22:22 TabAtkins: Defined in ::selection. Constrained properies that make it hard to tell number of boxes 16:22:26 leaverou: currentColor? 16:22:33 TabAtkins: It's however it works in ::selection 16:22:46 See https://drafts.csswg.org/css-pseudo-4/#highlight-pseudos 16:22:51 florian: It's pretty cool, the definition. not tree abiding and weird, but defined weird. 16:22:59 The properties supported are not allowed to affect layout in any way 16:23:24 una: B/c contrast issue it might be good to allow this so you can style borders and other parts of highlight to make it stand out. Would help authors make sure text style stands out in their specific design 16:23:31 properties currently specified to work is https://drafts.csswg.org/css-pseudo-4/#highlight-styling 16:23:38 chrishtr: dark mode- can't dev proved dark mode style for this? 16:24:01 una: Yes, jsut additional overhead. Good to do b/c author makes sure whatever preference mode these styles have clear visibility 16:24:04 s/will spawn multiple/will span multiple/ 16:24:25 TabAtkins: Support that. b/c we all do dark mode I'm of opinion any UA provided color should be under author control to make sure it looks good with both dark and light 16:25:06 florian: I suggest we split the issue in 2. Document what browsers do today and which aspect authros want to control. From there can judge if it's a good fit. Good chance for scroll to text. Find in page, maybe maybe not. 16:25:19 florian: Split the issue, document use cases. Does that sound reasonable? 16:25:28 astearns: Anyone argue it should be a single way? 16:26:02 florian: It might be. If we say highlight pseudo is right that's a single way. That some browsers highlight all and some only active. I think there's also highlight in scroll bar. There's a number of things being done. 16:26:29 florian: If we want to say the find text thing is easy and the other less then we split. But we explore in parallel and if they're easy we do both 16:27:06 chrishtr: Makes sense to split. Scroll to text is much simplier. It's a progressive enhancement of linking property. In Chromium-based it shows a yellow that disappears after user interactions. It's pretty simple 16:27:15 chrishtr: I can file a new issue and go into more detail with examples 16:27:35 florian: Thing I wonder about this is the timeout. Other highlight pseudos aren't timed. Other than that it doesn't sound hard. 16:27:40 we have examples with much more interaction, such as marginalia, e.g. what Medium does with highlight UI 16:27:45 fantasai: Just like with selection I think UA controls when it exists 16:27:49 florian: Probably 16:28:04 florian: Is this transition out and the transition out is defined by UA? Maybe. 16:28:19 astearns: We'll open at least 1 new issue to separate the two 16:28:34 q++ 16:28:37 err, q+ 16:28:44 chrishtr: Great to confirm if there's any objection to trying to move forward and spec scroll to text? 16:28:44 ack hober 16:28:49 ack + 16:29:15 hober: I don't htink I object. I do think that the find in page one is supported across all browsers and has more complex styling. Tackling harder first means you get easier for free later. 16:29:17 q+ 16:29:24 agrees with hober, specify find first since it's more cross-browser 16:29:30 florian: Not sure. At thispoint we're trying to see if the definition fits more problems 16:29:40 astearns: my q is an addendum 16:29:48 TabAtkins: The text find thing is a soft problem already. Not jsut easy, it's a none problem once we define it exists 16:30:03 ack gregwhitworth 16:30:06 q? 16:30:17 I don't understand the proposal? 16:30:22 astearns: I think we have a way forward to open another issue 16:30:35 gregwhitworth: Wanted to make sure chrishtr was good with where we're at 16:30:53 chrishtr: Great to resolve that it's useful for scroll to text. Come back with a proposal text to verify with the group 16:30:59 ack gregwhitworth 16:31:04 astearns: Prop: We have this facility for browsers that impl scroll to text 16:31:08 astearns: Obj? 16:31:13 q+ 16:31:23 florian: Still curious about how animation works. If we'll come back with a definition of how that works, yes 16:31:27 ack tantek 16:31:49 tantek: I think framing the scroll to text in terms of highlight is too narrow a framing. Don't object to exploring but object to limiting to juust that 16:32:32 tantek: Medium, for example. If you scroll to a selection of text additional UI occurs where you can annotate. At least couple indy web where you can comment in margins and when you highlight it highlights text you commented on. 16:33:10 tantek: Have in the wild that kind of text that's far beyond simple backgorund highlights. I don't oppose exploring, just want to make sure we're not trying to collapse it with something like find that's mroe limited 16:33:45 chrishtr: Responded to those use cases in github. Those would need script involvement. Similar to how we discussed accent color on form controls this is low hanging fruit. It by no means precludes more customization in the future 16:33:50 tantek: Okay, thanks 16:34:23 florian: From my PoV I would like to know if entire fade in and out is UA controled or if timing is controlled. 16:34:43 chrishtr: I think that's out of scope for resolution and I'll come back with a precise thing. 16:35:01 astearns: Resolution is we're interested and would like you to pursue and come back with proposal text? 16:35:04 chrishtr: Yes 16:35:20 RESOLVED: we're interested and would like chrishtr to pursue and come back with proposal text 16:35:30 s/if timing is controlled./if its timing is UA controlled but the actual fading is controlled from css/. 16:35:32 Topic: [css-pseudo-4] Standardizing input[type="range"] styling 16:35:40 github: https://github.com/w3c/csswg-drafts/issues/4410 16:35:59 gregwhitworth: I can try and take if it the person isn't on the call 16:37:12 emilio: These people rpoposed standardizing a model similar to Gecko. Subtle differences. Added to get feedback. Modal is fairly simple. Could go one way or other. Would like to hear from WK and Blink if it's interesting to using more Gecko-like model and if there's interest in standardizing. 16:37:24 q+ 16:37:44 ack gregwhitworth 16:38:00 Proposal: 16:38:01 ::range-thumb { /* Styles the thumb of the input*/ } 16:38:01 ::range-track { /* Styles the track of the input*/ } 16:38:01 ::range-progress { /* Styles the progress/fill below the thumb of the input*/ } 16:38:20 gregwhitworth: To get more specific the proposal is 3 different items. Range-thumb, range-check, and reange-progress. Concrete is missing 16:38:59 gregwhitworth: did a decent amount of research b/c I was hesitant we'd design into a corner. These 3 are unanimous. I'm in favor of standardizing. Would need concrete what can/can't they do analysis. 16:39:53 iank_: From blink, I don't know if mason is on. Quick look this is interesting. Would welcome improvement. I don't think we have concept of progress element, but could be wrong. Agree with gregwhitworth and analysis of what properties would/wouldn't be respected would pave way for easier implementation 16:40:09 gregwhitworth: I will note WK you have a concept of tracking. I don't know if you have an element. 16:40:15 iank_: I don't believe we have an element. 16:40:18 gregwhitworth: Okay, okay 16:40:27 iank_: Just purely a paint effect I believe 16:40:29 q+ 16:40:53 q+ 16:40:59 gregwhitworth: I had requested the research. We can action me and I'll reping the person to know what's interop so we cna get a concrete proposal 16:41:03 iank_: Sounds great 16:41:05 ack smfr 16:41:22 smfr: WK has html progress which is pre-fork. Certainly interested in participating in standardizing 16:41:24 q- 16:41:32 smfr: the range pseudo elements 16:41:50 astearns: Sounds like we have consensus to work in this area 16:42:05 ACTION gregwhitworth respond to commentor on #4410 to see if they can do the research 16:42:22 gregwhitworth: Yep. smfr if you can see what you limit that would be great. I'll compare with Maz in Chromium 16:42:33 q+ 16:42:36 iank_: We recently did a bit of work to simplify in this area so may be pretty different to WK 16:42:40 I wonder if we're painting ourselves into a corner, and excluding alternative designs (dial like, or other things) 16:42:42 gregwhitworth: Got it. I'll definitely test 16:42:44 ack jensimmons 16:43:04 q+ 16:43:42 q+ 16:43:50 jensimmons: I want to advocate for a holistic way to get at these problems. Similar space to other conversations. Jumping to we should make pseudo elements. We should look at the whole system, not just this one control. gregwhitworth I think said this in the thread. Terrific we're doing this, but should look at whole thing and not just design separately 16:44:34 leaverou: Agree with jensimmons. We standardize pseudo elements on a piece by peice basis. There was proposal for parts to standardize. What happened to it? Why create different pseudo elements when can make one for all form controls. 16:44:35 ack gregwhitworth 16:44:48 +1 jensimmons, take a look at the whole system 16:45:09 +1 jensimmons and leaverou as well -- forms need wholistic review 16:45:36 gregwhitworth: I really do think and maybe there's an OpenUI joint meeting that makes sense, I don't want to paint into a corner. OpenUI is holistic appraoch. There's 3 or 4 topics where we talk in meta and go in circles while we do ad hocs. But I don't disagree with accent color and these where it technicallye xists 16:45:59 gregwhitworth: We should do the holistic thing but web is the web today. There are valid use cases not supported in UAs that should be documented. 16:46:43 gregwhitworth: I'll throw together and ad hoc agenda for joint meeting with OpenUI. There's 3 or 4 topics we could cover. There's enough overlap between the groups. I'm in favor of resolving on these 3 elements but it won't allow you to go to the extent of content swapping 16:46:59 leaverou2 has joined #css 16:47:19 gregwhitworth: Also point to explainer that Google, Edge, and Salesforce did which is put together a model definition. I think that's worth exploring in joint meeting. Get opinions on that model because does allow part access instead of one offs 16:47:20 ack emilio 16:48:04 emilio: I think gregwhitworth had good points. I agree to finding a holistic solution is useful and needs to pursue. This is standardizing reality. The prefixed pseudo elements won't go away. Allowing authors to not write same style in 3 selector lists is good 16:48:22 astearns: Agree we should consider holistically and happy to see peoplelike gregwhitworth and Mason are doing the research. 16:48:43 astearns: It seems like we are doing the holisitic consideration. If there are gaps in the analysis it would be great to raise those in the issues 16:48:44 Doesn't seem that these pseudos would let you do this sort range controls (or style a UA that had them): https://cdn.shopify.com/s/files/1/0017/2972/products/PX5-chromcapsprodcutpage_580x387.jpg?v=1596119507 16:49:10 astearns: For this issue we have the next step of figure out what things could be used on these pseudos. 16:49:24 astearns: Should resolve we do want to make progress on the proposed range pseudos 16:49:36 astearns: Prop: Continue working on standardizing these 3 pseudos 16:49:41 astearns: Objections? 16:49:54 RESOLVED: Continue working on standardizing these 3 pseudos 16:50:04 astearns: Where it goes, I'm assuming pseudo spec? 16:50:17 fantasai: Yes or do we want a spec of form controls and their pseudo elements? 16:50:36 astearns: Yes, does make some sense to have form control pseudos by themselves 16:51:19 gregwhitworth: We could add that for discussion at joint meeting. I would love to not duplicate. If they're just pseudo elements they go in pseudo. If we spin up a form control spec it goes same patch as OpenUI. 16:51:25 astearns: That okay fantasai ? 16:51:52 fantasai: Okay. If we end up adding lots that's specific to a form control at that point it should move to its own spec. Currently mostly specific to page 16:52:44 gregwhitworth: That's what I was trying to take away from is that overlap. Pseudo elements are a part but ultimately define an anatomy. If we go that route do we spin a new spec for parts? This can be in holistic discussion about where things live. this is part of Open UI anatomy discussion 16:52:52 Topic: [css-pseudo] Problems with styling ::first-letter with punctuation 16:53:06 github: https://github.com/w3c/csswg-drafts/issues/2040 16:53:12 florian: that's where the model explainer I referred to as you're correct somewhat but it's primarily due to to the current capabilities of psuedos 16:53:21 github: none 16:53:25 Topic: [css-text] 'tab-size' de facto applies to inline boxes 16:53:31 github: https://github.com/w3c/csswg-drafts/issues/5489 16:53:54 florian: Currently applies to block but in impl applies to inline as well. Question is how? Stack or independant? From tests seems independent 16:54:20 florian: If you have a prserve-tab with a value of 7 you measure frmo edge and push to next independent of if other ones. All browsers seem to do this so would like to spec it 16:54:24 ack fantasai 16:54:24 fantasai, you wanted to ask where to put this and to 16:54:29 sounds like we could standardize reality there 16:55:07 ok, fair enough 16:55:10 fantasai: Defined to apply to block so when font changes in paragraph tab stops line up. We knew at time impl didn't do that. I think it's not a question about line up with realitiy, there's a reason the spec is different. We can decide we can't do thing that is correct, but there's a reason why it was spec as different. 16:55:16 florian: I did not know that, thank you 16:56:02 oriol: I prop in issue that maybe could go in between current spec and current impl. Could say property applies to inlines and let authors change values in line boxes. If value spec is a number say it refers to advance size of space character of containing block. 16:56:13 oriol: In common cases keep good alignment but closer to current impl 16:56:16 fantasai: Works for me 16:56:25 astearns: And likely more web compat 16:56:30 florian: Works for me 16:56:55 astearns: Prop: Change the spec to say tab size applies to inlines but when that happens the number values apply to advance width from block container 16:57:02 astearns: That would change for all browsers? 16:57:12 oriol: Yeah, right now they use width of space of inline box. 16:57:26 florian: I will add a test for that 16:57:29 astearns: Objections? 16:57:37 RESOLVED: Change the spec to say tab size applies to inlines but when that happens the number values apply to advance width from block container 16:57:45 astearns: Thanks oriol for the solution 16:57:48 Topic: end 16:58:18 astearns: One additional thing, proposed meeting with i18n group during TPAC. Need to have an agenda. Some suggestions for xfq but would like more 16:58:31 chrishtr: Issue #4792 16:58:44 https://github.com/w3c/csswg-drafts/issues/4792#issuecomment-689099191 16:58:55 thanks for that, will review! 16:59:05 chrishtr: Don't have time to talk but got a very detailed update with proposed solution. Has a lot of detail and design doc as well as prototype. In order to make next week discussion useful please look in advance 16:59:16 astearns: Proposal link ^ 16:59:34 astearns: Thanks for everyone for calling in. Talk to some of you tomorrow 17:00:13 Thanks astearns 17:01:08 zakim, end meeting 17:01:08 As of this point the attendees have been argyle, florian, dael, chrishtr, cbiesinger, futhark, huijing_, bkardell_, faceless, alisonmaher, rachelandrew, GameMaker, jensimmons, 17:01:11 ... dandclark, gregwhitworth, myles, oriol, dlibby, dholbert, hober, dauwhe_, antonp, &, Lea, smfr, una, tantek 17:01:11 RRSAgent, please draft minutes 17:01:11 I have made the request to generate https://www.w3.org/2020/09/09-css-minutes.html Zakim 17:01:13 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 17:01:17 Zakim has left #css 17:04:45 so, how is ::scroll-to-text different from yellow-fade technique on :target ? 17:05:31 ala https://css-tricks.com/on-target/ and others 17:10:10 gregwhitworth, re: range anatomy...don't forget the datalist options. styling the text, color of the tick marks/labels might make a 4th pseudo worthwhile 17:11:50 aja: I have considered the additional potential parts that exist across common controls in top design systems/component libs in UI/UX. You can see the full list here: https://open-ui.org/components/slider.research.parts/ Happy to add any that aren't there 17:12:41 aja: as noted in the issue, many of these make sense even though not universally leveraged 17:13:42 aja: specific to datalist I referenced it generally here - > We may want to consider marks, steps and mark content as these are actually already standardized - some UAs render them and others don't but they aren't reachable 17:14:03 aja: issue comment is here: https://github.com/w3c/csswg-drafts/issues/4410#issuecomment-680424639 17:20:20 have read that before...just mentioning in context of what i'd find a useful possible 4th pseudo. glad for work on the first 3 19:14:39 AmeliaBR has joined #css 19:47:10 projector has joined #css 19:47:40 leaverou has joined #css 19:48:10 Rossen has joined #css 19:48:41 shans has joined #css 19:49:11 sylvaing has joined #css 22:38:12 ondrejko has joined #css