- From: Peter Linss via GitHub <sysbot+gh@w3.org>
- Date: Fri, 20 Jan 2023 00:27:01 +0000
- To: public-css-archive@w3.org
> I'm strongly against a "mandatory &" - nothing is helped by requiring an & somewhere. (That is, div > & satisfies this but is still problematic in such a world, while > div has no problems but is mysteriously disallowed by such a restriction.) I don't understand where this suggestion is coming from or in what way it would help us. I'm against that as well, but that's not what's being proposed here. > The only reason it would make sense to impose such a restriction is we think that, when we determine that lookahead is infeasible, we'll scrap all the preceding resolutions and re-evaluate the entire issue fresh. But we're not going to! 1) 'we're not going to!' isn't your call, that's the chairs' call, and other group members are well within their rights to ask that these decisions be revisited. 2) while all the previous decisions were made with the assumption that lookahead wasn't possible, they didn't take into account all the pitfalls of the solutions at the time. Yes Tab, I'm aware that you said that *you* did, and I accept that, I also accept that others involved in coming up with the solutions that led to the current option 3 syntax did as well, however those pitfalls were absolutely *not* part of the discussions with the whole group when the resolutions were made[1]. They also weren't mentioned in the public polls. So yeah, if lookahead isn't possible, we **do** need to revisit at least some of the previous decisions given the new information. If lookahead is doable, then that's all moot and there's no point revisiting those. Given the degree of contention, and emotions running high, it might be best to avoid going there if we can by simply waiting a few weeks for the lookahead investigation. If it's determined that the lookahead research is going to take longer than people are willing to wait (which has not been determined yet), then shipping a partial solution that always requires some kind of prefix is the safest bet. Because if we determine that lookahead can't work, and if we revisit the prior decisions and decide that an optional prefix isn't actually the best path forward after all, then we haven't painted ourselves into a corner by shipping something prematurely. We can always make at least some of the mandatory prefixes optional, but we can never make optional prefixes mandatory without breaking content. I also have yet to see any justification as to why this needs to be rushed. If there's a real need to push a solution out the door ASAP, then there should be justification for prioritizing the lookahead research work. [1] for example, when I mentioned some of the language evolution tradeoffs, people were surprised. -- GitHub Notification of comment by plinss Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1397778886 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 20 January 2023 00:27:03 UTC