- From: inoas via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Jan 2018 02:31:20 +0000
- To: public-css-archive@w3.org
*If* my last comment is true, that would leave us with: * `:nospecificity()` - Agreed that it is hard to type and leaves no option to add specificity features later on * `:filter()` - I rather much would have the same word in different contexts doing different things (as expected), than logical pairs of words doing something else (`:is()` vs `:not()`). * `:when()` - I don't think the interpretation as only "time" related is a problem @LeaVerou? [LESS](http://lesscss.org/features/#mixin-guards-feature), [Elixir](https://hexdocs.pm/elixir/master/guards.html#why-guards) and [PostgreSQL](https://www.postgresql.org/docs/9.4/static/functions-conditional.html) use it for logical conditions just fine, so why is ":when sounds time-related" a problem? *So these are all sane options without creating unexpected developer pain*: 1. Use `matches()` for the new implementation and rename current `matches()´ implementation in the wild to `is()` - Issue: Vendor Safari has to adapt. 2. Use `when()` for the new implementation and alias current `matches()´ to `is()` and deprecate `matches()` - **No Issue**. 3. Use `filter()` for the new implementation and alias current `matches()´ to `is()` and deprecate `matches()` - Small Issue: re-use of the same word in different context means it does different things. -- GitHub Notification of comment by inoas Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-354926023 using your GitHub account
Received on Wednesday, 3 January 2018 02:31:24 UTC