- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Jan 2023 17:02:15 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-nesting] Problem with mixing properties and selectors`.
<details><summary>The full IRC log of that discussion</summary>
<JakeA> oh a link is even more handy :D<br>
<argyle> astearns: peter do you want to summarize and start<br>
<argyle> plinss: i have several concerns, most are aware of them, we can review what we need to<br>
<argyle> plinss: my best path forward is relax and do the sass syntax and require prefix nowhere. we need to explore that<br>
<argyle> 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<br>
<TabAtkins> q+<br>
<argyle> plinss: we have soemthing that hasnt been considered or discussed, i'm asking we do that first<br>
<argyle> astearns: we experiment, get some data, is feasible is performant enough<br>
<fantasai> s/especially controversial/especially because it's controversial/<br>
<argyle> plinss: we added this restriction 25 years ago, and i wasnt convinced we needed it back then<br>
<Rossen_> q?<br>
<argyle> 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?<br>
<dbaron> This was explored a bit in https://github.com/w3c/csswg-drafts/issues/7961<br>
<astearns> ack TabAtkins<br>
<argyle> TabAtkins: as ive said in the thrads a few times, the current proposal is the most ameniable to look ahead in the future<br>
<fantasai> s/fromt he tag/from a developer/<br>
<argyle> TabAtkins: in t he future, it would just b e removal of some restrictions<br>
<fantasai> s/lea and i/TAG and Lea and I/<br>
<fantasai> s/thrads/threads/<br>
<plinss> q+<br>
<argyle> TabAtkins: we could walk or drop back to achieve this. 2 ways forward, restrictive at first<br>
<argyle> if we go with any other solution and later upgrade look aheda, we'll have ways of writing. wierd way and correct way.<br>
<argyle> 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<br>
<fantasai> s/if we/TabAtkins: if we/<br>
<fantasai> s/if we/TabAtkins: if we/<br>
<fantasai> s/is()/:is()/<br>
<argyle> 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.<br>
<futhark> q+<br>
<argyle> 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)<br>
<argyle> 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<br>
<argyle> TabAtkins: sorry y'all community, we'll continue to push it away for N months<br>
<argyle> 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<br>
<JonathanNeal> When we talk about Sass style nesting, I think it’s important we distinguish which features of Sass style nesting we would be copying.<br>
<argyle> 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.<br>
<JonathanNeal> 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.<br>
<lea> JonathanNeal: The ones that don't involve concatenating within tokens :)<br>
<argyle> 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<br>
<fantasai> 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<br>
<argyle> TabAtkins: it is infinite lookahead, because you can have unlimited ambiguous lookahead<br>
<astearns> ack plinss<br>
<lea> q?<br>
<argyle> 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.<br>
<argyle> 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.<br>
<fantasai> lea, like "article { section h3 { ... } }", it can map to "section article h3" and that's not generally expected<br>
<lea> q+<br>
<TabAtkins> (fantasai, i think you mean `article h3 { section & {...}}`<br>
<TabAtkins> )<br>
<argyle> 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<br>
<jensimmons> q+<br>
<argyle> plinss: so that is the safer approach. again, i dont want to tangent until we determine is the experiment viable<br>
<argyle> if it's weeks, lets wait a few weeks<br>
<lea> fantasai: yup, that's a separate issue on the agenda, right?<br>
<argyle> 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<br>
<astearns> ack futhark<br>
<TabAtkins> q+<br>
<argyle> 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<br>
<argyle> futhark: being able to throw away tokens helps us with memory<br>
<fantasai> s/peak memories/high peak memory usage/<br>
<plinss> q+<br>
<argyle> futhark: for us we'll know the problems with infinite lookahead, we'll need to go back to something similar we had before<br>
<argyle> futhark: another issue is, the block stack doesnt need a snapshot in order to restart the parsing for a property<br>
<argyle> futhark: i dont think it's a matter of days, in chrome, it's definitely weeks at least<br>
<argyle> plinss: first of all, yes it's theoretically infinite look ahead, the average will be small. not a cost you pay all the time<br>
<argyle> plinss: only cost with obscenely long selectors<br>
<argyle> plinss: this is an experiement. you dont have to make production code, you can quick hack and try it out<br>
<argyle> 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.<br>
<argyle> plinss: may take months to perfect, but an experiement could take hours or days<br>
<lea> (fyi the algorithm plinss is describing is what I proposed in #7961)<br>
<astearns> ack JonathanNeal<br>
<oriol> Note custom properties can contain {<br>
<argyle> JonathanNeal: ty lea what i'm going to bring up in the chat already<br>
<lea> q?<br>
<argyle> 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<br>
<argyle> concatenation. .<br>
<fantasai> s/mute/moot/<br>
<fantasai> s/mute/moot/<br>
<argyle> plinss: for clarity, i mean not requiring prefixing, not necessarily the other features. separate discussiont o follow it 100%<br>
<astearns> ack lea<br>
<argyle> 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.<br>
<argyle> lea: reason i'm on the queue, if we assume infinite lookahead is possible, how could we decide around this unknown.<br>
<argyle> 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.<br>
<argyle> lea: if option 3 depends on lookahead, then sure we can wait like peter said<br>
<lea> 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.<br>
<fantasai> s/argyle/lea/<br>
<argyle> lea: 2nd, if it is possible, it doesnt automatically solve the problem. we can make & optional. lea just pasted it<br>
<JonathanNeal> I write things down in advance, too. And I still fumble every time. :)<br>
<argyle> 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<br>
<argyle> 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<br>
<argyle> lea: looks like these are fairly uncommon, but would restrict some cases<br>
<Rossen_> q?<br>
<argyle> 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<br>
<argyle> TabAtkins: i'm writing the rules of thing we'd run into while we do these minites<br>
<argyle> lea: would be nice if the issue was updated<br>
<bramus> Don’t people drop JSON in custom props? I know I’ve done before 🙈<br>
<fantasai> s/while we do these minites/I'll paste it in a few minutes/<br>
<astearns> ack jensimmons<br>
<plinss> q-<br>
<argyle> 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<br>
<argyle> jensimmons: this idea its easy and is only a couple hours, is honestly kinda insulting. it's nto easy, it will take weeks<br>
<argyle> jensimmons: a hacky quick, yeah of course, we can of course do that, the quetion is, at what perforamnce cost?<br>
<argyle> jensimmons: a quick hacky edperiement doesnt answer that questoin, a deeper dive is required to see the impact<br>
<lea> everyone values performance, no?<br>
<argyle> 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<br>
<JonathanNeal> Would anyone know — does the GitHub issue already address selectors like `color-scheme:nth-child`...?<br>
<plinss> q+<br>
<argyle> jensimmons: we wont know how long that effor takes until we have an answer<br>
<fantasai> JonathanNeal, yes<br>
<argyle> jensimmons: or we keep going and the perf is trash, until we decide it's not viable<br>
<JonathanNeal> fantasai: thank you<br>
<bramus> q+<br>
<fantasai> JonathanNeal, that's the problem, fundamentally -- the overlap in syntax between selectors and property declarations<br>
<lea> q?<br>
<argyle> 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.<br>
<argyle> jensimmons: we have a implementations and a spec, we have an option 3 soltion that web developers are thrilled about<br>
<JonathanNeal> 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.<br>
<TabAtkins> Here's the proposed parsing: https://gist.github.com/tabatkins/6c230f0ce612d80979e4a4bdfa7ee489<br>
<argyle> 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<br>
<argyle> 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<br>
<argyle> plinss: 2nd, we've aalready settled on option 3, we havent, i'm an objection. we got to that point by widdling down options.<br>
<argyle> 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<br>
<JonathanNeal> 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<br>
<argyle> 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.<br>
<argyle> jensimmons: 2, i did not say we settled, i said we have broad consensus.<br>
<emilio> I volunteer to explore the nesting w/ unlimited lookahead in Gecko in the next month, fwiw<br>
<lea> q+<br>
<argyle> 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.<br>
<argyle> plinss: at least we tried to settle it quickly, and i dont think that's unreasonable<br>
<astearns> ack TabAtkins<br>
<emilio> q+<br>
<plinss> q-<br>
<plinss> q+<br>
<JonathanNeal> Re: "Non-custom properties can never contain top-level {}-blocks". Pouring one out for Custom Property Sets.<br>
<argyle> 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<br>
<argyle> discussion, we should work under the assummption we'll make the sasme decision<br>
<argyle> TabAtkins: either now, infinite lookahead or current spec. reminder, we can convert option 3 to infinite lookahead<br>
<argyle> TabAtkins: i dont think we're going to throw away consensus we've acquired so far<br>
<argyle> 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<br>
<argyle> 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.<br>
<argyle> 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<br>
<jensimmons> I agree with Tab that we've already figured out what we want to do without lookahead.<br>
<JonathanNeal> I think denying top-level blocks to declarations feels harsh to me.<br>
<argyle> TabAtkins: i agree, the current spec has no author visible changes if we go with infinite lookahead<br>
<fantasai> s/lookahead/lookahead, other than allowing selectors to start with a tag selector/<br>
<JonathanNeal> But I admit it’s never really been tested. There is nothing like an `aria: { selected: true }` shorthand declaration.<br>
<jensimmons> 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<br>
<argyle> 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.<br>
<argyle> plinss: if we're going to go there, it's a bigger decision. we dont have to go there if lookahead is feasible<br>
<TabAtkins> That is 100% wrong, we considered the language-evolution concerns all thruout.<br>
<Rossen_> q?<br>
<argyle> 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<br>
<argyle> plinss: we dont have to have this debate, if infinite lookahead is feasible<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to respond to peter<br>
<JonathanNeal> 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.<br>
<argyle> 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.<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1362033982<br>
<argyle> fantasai: the css language cutoff is very small, we're not causing any future problems. i dont see a real problem with future compat<br>
<argyle> 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<br>
<bramus> q-<br>
<astearns> ack bramus<br>
<astearns> ack lea<br>
<argyle> 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<br>
<argyle> lea: do not this doesnt fix all the lookahead issues<br>
<JonathanNeal> appreciate that comment, fantasai, and strongly agreed as someone who has worked with/on multiple user-land parsers.<br>
<argyle> lea: makes more sense to be mandatyory at first, later not. instead of it's kinda mandatory, not it's totally optional<br>
<bramus> Would be difficult to feature detect, no?<br>
<argyle> lea: seems like a more reasonable progressions. i could still stand by 3 if lookaheda is not possible<br>
<argyle> lea: but if lookahead is somewhre down the line, i'd prefer this kind of progression<br>
<argyle> TabAtkins: required the & doesnt fix infinite lookahead<br>
<argyle> TabAtkins: we can't make it mandatory. that means parsing requires looking in the future we is the exact thing we're discussing.<br>
<argyle> lea: we can make it mandatory in addition to option 3<br>
<argyle> lea: & mandatory with all descendants<br>
<jensimmons> I don't think that's easier for devs — to have & .foo and :is(article) & ... that's confusing<br>
<JonathanNeal> This break is brought to you by Coffee and Cheetos.<br>
<lea> 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)<br>
<fantasai> s/argyle/lea/<br>
<argyle> plinss: how long will it really take to test lookahead? still feels unanswered<br>
<argyle> TabAtkins: it'll likely be months, but we do have someone for Q2 or Q3.<br>
<astearns> ack emilio<br>
<emilio> oh, no mic<br>
<emilio> sigh<br>
<plinss> q-<br>
<Rossen_> q+<br>
<Rossen_> q-<br>
<bramus> q+<br>
<emilio> Anyways, I was going to say that I can explore this in the coming months or so<br>
<Rossen_> q+<br>
<astearns> ack Rossen_<br>
<emilio> I can set some time aside for this<br>
<argyle> 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<br>
<argyle> 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<br>
<argyle> 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.<br>
<fantasai> s/mute/moot/<br>
<argyle> 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<br>
<astearns> ack emilio<br>
<argyle> emilio: i can set some time aside and try infinite lookahead this month or so? that useful?<br>
<argyle> astearns: yea i think so<br>
<argyle> astearns: that would be a timeline folks would respond well to<br>
<plinss> q+<br>
<argyle> 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<br>
<jensimmons> q+<br>
<Rossen_> +1 to having look-ahead eval before option 3 go-live<br>
<argyle> 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<br>
<JonathanNeal> 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.<br>
<astearns> ack bramus<br>
<matthieudubet> should we define what is "acceptable" for performance regarding unbounded lookahead (1% perf regression on speedometer?)<br>
<TabAtkins> JonathanNeal, not sure what you mean<br>
<argyle> 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?<br>
<JonathanNeal> I am referring to “Non-custom properties can never contain top-level {}-blocks”, TabAtkins.<br>
<argyle> 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<br>
<argyle> bramus: that minimal version can relax to either<br>
<argyle> 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<br>
<argyle> astearns: confirm that useful<br>
<JonathanNeal> To me, restricting 1/3 of the recognized grouping syntaxes would put a significant restriction on future combat.<br>
<astearns> ack plinss<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<Rossen_> 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)<br>
<argyle> 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<br>
<argyle> 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<br>
<astearns> ack jensimmons<br>
<argyle> jensimmons: processing what peter just said<br>
<argyle> 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<br>
<argyle> 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<br>
<florian> q?<br>
<florian> q+<br>
<argyle> 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<br>
<Rossen_> q+ for before end of call and start of next call<br>
<argyle> plinss: if you really want to ship something today, that works. or we awit for emilio<br>
<argyle> jensimmons: but a few weeks is um, i wish you'd said this a month ago<br>
<argyle> 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.<br>
<argyle> 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<br>
<argyle> TabAtkins: if we dont make a resolution, we're not going to wait more months. the clock has run out<br>
<argyle> 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<br>
<argyle> TabAtkins: it's not going to be a few weeks.<br>
<argyle> emilio: i'm saying i can look into this in the next month<br>
<argyle> emilio: not 6 months. i want nesting to be as good as possible<br>
<argyle> TabAtkins: point is, in the absence of lookahead, the group decides on option 3<br>
<dbaron> 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.)<br>
<argyle> TabAtkins: if it's impossible, that decision stands unless we have a good reason to change it<br>
<argyle> TabAtkins: i dont think we should spin our wheels on otpoins<br>
<argyle> emilio: can we confirm lookahead is possible or impossible before chosing option 3<br>
<argyle> jensimmons: i'm excited you can take time to look at it in the next month<br>
<argyle> jensimmons: do agree with tab, it doesnt make difference on option 3 in the meanwhile<br>
<argyle> 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<br>
<Rossen_> q?<br>
<florian> +1 to jensimmons and TabAtkins<br>
<JonathanNeal> it’s just me :)<br>
<argyle> jensimmons: we've debated & requirements and we've decided no. why cant we ship 3 without a clear answer to infinite lookahead<br>
<argyle> plinss: why is a few more weeks so impossible? we've already waited 25 years<br>
<argyle> 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.<br>
<argyle> JonathanNeal: why cant we move forward with both?<br>
<argyle> plinss: current syntax hinders the css language. not a zero sum game, retrictions here vs restrictions there<br>
<JonathanNeal> Thank you, everyone, for allowing me to participate.<br>
<argyle> jonathan, help me fill yoru comments, i lost a bit of it..<br>
<dbaron> astearns: I will propose another breakout at the same time next week.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1387406048 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 January 2023 17:02:17 UTC