- From: Peter Linss via GitHub <sysbot+gh@w3.org>
- Date: Thu, 01 Dec 2022 02:36:46 +0000
- To: public-css-archive@w3.org
> My point wasn't "there is precedent for this bad thing and thus it's fine", it was "CSS already does this and authors don't seem to have any trouble googling things". So I don't think the TAG principle you linked applies here. Learnability is one component of usability, efficiency is another, equally important one. For commonly typed things, brevity becomes more important than learnability. CSS has rejected other uses of sigils in the past for precisely the searchability issue, and it's not necessarily obvious to an author to search for 'ampersand' instead of `&`. Brevity can be taken too far (see YAML), it is a tradeoff, but not an obvious one. And given that `@nest` mostly doesn't require the `&` it can easily result in less typing if there are enough nested rules, so proposal 3 doesn't necessarily win on brevity. > @supports selector(&)? Maybe, but seems fragile, what if there are other places `&` can be used? (and is it *really* a selector?) -- GitHub Notification of comment by plinss Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7970#issuecomment-1333075792 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 1 December 2022 02:36:48 UTC