- From: Peter Linss via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Jan 2023 22:50:15 +0000
- To: public-css-archive@w3.org
To be clear, my objection comes from shipping option 3 without knowing if we can relax the lookahead restriction or not. Because if we can't, it carries the syntax restrictions, is an author foot-gun, and only satisfies significantly less than 50% of the use cases (vs a mandatory prefix). I don't feel the benefits outweigh the costs. If we covered 100% of the use cases then the math might work and it'd be worth it, but we're not there. I'm fine with shipping a solution (like @bramus's suggestion) where a prefix is required for now, and we can make the prefix optional in the future if lookahead proves viable, or we can decide to make it optional in some cases later if lookahead proves to be impossible (essentially morphing it into option 3 or some flavor with limited lookahead and more options to omit the prefix). I'm also fine with shipping option 3 as-is, as soon as we know for a fact that look-ahead is viable, as an interim step until full lookahead can be implemented, because all the down-sides are temporary. (I personally don't think it would be worth shipping, but I wouldn't object to it.) Every solution so far is compatible with adding lookahead later and simplifying the syntax. And frankly, even if/when full lookahead ships, it might still be beneficial to also have an optional prefixed syntax for authors who want to make their stylesheets more clear (though I wouldn't be bothered if we didn't). -- GitHub Notification of comment by plinss Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1396198517 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 22:50:17 UTC