16:57:02 RRSAgent has joined #css 16:57:07 logging to https://www.w3.org/2023/01/11-css-irc 16:57:07 RRSAgent, make logs Public 16:57:38 please title this meeting ("meeting: ..."), Rossen_ 16:57:45 PaulG has joined #css 16:57:53 khush has joined #css 16:59:41 flackr has joined #css 16:59:44 present+ 16:59:57 SebastianZ has joined #css 17:00:15 jfkthame has joined #css 17:00:23 present+ 17:00:54 ydaniv has joined #css 17:01:00 present+ 17:01:13 present+ 17:01:14 present+ 17:01:17 present+ 17:01:18 (chat only) 17:01:33 bradk has joined #css 17:01:34 present+ 17:01:40 irc only for first half 17:01:44 Present+ 17:02:01 I’m going to be in and out of the call today 17:02:35 present+ 17:02:37 present+ 17:03:16 futhark has joined #css 17:03:26 alisonmaher has joined #css 17:03:30 present+ 17:03:46 present+ 17:03:53 chris has joined #css 17:03:55 present+ 17:04:20 q+ 17:04:22 ntim has joined #css 17:04:23 present+ 17:04:29 present+ 17:04:39 scribenick: fantasai 17:04:41 Topic: Agenda Bashing 17:04:46 present+ 17:04:55 argyle has joined #css 17:05:05 present+ 17:05:06 q+ 17:05:11 masonf has joined #css 17:05:17 present+ (chat only for the beginning) 17:05:19 present+ 17:05:20 astearns: Most of the nesting issues are fine to take up and are ready, but I'm just not seeing consensus on the blocking issue 8249. 17:05:26 sanketj has joined #css 17:05:31 astearns: Not sure we need to spend call time on it until we get to a better situation in the issue itself 17:05:32 q? 17:05:35 ack astearns 17:05:45 TabAtkins: Safari and Chrome are both interested in shipping very soon 17:06:07 TabAtkins: If we defer until the logjam resolves itself, it's going to get resolved by somebody shipping 17:06:16 astearns: We try to address the objection 17:06:26 TabAtkins: That's why we didn't resolve last time 17:06:31 TabAtkins: but we need to discuss and resolve 17:06:42 present+ 17:06:45 emeyer has joined #css 17:06:47 ack jensimmons 17:06:51 present+ 17:06:54 present+ 17:06:57 jensimmons: The two color issues are important for us to get to today 17:07:03 jensimmons: and also nesting 17:07:13 jensimmons: When Peter raised the objection, there were 3 parts and we opened different issues to discuss 17:07:25 jensimmons: there were a lot of conversations that were had about those objections 17:07:31 q? 17:07:32 present+ 17:07:35 present+ 17:07:40 jensimmons: and I do think we can focus our objections on that specific thing and not repeat ourselves 17:08:03 jensimmons: So maybe do the first two issue,s then color, then the rest of the call for nesting 17:08:06 Rossen_: ok, we can try that 17:08:08 +1 17:08:14 good suggestion, jensimmons 17:08:19 +1 17:08:21 ??: I would like to get to #3 17:08:29 ??: don't know if it will fit in this call 17:08:45 Rossen_: Let's see how quickly we get through the first six we have right now 17:08:51 Rossen_: the sooner we start, the sooner we might get to those 17:08:55 lea has joined #css 17:08:58 s/??/Tim/ 17:08:58 s/??/Tim/ 17:08:59 present_ 17:09:01 present+ 17:09:13 Topic: Pseudo-class before-change style for transitions on new elements 17:09:20 q? 17:09:20 github: https://github.com/w3c/csswg-drafts/issues/8174 17:09:21 smfr has joined #css 17:09:33 flackr: when coming from display:none have no display style 17:09:37 ... so can't define a from state 17:09:39 present+ 17:09:42 ... can define in CSS animation, but less ergonomic 17:09:52 ... so proposing we add an :initial pseudo-class which establishes the initial style 17:09:56 ... the before-change style for CSS transitions 17:10:08 ... in discussion, decided that if we made this a pseudo-element 17:10:12 rrsagent, here 17:10:12 See https://www.w3.org/2023/01/11-css-irc#T17-10-12 17:10:20 ... we could optimize this by preventing e.g. sibling selectors and only require occasional style calculation when it's used 17:10:28 ... so proposal is to have ::initial establish the initial style 17:10:32 q+ 17:10:34 q? 17:10:42 ack emilio 17:10:50 emilio: This would be a pseudo-element that matches against an element? 17:10:54 oriol has joined #css 17:10:56 GameMaker has joined #css 17:10:58 emilio: so matches element rules plus magic pseudo-element? 17:11:01 present+ 17:11:04 present+ 17:11:11 pseudo-element would be applied on top of element rules 17:11:16 emilio: that's pretty different from pseudo-element 17:11:25 emilio: I don't think we have a precedence for this, which is a bit tricky 17:11:25 bradk has joined #css 17:11:30 emilio: I'm also confused when you want it 17:11:35 emilio: this is for coming back from display:none? 17:11:49 emilio: seems implementable, but seems tricky and weird to make it a pseudo-element 17:11:58 emilio: because targetting two element styles on one 17:12:02 emilio: weird wrt cascade 17:12:15 flackr: that's good feedback for pseudo-element approach 17:12:25 flackr: could also take pseudo-class approach, but less easily optimizable? 17:12:28 emilio: in what sense? 17:12:43 flackr: if you have combinator selectors, element showing up in the DOM can cause recalcuation 17:12:48 emilio: but that's the case for all pseudo-element 17:12:55 flackr: this is extra style recalc that doesn't normally exist 17:13:11 emilio: I'm a bit confused, you recalc more if you have :initial along the combinators.... depending how wel you optimize 17:13:39 flackr: I think given :initial is only establishing before-change style and otherwise doesn't apply to the element, not that weird that it conflicts with other styles 17:13:49 flackr: because those other styles can't initiate transitions from display: none 17:13:56 emilio: we have a similar case with pseudo-classes for links 17:14:13 emilio: need to resolve :visited / :unvisitied, need to do unconditionally, but dont' understand why :initial would be slower 17:14:28 flackr: if initial is a pseudo-class, can be used as part of combinator selectors 17:14:32 flackr: so have to resolve all those combinators 17:14:43 flackr: but if pseudo-element, can't be used in those combinators 17:14:47 emilio: for :visited we have special case 17:15:05 emilio: basically :visited on left of sibling is ignored 17:15:09 flackr: ah, we could do that 17:15:19 emilio: the way I think of implementing it is, we have this element ... 17:15:25 davidleininger has joined #css 17:15:27 emilio: otherwise :initial only matches rightmost compound 17:15:31 flackr: that sounds reasonable to me 17:15:34 emilio: that would be less weird 17:15:39 q+ 17:15:45 +1 to emilio 17:16:14 ack futhark 17:16:29 futhark: ignoring the pseudo-class, when resolving selectors, would have already computed style for previous one so would have eixsting computed style 17:16:36 futhark: so :initial wouldn't match on those elements 17:16:45 bradk has joined #css 17:16:48 emilio: Right. :initial can only match in this special case 17:16:59 emilio: "this element is now :initial", now compute 17:17:07 emilio: with :has() have similar dependency... 17:17:16 futhark: Similar if getComputedStyle() in display:none subtree 17:17:25 futhark: You need to ensure you have styles there to do inherit etc. 17:17:31 emilio: not for siblings, but for ancestors 17:17:39 emilio: I'd rather say that it only matches on the rightmost 17:17:43 +1 17:17:47 +1 17:18:06 fantasai: How does this interact with page loading, partly loading? 17:18:18 flackr: applies anytime the element first gets a layout box 17:18:30 q+ 17:18:31 flackr: this would apply any time you add element to a page 17:18:39 flackr: separate issue for avoiding running things during load 17:18:47 flackr: but this is pre-existing problem for animations, which run on page load 17:18:56 Rossen_: So based on description, this would not fire on display:contents ? 17:19:03 Rossen_: since it doesn't have a box? 17:19:07 flackr: that sounds right 17:19:13 fantasai, you wanted to ask how this interacts with loading 17:19:16 ack fantasai 17:19:18 ack emilio 17:19:30 emilio: I think I'd rather special-case it to display:none since that's the actual thing 17:19:42 q+ 17:19:44 +1 to emilio. 17:19:47 emilio: at least, I don't think display:contents stops animations in the subtree, whereas display:none does 17:19:58 ack PaulG 17:20:15 PaulG: If we're leaning towards pseudo-element, how would that affect AX tree? 17:20:28 PaulG: if not supposed to be animated at that time, just want to make sure we consider that 17:20:38 flackr: don't think we're leaning towards the pseudo-element approach 17:20:49 flackr: but not intenteded to establish a separate elmeent, just style the real element in the before-change state 17:21:05 ack fantasai 17:21:36 fantasai: Suggest maybe flackr and emilio can come back with a revised proposal, and we can move to other issues 17:21:43 flackr: fwiw, AX should be equivalent to animations 17:21:47 Rossen_: ok, let's end here 17:21:55 Rossen_: come back when you're ready, thanks for introducing 17:22:08 Topic: Entry and Exit Animations for top-layer elements 17:22:13 github: https://github.com/w3c/csswg-drafts/issues/8189 17:22:32 flackr: When certain elements go in/out of top layer 17:22:45 flackr: if devs want to have an naimation on the, they need the element to remain in the top layer for duration of the animation 17:22:53 flackr: so proposal is that we allow specifying top layer in the transition properties 17:23:02 flackr: but that it's otherwise not a developer-stylable property 17:23:13 flackr: essentially, you can specify transition: top-layer 17:23:16 flackr: and give it a duratoin 17:23:24 flackr: and this is the duration during which the element stays in the top layer 17:23:34 q? 17:23:37 q+ 17:23:50 ack ntim 17:23:58 ntim: I've always been against the top-layer CSS property concept 17:24:08 ntim: The concept should really stay abstracted away from the developer 17:24:17 ntim: even just introducing this property is a bad first step, I think 17:24:24 q? 17:24:28 q+ 17:24:30 q+ 17:24:48 lea: I wanted to as ntim why he thinks this concept should be abstracted away from the developer 17:24:54 lea: there's a lot of reasons it should controllable in CSS 17:24:55 ack lea 17:25:03 lea: we keep seeing use cases that could be solved if could be controlled in CSS 17:25:12 ntim: If you allow controlling top layer with CSS, you end up with same issues as z-index 17:25:25 ntim: the appeal of top layer right now is that it's controlled by order of JS API calls 17:25:30 q? 17:25:31 q+ 17:25:38 ntim: but once you start allowing random elements to put top-layer, then what order is actually used in the end? 17:25:47 lea: I think that depends on how we design the feature 17:25:55 lea: maybe it's a property that just the UA controls 17:26:02 lea: though I hope to avoid that 17:26:02 bradk has joined #css 17:26:08 ntim: I think it needs a real design 17:26:20 ntim: just exposing this concept... 17:26:22 Note that the proposal is not incompatible with ntim's concern. I agree with his concern. 17:26:31 lea: yes, absolutely, does need design work to do it properly to not have problems of z-index 17:26:34 lea: total +1 to that 17:26:44 q? 17:26:45 ack emilio 17:26:49 emilio: I don't think I have a strong feeling wrt top layer property 17:27:00 emilio: but basically the use case seems to be transitioning modal dialogs and so on when opening and closing 17:27:05 emilio: and I assume other elements in the top layer 17:27:12 emilio: to me that seems like a use case that non-modal dialogs also need 17:27:20 emilio: there are dialogs that may not be in the top layer 17:27:42 emilio: so feels to me that this is a clever hack to avoid having closing/closed state on the dialog and fullscreen things 17:27:45 emilio: not sure if that's been considered 17:27:52 emilio: so why is this property better 17:28:15 emilio: why not say that it goes from open to non-open, have an intermediate state, and define that intermediat state transition as when all its transitions have finished 17:28:28 ack flackr 17:28:43 flackr: Wrt tim's concern about exposing top-layer to the user, we have these stackign questions 17:28:53 flackr: this proposal nicely avoids, because things remain in their current stacking position 17:29:02 flackr: so we don't have to change any of that or figure out those definitions yet 17:29:10 bradk has joined #css 17:29:22 flackr: I don't understand what non-modal dialogs have a problem, they can continue to apply their desired z-index 17:29:37 emilio: but you still have the issue of if you want a close animation on a dialog, you need to do it manuall 17:29:37 q? 17:29:45 flackr: dialog element, which is top-layer? 17:29:55 emilio: dialog may or may not be top layer depending on show vs showModal 17:29:59 If the dialog isn't modal, it isn't in the top layer, and you don't need this. 17:30:07 flackr: It would maintain its top layer state during transition, but still have to define the animation 17:30:12 q+ 17:30:17 emilio: idea is you can do opacity or transform or whatever to hide the dialog, right? 17:30:23 emilio: right now that's not easy to do with non-modal dialogs either 17:30:31 emilio: why not have ... 17:30:42 emilio: Firefox has all its panels as well, we have animations when you use menus 17:30:47 emilio: and those are just web elements 17:30:53 emilio: internally we have 5 states 17:30:59 emilio: open, opening, closing, closed 17:31:09 emilio: we ahve intermediate states so that the front end can actually use transitions for this stuff 17:31:20 emilio: my question is, why is this specific to top-layer and not to elements that pop in and out 17:31:35 flackr: you can't reasonably establish entry animations is resolved by setting inital styles 17:31:44 flackr: with that, should be possible to do on non-modal dialogs 17:31:49 flackr: top-layer is the only thing they don't have access to 17:32:00 flackr: the model is consistent with other things taht have a state change trigger an animation 17:32:10 flackr: state changes immediately, even though animation continues to run 17:32:15 non-modal dialogs need the ability to animate to/from display:none, but that's a separate issue. 17:32:23 emilio: when non-modal dialog closes, you want to ?? animation to displaY:none 17:32:36 emilio: you transitoin display, which we resolved to do but don't yet do 17:32:48 emilio: so your proposeal would be to animation display directly and also transition opacity 17:32:51 flackr: I have proof of concept for Chrome 17:33:05 q? 17:33:06 emilio: so this proposal is to explicitly allow z-order to remain while transitioning 17:33:08 q+ 17:33:20 emilio: like transitioning display 17:33:27 emilio: on one hand, I thin it would be less weird to have these intermediate states 17:33:36 emilio: when you open dialog, you transition to opening state 17:33:45 emilio: when you update style and don't have transitions running you're open 17:33:47 emilio: etc. 17:33:53 emilio: when no pending ransitions transition to closed 17:34:04 emilio: only targetted to dialogs/popovers/etc. but I think that's the main use case 17:34:10 emilio: I think that would be slightly less weird for authors 17:34:16 emilio: rather than transitioning display ... 17:34:29 bradk has joined #css 17:34:33 emilio: having magic property seems weird 17:34:45 dino7 has joined #css 17:34:51 emilio: I guess this proposal weird, but I think maybe having intermediate pseudo-classes could be more elegant and usable for authors 17:35:02 flackr: I think this is more consistent with other state changes for the Web 17:35:46 ack fantasai 17:35:50 fantasai: why not have things just stay in the top layer until their transitions are done automatically? 17:36:20 ntim: That seems to make sense 17:36:43 chrishtr: Having a transitioning state and this automatically detect what they're happening and preserve top layer during UA was thoroughly explored during popover design 17:36:49 chrishtr: and prototyped in Chromium 17:37:00 chrishtr: was specific to popover and dialog, and why not have a generic mechanism in animations 17:37:22 chrishtr: this is what lead to these proposals for display:none animations and specifying top-layer duration 17:37:31 chrishtr: without specifying UA magic to detect length of animations 17:37:32 ack chrishtr 17:37:33 q+ 17:37:43 chrishtr: discussed at length in popover API proposal 17:38:05 ack lea 17:38:16 lea: firstly, it seems weird to have a property that only works in transitions 17:38:32 lea: if devs want to put things in the top layer, what prevents them from adding an animation that puts them in the top layer? 17:38:45 emilio: .... 17:38:50 lea: so only available in transitions? 17:39:01 lea: what prevents having a transition that lasts 999999s? 17:39:11 emilio: you'd need to call modal 17:39:25 lea: trying to prevent devs by adding only to transitions, it's a hack and can be worked around 17:39:32 emilio: I agree 17:39:41 q? 17:39:42 emilio: internally, how we implement top layer 17:39:50 emilio: I'm not sure how I feel about this 17:40:02 q+ 17:40:12 [missed] 17:40:16 Rossen_: let's end this topic right here 17:40:25 Rossen_: we coered quite a bit, but this doesn't seem ready for resolution 17:40:38 Rossen_: was well articulated and proposed, and good path forward for addressing some of the TAG review comments 17:40:50 Rossen_: shoudl take conversation back to GH, and should bring it back when it's more developed 17:41:03 q- 17:41:09 Topic: Agenda 17:41:18 Rossen_: Two nesting and two color issues, top priority. Order? 17:41:28 chris: would like to suggest the color issues, think there's consensus 17:41:31 present+ 17:41:34 chris: if agreed, we can close rapidly 17:41:37 Topic: Relative Color Syntax 17:41:44 github: https://github.com/w3c/csswg-drafts/issues/7978 17:41:53 chris: problem was using base color as ?? 17:42:01 chris: I added spec text similar to color-mix() 17:42:06 dholbert_ has joined #css 17:42:09 chris: if that's okay by everyone we have solved the issue 17:42:11 TabAtkins: Great for me 17:42:18 Rossen_: Anyone else? 17:42:22 s/using base color as ??/specifying base color as currentcolor/ 17:42:33 RESOLVED: Accept Chris's proposal 17:42:50 +1 17:43:15 Topic: channel keywords 17:43:20 github: https://github.com/w3c/csswg-drafts/issues/7876 17:43:40 chris: main issue raised was that the keywords could have two possible types, doesn't work 17:43:48 chris: either number or percentage 17:43:56 chris: went with number to be consistent with serialization 17:44:09 TabAtkins: nit, you accidentaly did percentage for wmb, but otherwise it's great 17:44:20 chris: It's because color-4 it only takes a percentage 17:44:29 TabAtkins: Ah, in that case it's completely fine 17:44:33 chris: any other comments? 17:44:50 chris: anyone need more time? 17:45:17 ntim: didn't have a chance to look at it 17:45:26 lea: does that mean for rgb they resolve to 0-255 range? 17:45:38 chris: yes, but remember it's 0.0 to 255.0 so you don't lose precision 17:45:44 lea: but inconsistent with rgb models 17:45:50 chris: because it was invented poorly 17:46:01 lea: I agree but does that mean we don't need relative color syntax for rgb? 17:46:04 q? 17:46:14 chris: I have a lot of trouble coming up with use cases 17:46:18 ack ntim 17:46:20 chris: I haven't found a good example 17:46:35 lea: I think it's primarily for ocmpletenes, but maybe we should not do it just for completeness 17:46:39 lea: restrict to color()? 17:46:42 chris: I wouldn't go that far 17:46:51 chris: let's resolve this and deal in other issues? 17:47:07 chris: get consensus on going to number? 17:47:16 Rossen_: So do we have enough consensus? 17:47:20 s/ocmpletenes, but maybe we should not do it/completeness, but we don't generally do things/ 17:47:50 lea: consensus is about every component that's "number or something else" resolves to number? 17:47:55 lea: so hues resolve to numbers? 17:48:01 chris: yeah, all examples treat hues as number 17:48:11 chris: so I think most ppl are treating as numbers 17:48:17 lea: yes, that's what authors do 17:48:38 [...] 17:48:38 +1 to number 17:48:52 chris: Proposal, keywords with multiple specified types result in number 17:48:58 Rossen_: Any additional feedback or objections? 17:49:05 jensimmons: this is fine with us from Apple 17:49:18 RESOLVED: keywords with multiple specified types result in number 17:49:39 Topic: CSS Nesting Syntax 17:49:44 github: https://github.com/w3c/csswg-drafts/issues/8249 17:49:49 resolving two color issues in <10min is unprecedented 17:49:52 bradk has joined #css 17:50:05 TabAtkins: I'm willing to summarize what I believe plinss's position is, he can correct 17:50:15 TabAtkins: fear is that the direction the spec is specifying will overly constrain future CSS 17:50:22 TabAtkins: certain new syntactical things in properties or selectors 17:50:32 TabAtkins: proposal is instead to have a dedicated syntax to mark things as a selector 17:50:42 TabAtkins: that way all future syntactical developments would still be allowed 17:50:49 q? 17:50:54 TabAtkins: and future developments for selectors, which might currently conflict with properties, would also be allowed 17:51:01 TabAtkins: because you have a glyph to mark it as a selector 17:51:20 TabAtkins: related is the 8251 issue, where dbaron discusses the things that trigger selector processing and not currently used by selectors 17:51:31 TabAtkins: this issue accepts mixing of properties and selectors in grammar space 17:51:40 TabAtkins: issue is, we've already discussed previously, what peter is suggesting 17:51:55 TabAtkins: this was Option 1, you had to start with & or @nest or various variants thereof 17:52:07 TabAtkins: This was rejected by WG for verbosity and for copy-paste limitations 17:52:16 TabAtkins: core issue is, WG has looked over that syntax direction and rejected it in the past 17:52:25 q+ 17:52:38 TabAtkins: so I would like to re-affirm that decision, that we're not going to use a dedicated marker syntax of some kind to denote selectors and separate them from properties 17:52:46 TabAtkins: but rather go with current approach of mixing the space 17:52:53 q+ 17:52:59 TabAtkins: make sure the Syntax spec creates a clear dividing line 17:53:32 fantasai: I think something Tab didn't emphasize is the core part of Peter's concern for forward compat 17:53:46 fantasai: The real effect of forwards compat isn't as - we'r enot limiting as much as it seems like we are 17:54:03 fantasai: What we're allowing for the future is anything that's invalid, regardless fo whether it's currently property or selector 17:54:14 fantasai: The space of "what is invaidl junk" is actually really broad even with our current proposal 17:54:17 ack fantasai 17:54:17 fantasai, you wanted to react to ntim 17:54:21 https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1362033982 17:54:27 fantasai: The ony thing we can't expand into is a super-limited syntax space that I can't imagine us actually doing 17:54:37 #stuff starting with a symbol { anything in this block } valid-property: value; 17:54:40 fantasai: We cant' start with a symbol, *and* has a curly-brace block *and* is followed by something tha tlooks like a property 17:54:51 fantasai: This is the only thing you can't define in the future is a cool new feature 17:55:01 fantasai: If it doesn't look like that it's invalid - whether a property or style rule, we throw it out 17:55:09 fantasai: And in th efuture we can call it valid either way 17:55:21 fantasai: So for concern abou tpainting us into a corner, it's acutally a very small corner and the rest of the space is open 17:55:52 plinss: Just want to clarify a couple points, most of what Tab said is accurate 17:56:02 plinss: it's not necessarily required to have a solution that prefixes every single rule 17:56:07 plinss: also fine to create a new scope 17:56:18 plinss: just nested brackets or whatever, that also solves the copy-paste problem 17:56:28 plinss: just want something that delineates the syntax space 17:56:38 bradk has joined #css 17:56:41 plinss: we did resolve not to do this in the past, but I'm not sure that took everything into account 17:56:46