16:01:59 RRSAgent has joined #css 16:02:04 logging to https://www.w3.org/2023/01/18-css-irc 16:02:08 Meeting: CSS Working Group Nesting Breakout 16:03:57 zakim, start meeting 16:03:57 RRSAgent, make logs Public 16:03:58 please title this meeting ("meeting: ..."), astearns 16:03:58 CSSWG_LogBot has joined #css 16:04:00 lea has joined #css 16:04:00 present+ 16:04:00 Present+ 16:04:00  Meeting: CSS Working Group Nesting Breakout 16:04:00 present+ 16:04:00 present+ 16:04:00 present+ 16:04:00 present+ 16:04:00 present+ 16:04:00 present+ 16:04:00 castastrophe has joined #css 16:04:09 present+ 16:04:22 present+ 16:04:46 present+ 16:04:57 present+ 16:05:01 you’re awesome, argyle! 16:05:08 <3 16:05:30 astearns: first up, mixing properties and selectors 16:05:41 astearns: agenda is in the private list 16:05:42 GameMaker has joined #css 16:05:52 Agenda: https://lists.w3.org/Archives/Member/w3c-css-wg/2023JanMar/0041.html 16:05:52 Email subject is "Proposed agenda for nesting breakout" 16:05:56 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1382256731 16:05:56 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8249. 16:05:56 Topic: [css-nesting] Problem with mixing properties and selectors 16:06:05 oh a link is even more handy :D 16:06:10 astearns: peter do you want to summarize and start 16:06:16 fantasai has changed the topic to: https://lists.w3.org/Archives/Member/w3c-css-wg/2023JanMar/0041.html 16:06:19 present+ 16:06:22 plinss: i have several concerns, most are aware of them, we can review what we need to 16:06:42 plinss: my best path forward is relax and do the sass syntax and require prefix nowhere. we need to explore that 16:07:11 plinss: we should take some time to experiment if a path is feasable, especially controversial. make all authors happy if we give them this syntax 16:07:21 una has joined #css 16:07:23 q+ 16:07:26 plinss: we have soemthing that hasnt been considered or discussed, i'm asking we do that first 16:07:40 astearns: we experiment, get some data, is feasible is performant enough 16:07:47 s/especially controversial/especially because it's controversial/ 16:07:52 Rossen_ has joined #css 16:07:54 plinss: we added this restriction 25 years ago, and i wasnt convinced we needed it back then 16:07:58 q? 16:08:30 plinss: since then, i dont think anyone has pushed back and challenged it. there's some experience fromt he tag that's done extra look ahead, said it wasnt a big deal. lea and i have discussed strategies, doesnst require entire parser changes. could be a small change. why arent we exploring this? 16:08:32 This was explored a bit in https://github.com/w3c/csswg-drafts/issues/7961 16:08:34 ack TabAtkins 16:08:43 present+ 16:08:54 TabAtkins: as ive said in the thrads a few times, the current proposal is the most ameniable to look ahead in the future 16:08:59 davidleininger has joined #css 16:09:01 s/fromt he tag/from a developer/ 16:09:04 TabAtkins: in t he future, it would just b e removal of some restrictions 16:09:17 s/lea and i/TAG and Lea and I/ 16:09:29 s/thrads/threads/ 16:09:55 q+ 16:10:03 TabAtkins: we could walk or drop back to achieve this. 2 ways forward, restrictive at first 16:10:29 if we go with any other solution and later upgrade look aheda, we'll have ways of writing. wierd way and correct way. 16:10:51 if we go with the current proposal and then look ahead, then delta is small. might see an is() selector wrapped around a typue selector. but the rest will be identical. smallest delta one to the other 16:11:15 matthieudubet has joined #css 16:11:20 s/if we/TabAtkins: if we/ 16:11:21 s/if we/TabAtkins: if we/ 16:11:28 s/is()/:is()/ 16:11:30 TabAtkins: about investigating infinite lookahead. this isnt a 25yr old restriction. folks looked into it about a decade ago when i was first looking into parsing. 16:11:38 q+ 16:11:59 TabAtkins: at that point, there wasnt a serious exploration. but implementors did believe it would be too much of a cost in a hot area, in initial page css parsing. we've been wrong, and i'd be delighted to be proven wrong (like has) 16:12:28 TabAtkins: until we do, i dont want to, or think we should block progress under the assumption that advacnes in stuff have solved our perf issues. sometimes it does or doesnt, in the meantime folks are clamoring for it 16:12:40 TabAtkins: sorry y'all community, we'll continue to push it away for N months 16:12:56 jensimmons has joined #css 16:12:58 TabAtkins: any case, we go with the current proposal or infinite lookahead. the current proposal is still the best solution int he absence of lookahead 16:13:24 When we talk about Sass style nesting, I think it’s important we distinguish which features of Sass style nesting we would be copying. 16:13:32 TabAtkins: either way, we end up in the same world. either a slight shift towards infinite lookahead, or we wait and get the full syntax. 16:13:41 For example, in CSS style nesting, tokens would be independent parts of a selector, whereas in Sass I think tokens can concatenate into new kinds of selectors. 16:13:46 present+ 16:13:48 JonathanNeal: The ones that don't involve concatenating within tokens :) 16:14:11 astearns: we not talking about "infiniite" lookahead, as i understand. and i'm hoping it's not months. just quick data to inform what we're doing, instead of just not answering the question 16:14:19 lea, I think not concatenating within tokens is totally reasonable and understandable. I think the way that we wrap things in :is() is going to trip people up, though 16:14:24 TabAtkins: it is infinite lookahead, because you can have unlimited ambiguous lookahead 16:14:27 ack plinss 16:14:37 q? 16:14:44 plinss: again we're not discussing how long it will really take to do this. i dont believe it's months. it oculd be days or weeks. 16:15:09 plinss: if we do this experience, one of3 outcomes: prove lookahead is not viable and never will be. or we discover it'll take more time and it will take months. 16:15:12 lea, like "article { section h3 { ... } }", it can map to "section article h3" and that's not generally expected 16:15:13 q+ 16:15:16 present+ 16:15:50 (fantasai, i think you mean `article h3 { section & {...}}` 16:15:52 ) 16:15:54 plinss: in the situation where we prove it's not viable, i'm still not convinced what we have is the best answer. but i dont want to debate it. i will argue that any approach that requires a prefix, is also something we can relax in the future if we figure out lookahead. once we make prefix optional, we can never go backwards if we make a mistake. if we start witha prefix, we can always relax it 16:15:57 q+ 16:16:09 plinss: so that is the safer approach. again, i dont want to tangent until we determine is the experiment viable 16:16:14 if it's weeks, lets wait a few weeks 16:16:35 fantasai: yup, that's a separate issue on the agenda, right? 16:16:36 plinss: i've been waiting for nesting for 25 years, but if we say give me another month or two and we can give you everythign you really want, folks would be ok with that 16:16:38 ack futhark 16:16:39 q+ 16:17:05 futhark: about the details and implementation in blink. we have something we call a streaming parser, we throw tokens away as often as possible. we used to tokenize the whole stylesheet until the parser took over, we had some peek memories 16:17:14 futhark: being able to throw away tokens helps us with memory 16:17:22 s/peak memories/high peak memory usage/ 16:17:32 q+ 16:17:32 futhark: for us we'll know the problems with infinite lookahead, we'll need to go back to something similar we had before 16:17:50 futhark: another issue is, the block stack doesnt need a snapshot in order to restart the parsing for a property 16:18:04 futhark: i dont think it's a matter of days, in chrome, it's definitely weeks at least 16:18:25 plinss: first of all, yes it's theoretically infinite look ahead, the average will be small. not a cost you pay all the time 16:18:33 plinss: only cost with obscenely long selectors 16:18:45 plinss: this is an experiement. you dont have to make production code, you can quick hack and try it out 16:19:43 plinss: you dont have to worry about a block, you have lookahead, you're parsing a property or declaration, if you see a token that's not an ident, youre done. if there is one, lookahead and move on. if it is a colon, lookahead until you see another sigil. if you see an open brace first, you see a rule, move on. not a huge deal. 16:19:53 plinss: may take months to perfect, but an experiement could take hours or days 16:19:54 (fyi the algorithm plinss is describing is what I proposed in #7961) 16:19:59 ack JonathanNeal 16:20:00 Note custom properties can contain { 16:20:03 JonathanNeal: ty lea what i'm going to bring up in the chat already 16:20:10 present+ 16:20:22 q? 16:21:08 JonathanNeal: i wanted to share, terms like "everything developers want", is hard for me. i assume we're talking about nesting from Sass? the reason i'm having trouble is that sass is concat based, which i presumed is off the table. therefore i'd edpect that a goal of acheiving parity, would be mute if they would still have such fundemental differences. dont mean this to disuade research, but as far as parity, i thought it'd be mute without 16:21:08 concatenation. . 16:21:16 s/mute/moot/ 16:21:29 s/mute/moot/ 16:21:30 plinss: for clarity, i mean not requiring prefixing, not necessarily the other features. separate discussiont o follow it 100% 16:21:31 flackr has joined #css 16:21:33 ack lea 16:21:57 lea: to reply to jonathan first, the sass folks admitted concat was a mistake. we mean & always being optional for descendants. if there's a better name, happy to use it. 16:22:29 lea: reason i'm on the queue, if we assume infinite lookahead is possible, how could we decide around this unknown. 16:22:36 present+ 16:23:02 lea: one thing we could decide on, assuming lookahead is not possible, do we still want option 3. if so, adopt 3 now nd lookahead in the future. 16:23:13 lea: if option 3 depends on lookahead, then sure we can wait like peter said 16:23:53 argyle: If lookahead is NOT possible, do we still need Option 3? Then we can adopt it now. If lookahead *is* possible, do we want to adopt the additional restriction that braces cannot be included anywhere in the value of a property? (we can still allow the entire value to be enclosed in braces, for mixins etc, and braces in strings are not a problem). If we *don't*, then the whole exploration is moot. 16:24:06 s/argyle/lea/ 16:24:06 lea: 2nd, if it is possible, it doesnt automatically solve the problem. we can make & optional. lea just pasted it 16:24:21 I write things down in advance, too. And I still fumble every time. :) 16:24:45 lea: in issue 7961, it was also pointed out that ot adopt this, even with infinite lookahead, we need to forbid braces in custom properties 16:25:13 lea: we could allow braces to wrap the whole value, so future can do mixins and shortcuts, some syntaxes that require that. still possible, can't have empty pseudo class, no conflict there. we do need to forbid braces in the property value 16:25:21 lea: looks like these are fairly uncommon, but would restrict some cases 16:25:37 q? 16:25:40 lea: i think the tradeoff is worth, would be good to have a resolution on this. if we know it's possibnle, we we lift the restriction 16:25:52 TabAtkins: i'm writing the rules of thing we'd run into while we do these minites 16:25:56 lea: would be nice if the issue was updated 16:25:59 Don’t people drop JSON in custom props? I know I’ve done before 🙈 16:26:10 s/while we do these minites/I'll paste it in a few minutes/ 16:26:12 ack jensimmons 16:26:49 q- 16:26:55 jensimmons: this question about lookehad is really important, i appreciate the WG is finding out if this is possible. here at apple we've been talking about it alot 16:27:08 jensimmons: this idea its easy and is only a couple hours, is honestly kinda insulting. it's nto easy, it will take weeks 16:27:22 jensimmons: a hacky quick, yeah of course, we can of course do that, the quetion is, at what perforamnce cost? 16:27:33 jensimmons: a quick hacky edperiement doesnt answer that questoin, a deeper dive is required to see the impact 16:27:52 everyone values performance, no? 16:27:54 jensimmons: i can tell you the webkit team, we value perf incredibly highly. its not simple to "just toss it is, no big deal". it will take time 16:27:56 Would anyone know — does the GitHub issue already address selectors like `color-scheme:nth-child`...? 16:28:00 q+ 16:28:09 jensimmons: we wont know how long that effor takes until we have an answer 16:28:17 JonathanNeal, yes 16:28:21 jensimmons: or we keep going and the perf is trash, until we decide it's not viable 16:28:28 fantasai: thank you 16:28:31 q+ 16:28:34 JonathanNeal, that's the problem, fundamentally -- the overlap in syntax between selectors and property declarations 16:28:56 q? 16:29:06 jensimmons: it's not a quick thing. also, engineers dont live in isolation, there's a schedule. it's always a balance, cant just clear the desk and work on lookahead. please undersatnd we value and care about and determine if this is possible. is it going to happen nexxt week, or next 3 months, no. 16:29:21 jensimmons: we have a implementations and a spec, we have an option 3 soltion that web developers are thrilled about 16:29:45 fantasai: Yes. I was under a (potentially false) presumption that this fundamental issue has been researched and discussed many times over recent years during the acceptance of the original CSS nesting proposal. 16:29:57 Here's the proposed parsing: https://gist.github.com/tabatkins/6c230f0ce612d80979e4a4bdfa7ee489 16:30:03 jensimmons: even tho there's a gotcha, which i did not like at the beginning, is clear at this point there is broad consensus we like to ship option 3 with this gotcha. in the future we'll dive into if or when, if not in the next year then 5 or 10 years, we can change and evovle nesting 16:30:40 plinss: a, i'm not trying to be insulting, but my point with a quick hack, i'm not proposing we ship the quick hack, just a quick hack for data. if it's not optimal, but it turns out to not be that slow, we have our answer now without waiting 16:31:11 plinss: 2nd, we've aalready settled on option 3, we havent, i'm an objection. we got to that point by widdling down options. 16:31:37 plinss: new information came to light, and if we had that all along we would have made different decisions. it will lead to a formal object if we want to ship option 3 today. that isnt a quick fix here 16:32:06 TabAtkins: As a user-land polyfiller, I both respect that comments are thrown out before these rules in the parser spec, and yet it still makes reading parser rules just harder enough. :P 16:32:24 jensimmons: regarding perf, it might happen that way peter. might discover some feedback and path of where it's going to go based on early results. it often doesnt fall together than neatly. we might get lucky and it only takes a short time, that's hoping, that's not how eng schedules are made. 16:32:38 jensimmons: 2, i did not say we settled, i said we have broad consensus. 16:32:42 I volunteer to explore the nesting w/ unlimited lookahead in Gecko in the next month, fwiw 16:33:09 q+ 16:33:31 plinss: my point with the experiement, scheduling concerns, etc, i think if its this high priority, we want to get this thing settled. an eng couldl take a day or 2 to figure it out, and if the worst case is acceptable, we know our path forward. even if it takes a week or 2, it's worth waiting. and we dont have to wait on apple, anyone testing can find the answer. 16:33:42 plinss: at least we tried to settle it quickly, and i dont think that's unreasonable 16:33:47 ack TabAtkins 16:33:49 q+ 16:33:50 q- 16:34:45 q+ 16:34:48 Re: "Non-custom properties can never contain top-level {}-blocks". Pouring one out for Custom Property Sets. 16:35:08 TabAtkins: the big procedurral thing here, in terms of ordering. if we assume, like we wait for dataon this, and we find infinite lookahead is fine, we switch to that. if not, peter asusmption seems to be that we wouuld go back to discussing all options again. but before this, we researched under the assumption that infinite lookahead is not feasible, unless there is new information that we would make a new decision from option 3 and months of 16:35:08 discussion, we should work under the assummption we'll make the sasme decision 16:35:30 TabAtkins: either now, infinite lookahead or current spec. reminder, we can convert option 3 to infinite lookahead 16:35:41 TabAtkins: i dont think we're going to throw away consensus we've acquired so far 16:36:00 TabAtkins: if we find no lookahead and we want option 3, peter will still object. whether that's not or after exploration, we can do that now 16:36:42 astearns: i disagree that waiting and finding that infinite lookup isnt feasible, means we start over. we've been assuming it's not possible, so we'll likely end up with option 3 if we find it's not feasible. but, if it is feasible, the design could radically change. 16:37:16 astearns: we'd be better off with a single good solution than a design based on the assumption wasnt feasible, then switching to it is. i think it's a bad thing to go with a solution based on unproven assumptions, then change things later 16:37:18 I agree with Tab that we've already figured out what we want to do without lookahead. 16:37:24 I think denying top-level blocks to declarations feels harsh to me. 16:37:34 TabAtkins: i agree, the current spec has no author visible changes if we go with infinite lookahead 16:37:58 s/lookahead/lookahead, other than allowing selectors to start with a tag selector/ 16:38:04 But I admit it’s never really been tested. There is nothing like an `aria: { selected: true }` shorthand declaration. 16:38:12 And I believe we do know what we want to do if lookahead if possible — that we would do Option 3 without the 'gotcha' of requiring an `&` before an element selector 16:38:15 plinss: i'm not saying we reopen every issue, but it's unfair to not look at all issues because we didnt look at all the information. alot of decisions were made of syntax convenience or capability, not the fact it closes off design space in the langauge. we do need to reconsider some of those option sin that light. 16:38:27 plinss: if we're going to go there, it's a bigger decision. we dont have to go there if lookahead is feasible 16:38:33 That is 100% wrong, we considered the language-evolution concerns all thruout. 16:39:03 q? 16:39:08 plinss: jen was saying, all the authors are thrilled with 3, we have data that many authors will put the prefix there anyway. optional prefix serves a fraction of the users. i see it as a footgun. if they try and do it without it, they'll waste time looking for the bug. it's not really that great a solution 16:39:21 plinss: we dont have to have this debate, if infinite lookahead is feasible 16:39:26 ack fantasai 16:39:26 fantasai, you wanted to respond to peter 16:39:58 In my limited circles, automatically prefixing everything felt a bit like making a strong formatting decision about the use of semicolons or braces in JavaScript. 16:40:07 fantasai: peter is arguijng that the conerns about forward compat will chagne everything, i strongly disagree with that. the usability concerns are very real, main reason i dont like optoin 3. we did discuss those at length, and we landed at optoin 3 anyway. which i have to accept that's where we are at. 16:40:09 https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1362033982 16:40:27 fantasai: the css language cutoff is very small, we're not causing any future problems. i dont see a real problem with future compat 16:41:02 fantasai: i dont think that bringing up future compat into the discussion with higher consideration is going to cause any change in our decision. the biggest problem is the usability concern, and we've already discussed it with our eyes open 16:41:04 q- 16:41:06 ack bramus 16:41:15 ack lea 16:41:46 lea: option 3 was a compromise because we assumed lookhead was not possible. if lookhead was possible, it might be better to ship a syntax where & is mandatory everywhere, so later it can be optional everywhere 16:42:15 lea: do not this doesnt fix all the lookahead issues 16:42:19 appreciate that comment, fantasai, and strongly agreed as someone who has worked with/on multiple user-land parsers. 16:42:40 lea: makes more sense to be mandatyory at first, later not. instead of it's kinda mandatory, not it's totally optional 16:42:47 Would be difficult to feature detect, no? 16:42:56 lea: seems like a more reasonable progressions. i could still stand by 3 if lookaheda is not possible 16:43:05 lea: but if lookahead is somewhre down the line, i'd prefer this kind of progression 16:43:22 TabAtkins: required the & doesnt fix infinite lookahead 16:43:44 TabAtkins: we can't make it mandatory. that means parsing requires looking in the future we is the exact thing we're discussing. 16:43:53 lea: we can make it mandatory in addition to option 3 16:44:05 lea: & mandatory with all descendants 16:44:35 I don't think that's easier for devs — to have & .foo and :is(article) & ... that's confusing 16:44:47 This break is brought to you by Coffee and Cheetos. 16:44:47 argyle: If we *knew* that lookeahead is possible and it would just take a while to implement, I think it would actually be better to ship an even more restricted variation of Option 3 with an always mandatory ampersand; then it can be made optional everywhere at once. (Do note that making the & mandatory doesn't actually remove the need for the other parsing rules wrt non-idents, since the & can appear later in the selector) 16:44:55 s/argyle/lea/ 16:45:33 plinss: how long will it really take to test lookahead? still feels unanswered 16:45:50 TabAtkins: it'll likely be months, but we do have someone for Q2 or Q3. 16:45:56 ack emilio 16:46:01 oh, no mic 16:46:03 sigh 16:46:04 q- 16:46:09 q+ 16:46:13 q- 16:46:14 q+ 16:46:16 Anyways, I was going to say that I can explore this in the coming months or so 16:46:16 q+ 16:46:40 ack Rossen_ 16:46:43 I can set some time aside for this 16:47:16 emilio: Rossen_ i was interested to hear more about, and observing, listtening. sounds to mem like peter is asking can we have functional verification it's possible. on the back of it, can we validate this is feasible from a perf pov. having worked for perf in various browsers, it's all speculation until tried. speculating it's bad or good is just a speculation 16:47:48 Rossen_: it doesnt sound like having option 3, even if we ship today, doesnt preclude anyone from having infinite lookahead option, which will sipmly relax the restrictions. we have 2 options forward 16:48:19 Rossen_: i dont hear them as exclsuive. having one of the lookahead will make option 3 mute, but if we're looking at this, sounds like opt 3 is leaning towards. 16:48:30 s/mute/moot/ 16:48:51 Rossen_: main issue is, can we have functional validation, then have someone validate and run it through labs and get a good picture. not weeks or months. then yo ucan figure out if you can put htis into production 16:49:01 ack emilio 16:49:12 emilio: i can set some time aside and try infinite lookahead this month or so? that useful? 16:49:18 astearns: yea i think so 16:49:27 astearns: that would be a timeline folks would respond well to 16:49:51 q+ 16:49:55 astearns: personally, it'd b e better if we had some experiementation in lookhead before we go ahead and ship, but that's my preference 16:50:19 q+ 16:50:19 present+ 16:50:19 +1 to having look-ahead eval before option 3 go-live 16:50:36 astearns: if we ship without the info, i'd want a clear path for if we see it's feasible, how does the nesting story change. how do we go from option 3 to better syntax with infinite lookahead. not cleaer to me what the transformation is like and what the authoring dissonance would be in having both 16:50:41 Are we presuming or not presuming TabAtkins’ proposed parsing restrictions for infinite look-head? I would think the restrictions may make it disqualifying, separate from capability or performance. 16:50:43 ack bramus 16:51:02 should we define what is "acceptable" for performance regarding unbounded lookahead (1% perf regression on speedometer?) 16:51:09 JonathanNeal, not sure what you mean 16:51:26 bramus: one side of the story, yes infinite lookahead not quick to try out and the other is option 3 than there's going to be an objection. at a stand still? how to unblock? 16:51:33 I am referring to “Non-custom properties can never contain top-level {}-blocks”, TabAtkins. 16:51:58 bramus: my idea is to be a minimal version of option 3. it'd look like, & is required and only allowed at the start. then if lookahead is viable, we upgrade to sass like, if not it can move into option 3 as it is today 16:52:04 bramus: that minimal version can relax to either 16:52:23 bramus: to peters concern, with mixing props and selectors, and that only prevents the & from being the first character of th eproperty, that's reserved 16:52:34 astearns: confirm that useful 16:52:36 To me, restricting 1/3 of the recognized grouping syntaxes would put a significant restriction on future combat. 16:52:37 ack plinss 16:52:44 zakim, close queue 16:52:44 ok, astearns, the speaker queue is closed 16:52:55 rossen: ... also, don't forget that this needs to go into all parsers, not just the ones controlled by the browser engines (i.e. the best engineering staffed teams) 16:53:06 plinss: clarify my position, if someone does the research in a short amount of time, but it'll be 6 months to solving fully. then i'm ok knowing we ship option 3 now because i know the future pain will go away 16:53:44 plinss: if the response is, it's going to take 6 months to have an asnwer at all, and we want to ship in the meantime, i'm not going to object a mandatory prefix. lookahead viability determines amuch safer option 16:53:47 ack jensimmons 16:53:56 jensimmons: processing what peter just said 16:54:23 jensimmons: peter, if you've got a commmitment from a browser team or mnultiple to serioulsy look at lookahead in the nexxt months, you'd be ok shipping option 3 as it is now knowing we relax it if possible 16:54:35 plinss: if we dont know if it's feasible or not. if we find it is, but it's going to take time, then i'm fine with option 3 16:54:53 q? 16:54:56 q+ 16:55:07 plinss: if we dont know, ship with a required prefix. thenwe can research and discuss relaxing in some situations, or if it's feasible we relax it in all situations 16:55:16 q+ for before end of call and start of next call 16:55:18 plinss: if you really want to ship something today, that works. or we awit for emilio 16:55:26 jensimmons: but a few weeks is um, i wish you'd said this a month ago 16:56:20 jensimmons: w3c process document, it's clear that says we have an otpoin to take a vote. only if chairs need it to break a dead lock. 16:56:43 astearns: as chair, i dont think we're at that point. we have a volunteer to get the information, which is what peter is asking for, i dont see a reason to resolve today 16:56:57 TabAtkins: if we dont make a resolution, we're not going to wait more months. the clock has run out 16:57:11 astearns: we've taken shortcuts on this to get something done quickly, and i dont think it's unreasonable to wait a few more weeks for more information 16:57:15 TabAtkins: it's not going to be a few weeks. 16:57:22 emilio: i'm saying i can look into this in the next month 16:57:34 emilio: not 6 months. i want nesting to be as good as possible 16:57:45 TabAtkins: point is, in the absence of lookahead, the group decides on option 3 16:57:50 Are we going to have another breakout at the same time next week? (I also think it would be useful to prioritize #8310, since I think it also may be a blocking issue for the entire spec... and it's an entirely different (non-parsing) issue.) 16:58:03 TabAtkins: if it's impossible, that decision stands unless we have a good reason to change it 16:58:12 TabAtkins: i dont think we should spin our wheels on otpoins 16:58:23 emilio: can we confirm lookahead is possible or impossible before chosing option 3 16:58:32 jensimmons: i'm excited you can take time to look at it in the next month 16:58:40 khush has joined #css 16:58:44 jensimmons: do agree with tab, it doesnt make difference on option 3 in the meanwhile 16:59:01 jensimmons: he's fine with 3 in the meanwhile, and if we believe lookahead is not possible, i agree with tab we're going to resolve the same way we already have 16:59:10 q? 16:59:19 +1 to jensimmons and TabAtkins 16:59:19 it’s just me :) 16:59:23 jensimmons: we've debated & requirements and we've decided no. why cant we ship 3 without a clear answer to infinite lookahead 16:59:37 plinss: why is a few more weeks so impossible? we've already waited 25 years 17:00:33 JonathanNeal: regarding the research of lookahead, i believe multiple sources have researched that there'd be separate restrictions. separate from possible or performant but it'd be a significant restriciton if grouping needed changed. 17:00:49 JonathanNeal: why cant we move forward with both? 17:01:05 plinss: current syntax hinders the css language. not a zero sum game, retrictions here vs restrictions there 17:01:18 Thank you, everyone, for allowing me to participate. 17:01:30 jonathan, help me fill yoru comments, i lost a bit of it.. 17:01:40 PaulG has joined #css 17:01:43 present+ 17:01:43 present+ 17:01:49 bradk has joined #css 17:01:58 astearns: I will propose another breakout at the same time next week. 17:02:12 Topic: Break 17:02:23 present+ 17:02:30 present+ 17:02:42 argyle: I had said that I believed it was determined infinite look-ahead meant restricting 1/3 of the recognized grouping syntaxes, which would put a significant restriction on future web compat. 17:02:49 astearns has changed the topic to: agenda: https://lists.w3.org/Archives/Public/www-style/2023Jan/0006.html 17:02:52 The rest, I think, you captured. 17:02:52 present+ 17:03:04 presebt+ 17:03:11 present+ 17:03:17 JonDavis has joined #css 17:03:42 bradk has joined #css 17:04:00 present+ 17:04:14 i'm going to get a coffee, i'll be a few 17:04:21 Just joining now. Was there a resolution? 17:05:00 no 17:05:01 present+ 17:05:05 present+ 17:06:11 present+ 17:06:37 present+ 17:06:44 Present+ 17:07:01 github-bot: take up https://github.com/w3c/csswg-drafts/issues/7551 17:07:01 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7551. 17:07:01 Topic: [css-contain-3] Inconsistent handling of known and unknown features jeopardizes backward compatibility 17:07:48 miriam: discussed before but implementers have been pushing back 17:08:08 present+ 17:08:15 miriam: issue that in CQ we are just looking to see if it resolve to true or false but that something to resolve against 17:08:44 miriam: in that finding container step we look at question ask: if looking for width we are looking for container with inline size set 17:08:51 smfr has joined #css 17:09:02 miriam: height block size, both 17:09:22 miriam: problem if when asking for width or height, it can resolve true even though half of it is recognized 17:09:37 miriam: feels fine for now, as it could become recognized later 17:09:55 miriam: as we add queries it not only changes if it resolve to true or false but also which container to look at 17:10:02 miriam: causing possible backwards compat issue 17:10:09 present+ 17:10:22 miriam: where something resolves differently whether its recognized as a query feature or not 17:10:23 miriam: 17:10:42 miriam: some vendors have shipped, so changing now is a breaking change 17:10:49 miriam: would love to resolve sooner than later 17:10:52 miriam: 17:11:00 bradk has joined #css 17:11:12 miriam: resolved previously was to split on the or [missed] 17:11:26 miriam: browsers said that would be difficult and not logic to split on or 17:11:39 miriam: other direciton sth with unknown query feature can match container 17:11:58 astearns: there is no container that can asnwer all sides of the query 17:12:00 miriam: yes 17:12:14 miriam: width or height would then not resolve 17:12:16 masonf has joined #css 17:12:18 q+ 17:12:26 zakim, open queue 17:12:26 ok, astearns, the speaker queue is open 17:12:32 q+ oriol 17:12:38 ack JonathanNeal 17:12:41 s/width or height/width or unkonwn/ 17:12:42 present+ 17:12:52 miriam: width or height would also not match 17:12:55 ack oriol 17:13:24 oriol: agree that there are problems with or. what if you have [missed] and? seems strange 17:13:54 oriol: also want to consider third option to consider: could be possible that each queried feature could evaluate to different container 17:13:55 s/[missed]/negated and/ 17:14:01 oriol: that is what we do with container units 17:14:27 astearns: not sure I understand 17:14:37 present+ 17:14:47 oriol: for example at container rule "width > 100px and height > 100px" 17:15:13 oriol: parent that only has inline size witll be able to match height. other parent would match the width query 17:15:25 oriol: might be confusing though. 17:15:34 oriol: just wanted to list for completeness 17:15:46 oriol: fine with 2nd option: if feature not recognize, just resolve as unknown 17:16:04 miriam: in the or case it could resolve on one side of the query still 17:17:27 q+ 17:17:27 oriol: we would resolve each feature against the nearest container that supports it and if there is an unknown feature that we do not support by any ancesstor then it would resolve entirely to unknown 17:17:46 bramus: a unknown is then false? 17:17:54 ntim has joined #css 17:17:57 oriol: it does not apply the rule 17:18:03 (I'm strong against resolving a single query against multiple elements.) 17:18:09 oriol: it only becomes false at the top level 17:18:19 astearns: option 3 would allow to keep prev resolution 17:18:31 astearns: would get past implementer objection? 17:19:00 q+ 17:19:02 oriol: what are the objections? probably third option more complex than option 2. havent considered if easy to implement or not 17:19:07 ack florian 17:19:17 I do feel that it's strange that @container (width > 100px) { @container (height > 100px) { ... } } is different from @container ((width > 100px) and (height > 100px)) { ...}, and I think oriol's option 3 fixes that... but it's also strange on itself, and maybe we should be thinking about use of container names as the "good practice" and these being sorts of error cases. 17:19:27 florian: I understand optoin 3 and find it interesting. fairly hard time deciding whether that is confusing to authors or not 17:19:34 florian: opens up extra possibility 17:19:49 florian: would need examples to back up any reasoning 17:19:53 ack TabAtkins 17:20:14 TabAtkins: in the discussion with anti he was having a different view of optoin 1? 17:20:35 jfkthame has joined #css 17:20:47 TabAtkins: rahter than looking at query and using that as a prefilter for containers to look at, we instead will look at each possible container and if the query can be resolved against that we will do that, otherwise unknonwn 17:20:48 s/find it interesting/find it interesting in the abstract/ 17:21:08 TabAtkins: in the case "width or height" will work on inline-size container because container can handle a part of that 17:21:26 TabAtkins: but if you do "width and height" this would fail because of the 1 unkown 17:21:27 present+ 17:21:33 TabAtkins: that was optoin 1, right? 17:21:40 miriam: no, dont think so but that could work 17:21:42 s/to authors or not/to authors or opens up a new and maybe convenient option/ 17:22:00 TabAtkins: dont really understand what antti’s understanding is so I can‘t comment on what it might mean 17:22:07 TabAtkins: but what I said is what I voted for 17:22:20 miriam: that would work, as does oriol’s proposal 17:22:40 miriam: I dont see problems with oriols proposal and potentially does match author intent 17:23:08 TabAtkins: disagree with that. you almost certainly want both conditions to match against same element, not a parent higher up 17:23:15 agrees single container evaluation makes more sense 17:23:21 TabAtkins: (mentions dbaron‘s note) 17:23:38 ack dbaron 17:23:48 TabAtkins: while you may want to target 1 element, you almost never want to target 2 17:23:52 +1 to what Tab said 17:24:22 TabAtkins: While you might sometimes want to write nested queries and target the same element both times, you probably never want to write a single query and have it target two separate elements 17:24:59 dbaron: trying to understand option 1. it seems very strange to me that you would take a query "height or width" and then evaluate against 1 part of that against 1 element and ignore the 2nd part of the query 17:25:17 dbaron: seems strange. would expect to evaluate against a single element that answers to all parts 17:25:25 TabAtkins: that’s the compat issue: unknown query 17:25:43 florian: no element 17:25:55 miriam: option 1 may have been poorly written 17:26:06 miriam: i think tab’s and oriol’s could work 17:26:13 miriam: 1 container or loosen that? 17:26:24 dbaron: could tab clarify? 17:26:26 ack fantasai 17:26:31 So then my proposal: attempt to match the queries against each possible container. If the container *can* match a given query, good; if not, it evaluates to unknown. (Unknown queries are always unknown.) Then if the top-levle result is unknown, move to the next possible container. 17:27:07 fantasai: RE 1 container or 2: it does seem weird that combining […]. if you wanted to match against single container we have explicity type argument right? 17:27:11 miriam: no, we don’t 17:27:16 fantasai: ok, all implicit 17:27:34 fantasai: if we had explicit type then author could define 17:27:43 ack dbaron 17:27:49 So (true or unknown) will match, (true and unknown) will fail to match (and stop), (false or unknown) will continue looking. 17:28:10 dbaron: auto-finding parent based on query might be bad idea. it should search using name or nearest 17:28:58 miriam: that creates other probs such as style queries where we determined that you usually want direct parent so elements are style container by default so that you can query nearest but we dont want them getting in the way of size queries. going with nearest is going to be fragile. 17:29:31 TabAtkins: my proposal is going to match nearest that can possibly match. in worst case its going to be […] right away. 17:29:37 astearns: I see couple of ways forward 17:29:45 q+ 17:29:48 astearns: resolve on tab’s reworking of option 1 or take back to issue 17:29:52 I'm OK with Tab's proposal. 17:29:54 astearns: anyone need more time to review? 17:30:07 ack oriol 17:30:12 oriol: not sure if I understand proposal; what does it mean that container matches query? 17:30:56 TabAtkins: it means that you satisfy the contditiions to potentially mathc. mainly that you have right container type. 17:31:06 oriol: how do the binary operators work? 17:31:56 TabAtkins: if you arent capable of matching, then evaluates to unkown. e.g. inline size vs width and height, one will be true/false and other unknown. if finale result at top level is unknown: skip and move up tree. if true/false: use that. 17:32:05 TabAtkins: true + unknown = skip 17:32:13 TabAtkins: true and false = false 17:32:29 florian: i am going back to issue and throwing some examples in issue 17:32:43 s/am going/would like to go/ 17:32:54 ack dbaron 17:32:55 s/throwing/throw/ 17:33:25 dbaron: weird consequence of tabs proposal: nested containers: inner one has inline and outer one haas both containmenbts. there is going to be a point where you siwtch from using inner one to outer one. that jump seems pretty weird 17:33:27 s/examples in issue/examples in issue to compare Tab's option and Oriol's/ 17:33:32 dbaron: i guess we need to work through examples 17:33:45 astearns: OK. let’s take back to issue 17:33:51 dbaron: ... to see if it does backwards jumping or not 17:34:04 I believe with Tab's logic you would choose different containers depending on whether you support 'unknown' 17:34:06 miriam: other part of this: do we need use counters as this is breaking? 17:34:08 s/would/might/ 17:34:17 astearns: good idea. put it in issue. 17:34:26 github-bot: take up https://github.com/w3c/csswg-drafts/issues/8144#issuecomment-1377651538 17:34:26 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8144. 17:34:26 Topic: [css-view-transitions-1] domUpdated isn't the right term 17:34:43 View transitions wraps a state change - we attempt generate a transition from that state change 17:34:43 The developer provides a callback where they do that change, usually by modifying the DOM in some way. It can be async. 17:34:43 Sometimes you just want to know when the state change is complete 17:34:43 We provided a promise for that,`domUpdated`, which fulfills when the promise returned by the callback fulfills 17:34:44 Anne said "we don't really expose DOM as a term to web content", so the name is bad 17:34:44 So, we need a new name 17:34:44 Couple of options: `stateUpdated` - avoids using DOM, but a bit vague, might be confusing due to frameworks use of 'state'. 17:34:45 Vlad suggested that, since the promise resolves along with the callback, we name it `updateCallbackDone`. 17:34:45 I like that, since if the developer does stuff other than DOM updating in the callback, the promise name still makes sense. 17:34:45 Anne is happy with that. 17:34:56 JakeA: I can take up this one. posted a bunch of messages above 17:35:01 dino7 has joined #css 17:36:00 +1 to suggested name change, it's clear and tied directly to what's actually happening, and I think will make sense for an author. 17:36:38 `DOMContentLoaded` ? 17:37:18 JakeA: I guess we are saying: any objections? 17:37:32 astearns: not knowing what the callback is named that seems vague. what is it? 17:37:55 JakeA: it does not have an developer visible name. authors pass it in as argument 17:38:08 JakeA: `updateCallback` and then `updateCallbackDone` 17:38:16 have not followed deeply, but seems reasonable 17:38:22 TabAtkins: I like it. makes sense and matches spec language 17:38:24 bramus: +1 17:38:44 astearns: proposed resolution: adopt suggested change to rename to `updateCallbackDone ` 17:38:50 RESOLVED: adopt suggested change to rename to `updateCallbackDone 17:39:08 github-bot: take up https://github.com/w3c/csswg-drafts/issues/616 17:39:08 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/616. 17:39:08 Topic: [css-text-4] Hyphenate only overflowing words? 17:39:16 s/`updateCallbackDone /`updateCallbackDone` 17:39:24 https://github.com/w3c/csswg-drafts/issues/616#issuecomment-1368091416 17:39:35 fantasai: link to comment 17:39:51 fantasai: can you turn on hyphenation but only if it overflows? 17:39:55 fantasai: 17:40:22 fantasai: we could do this by adding keyword to overflow-wrap or hyphens property 17:40:41 fantasai: hyphens controls hyphentation. values none/manual/auto 17:40:58 fantasai: overflow-wrap controls what you are going to do with overflow 17:41:12 fantasai: want to know if we want this addition and which one we prefer 17:41:18 q+ 17:41:26 astearns: fine with adding. slight preference for value in hyphens 17:41:32 ack florian 17:42:08 florian: opposite slight preference for adding to overflow-wrap. but otoh hyphens prop also related of course 17:42:18 q+ 17:42:59 ack jfkthame 17:43:03 florian: between line-break/word-break/overflow-wrap, lots of properties. [missed] adding extra keyword to that property keeps it that way. 17:43:05 q+ 17:43:52 jfkthame: not sure if this is a good idea. its a very specific property. we already have other properties for authors, e.g. hyphenate-limit-zone 17:44:17 astearns: you propose to setting that property to something close of width to only allow hyphentation in overflow cases? 17:44:25 ack jensimmons 17:44:29 jfkthame: i think it would have that effect 17:44:42 jensimmons: seems like a valid use case. 17:45:03 jensimmons: I can see ppl putting this in their default stylesheets and turning it on for everything. not sure on how exactly to do it 17:45:21 fantasai: we should take back and check with hyphenate-limit-zone 17:45:29 florian: same 17:45:45 astearns: let’s take back to issue with jfkthame’s proposal 17:45:49 github-bot: take up https://github.com/w3c/csswg-drafts/issues/2462 17:45:49 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/2462. 17:45:49 Topic: [css-text-4] Propose 'text-spacing: space-first' (trim-start-except-first-line) as a normal behavior 17:46:07 fantasai: there are new comments on the issue. maybe skip for today? 17:46:18 florian: I think the comments support it, no? 17:46:26 florian: can wait 17:46:36 fantasai: there re comemnts that it might not work as well for chinese 17:46:54 florian: yeah, but it says 'it is not ideal' but what is ideal? 17:47:02 florian: can take a few days to reconsider 17:47:12 astearns: let’s go on to next issue 17:47:14 https://github.com/w3c/csswg-drafts/issues/2462#issuecomment-1367692407 17:47:25 florian: people who care about this should read from [link] down 17:47:44 astearns: please all take a look 17:47:45 github-bot: take up https://github.com/w3c/csswg-drafts/issues/5703 17:47:45 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5703. 17:47:45 Topic: [css-text-4] Re-use justify-content instead of text-group align? 17:48:11 jensimmons: I can describe 17:48:20 jensimmons: text-wrap is a property and balance is value for it 17:48:52 jensimmons: it enables to do balanced text for text that spans multiple lines 17:49:41 -> https://www.w3.org/TR/css-text-4/#text-group-align-property 17:49:44 jensimmons: text-group in text level 4 is the new property to accomplish that use case 17:49:57 jensimmons: do we need this new property or should we use justify-content? 17:50:00 -> https://www.w3.org/TR/css-align-3/#align-justify-content 17:50:38 ntim: makes sense to reuse justify-content 17:50:54 ntim: [missed] 17:51:22 iank_: justifty-content will start new formatting context, right? 17:51:24 fantasai: yes 17:51:32 iank_: so that is one relative difference between the two 17:51:39 fantasai: we could define it to not do that 17:51:52 iank_: would align-content be harmonized? 17:51:59 fantasai: that one needs it 17:52:30 fantasai: in terms of inline-axis one thing that gets weird when we don}t create formatting context: what happens when we have floats? 17:52:43 fantasai: (gives example) 17:52:56 florian: I think it’s good to create the formatting context 17:53:10 florian: then floats dont do strange things 17:53:23 s/(gives example)/for floats inside the box it's straightforward, but if floats are intruding from the parent... it gets weird/ 17:53:36 astearns: questoins about formatting contexts and floats are questions for either new property or the existing property 17:53:44 iank_: float question falls into two sub questions 17:53:54 iank_: would make easier if floats dont intrude from outside 17:54:30 iank_: how floats withing that ifc interacts is another question. 17:54:57 florian: i think alan is right that that concern applies to both properties 17:55:09 iank_: I want to point out formatting context difference. 17:56:00 fantasai: I thiknk what florian is trying to say: either way since neithe rpropert is implemented right now, we can decide what to do. question applie sto both properties 17:56:13 iank_: slight forward compat risk with reusing justify-content 17:56:17 fantasai: less concerned about that 17:56:39 fantasai: currently when you have a bunch of line boxes they [missed] in container. we have to tell those boxes to be shortened 17:57:25 s/ they [missed] in/ they fill in/ 17:57:48 fantasai: and then there is this fun interaction with line boxes. say i have a div and center it. in order for it to be centered we have to shorten line boxes. that is striaghtfowrad if boxes are directly contained by div. what if that div contains other divs? 17:58:09 fantasai: do we some kind of propagation? do we inherit? do we not affect any of the child divs? etc. 17:58:27 fantasai: with justify-content there is more of a consensus that you lay out all children as a unit 17:58:28 justify-content creating a new formatting-context is a relatively large compat risk IMO 17:58:36 fantasai: [missed] 17:58:47 fantasai: so it will not have any effect of centering the text. 17:59:37 iank_: if that list is shortening all the line boxes that [missed] 17:59:47 astearns: seems like issue that is going to come up for either version of the property 18:00:02 astearns: can we resolve on using justify-content or not? 18:00:28 iank_: compat risk is making justify-content establish a new formatting context 18:00:39 iank_: things suddenly become fc when they were not previously 18:00:52 florian: assuming people already use this property 18:00:54 iank_: exactly 18:01:06 specifically to blocks that are not already BFCs 18:01:09 florian: can we have a use counter to check? 18:01:34 iank_: i think apple folks are more interested in shipping 18:02:02 astearns: should prioritize whether we should create new fc or not and use that info to decide if we reuse property or go with proposed thing 18:02:23 florian: yes [missed] 18:02:28 astearns: we are at time 18:02:41 astearns: lets take back to github 18:02:58 astearns: most likely need more discussion on compat issue 18:03:12 s/yes [missed]/yes, though we might still be able to go with justify-content even if we want a fc depending on the compat situation/ 18:03:32 github-bot: end 18:03:32 astearns, Sorry, I don't understand that command. Try 'help'. 18:03:40 topic: end 18:22:01 trackbot, end meeting 18:22:07 zakim, end meeting 18:22:07 As of this point the attendees have been lea, dbaron, plinss, futhark, lukedary, argyle, JonathanNeal, ydaniv, oriol, castastrophe, bramus, JakeA, GameMaker, emilio, jensimmons, 18:22:10 ... miriam, flackr, tantek, PaulG, chrishtr, bradk, dholbert, masonf, TabAtkins, jfkthame 18:22:10 RRSAgent, please draft minutes 18:22:11 I have made the request to generate https://www.w3.org/2023/01/18-css-minutes.html Zakim 18:22:18 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 18:22:18 Zakim has left #css 18:53:40 github-bot has joined #css 20:42:33 projector has joined #css 20:43:04 leaverou has joined #css 20:43:35 Rossen has joined #css 20:44:04 shans has joined #css 20:44:35 sylvaing has joined #css 21:50:44 antonp has joined #css 23:15:29 karlcow has joined #css