- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Apr 2023 17:18:57 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Unknown`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Unknown<br> <fantasai> astearns: plinss's suggestion is we put the lookahead version into the spec<br> <fantasai> ... and remove references that we had to parts that we had based on old parsing mode<br> <fantasai> ... is that a way forward?<br> <fantasai> TabAtkins: that's exactly what I want to do<br> <fantasai> astearns: so can we resolve the problem by saying that we'll specify the new parsing-enabled version only?<br> <fantasai> plinss: I'm uncomfortable with that, depends how we phrase it<br> <fantasai> plinss: I'm thrilled that lookahead proved viable. I think this should take Option 3 off the table.<br> <fantasai> ... we should ship with lookahead, or something else entirely<br> <fantasai> ... I don't care if there's one STP or whatever that shipped differently, but what we spec<br> <fantasai> TabAtkins: I agree completely<br> <fantasai> jensimmons: I don't<br> <fantasai> plinss: I still think there are issues with lookahead, but it's far better than Option 3<br> <fantasai> ... I won't FO provided that we take a step back and review all the advantages/disadvantages<br> <fantasai> ... and reconsider all the options<br> <fremy> fwiw, the lookahead option would satisfy me<br> <fantasai> ... and look at the big picture<br> <fantasai> ... and whatever we decide as a group, I'll be fine with<br> <fremy> fremy: my concern was that copy and paste would not be viable, but with lookahead it is<br> <fantasai> jensimmons: I am disappointed that plinss is once again making demands that we do what he wants, and assures us that if we do he'll be OK<br> <fantasai> plinss: I haven't changed my position<br> <fantasai> ... I'm demanding that we follow the process and make rational decisions<br> <fantasai> jensimmons: What is happening is that browsers have implemented what was specified, and are moving forward despite the situation we've found ourselves in in the past several months<br> <fantasai> ... and I'm a believer that as we evolve CSS and take an idea, work through it, implement and ship it, evolve it, continue to add more to it or make it better, and implement and ship the newer version<br> <fantasai> ... we have a method to do this, we have levels for specifications<br> <fantasai> ... and we keep a trail as we go so browsers can make interoperable implementatoins<br> <fantasai> ... I don't want to obliterate the spec, because it is shipping. I would like to write up Level 2<br> <fantasai> ... and browsers can ship that as it's possible to do<br> <fremy> -1 because they are not compatible<br> <TabAtkins> (we have a working draft https://www.w3.org/TR/css-nesting-1/)<br> <fantasai> plinss: we don't have a spec for that, browser shipped outside the W3C process<br> <fantasai> jensimmons: that's your opinion, don't want to fight about it<br> <fantasai> plinss: we had contention and two browsers shipped anyway<br> <fantasai> ... we have no obligation to spec retroactively<br> <fantasai> astearns: We are out of time<br> <fantasai> astearns: I would point out that we do have a process for asking the WG "are you ready to ship", and that was not followed in this case<br> <TabAtkins> We do in fact have an obligation to spec reality. We can try to *nudge* reality, but we're not writing fiction.<br> <fantasai> ... but we'll have to leave this open. We can have another breakout next week.<br> <TabAtkins> And we *did* try to follow process, the process was dragged out over several browser's explicit requests to resolve it.<br> <fantasai> ... Would like ppl to add comments to the issues so we can hash this out and not have new arguments on the call<br> <fantasai> Meeting closed.<br> <TabAtkins> The process (the WG) failed to work effectively, and was routed around.<br> <TabAtkins> And now we're dealing with the consequences. Luckily I made sure that what we went with was compatible with the ideal future, so now moving to the ideal future is easy.<br> <plinss> And sometimes the process takes longer than people want, but that's still the process, routing around it does not supersede the process<br> <fremy> To be fair, I will argue the process worked properly here. Without objections, we would not have the lookahead version. It was deemed impossible. Only when so much pushback happened was it properly tested.<br> <astearns> +1 fremy<br> <fremy> I think the process yielded a better outcome, but unfortunately some lost faith before it reached its course<br> <fremy> It's understandable, I would have wanted to ship this too if I was the PM<br> <fremy> No blame handed out<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/8249<br> <fremy> But I think the "work around" was not optimal, here<br> <fantasai> s/Unknown/Nesting Syntax/<br> <TabAtkins> fremy: The "workaround" was required, because the chairs allowed one threatened objection to indefinitely delay resolution. That was, itself, a violation of process, as Jen pointed out in an earlier call when she *cited* the Process and asked for a vote to resolve the logjam, and was rejected by the chairs.<br> <TabAtkins> More generally, the Process is an way of working toward interop, not a suicide pact. We abide by it because it generally produces good results, and is a useful schelling fence to ground discussions with. But we very intentionally do not *require* W3C signoff on shipping code in Chrome.<br> <fantasai> Dude, not only do you to require it, you don't even *ask* for it, even when it would be useful for the CSSWG to have that discussion and even when you would get it. It's really obnoxious.<br> <fantasai> s/require/not require/<br> <fantasai> You ask for TAG signoff, but don't care to ask the CSSWG.<br> <fantasai> Even when the CSSWG would actually have more useful input.<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-1497853173 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 April 2023 17:18:59 UTC