Re: [csswg-drafts] [css-conditional] choose names for keyword-based feature queries in @supports and names for initial set of queries (#9875)

I suppose the comment in question is https://github.com/w3c/csswg-drafts/issues/3559#issuecomment-1924521929 by @JoshuaLindquist.  Given that we wanted to move the naming discussion here, I'll try to reply here:

> Is there a reason the previous suggestions list the display type last? It seems more intuitive to me to have keywords that list the display type first and then follow it with the requested feature.

I think the reason for listing the display type last is that it's about querying for a combination that involves a feature *on* a particular display type.  I think the normal English way of expressing that is "feature-on-display-type"; I don't see a clear way of expressing it in the other order that expresses that it's the combination of features.

> Using `feature()` is not my favorite solution.
> 
> Since the current resolution is to implement keywords only on rare occasions (1 a year, per the log) and to make it easy to educate everyone to use with minimal confusion, I think it would be better to use a keyword that screams "this is a very special use case" rather than a generic term like `feature()`. I think using `feature()` sets a reasonable expectation that you can check for any set of CSS features, and it will cause confusion when it doesn't work that way.
> 
> Even something like `case()` or `keyword()` or just `key()` seems better to me (though I don't love any of those).

I think `case` or `keyword` or `key` make it less clear what the argument to the function is.  Do you think `named-feature()` would make this clearer than `feature()`?

-- 
GitHub Notification of comment by dbaron
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9875#issuecomment-2139473822 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 30 May 2024 12:43:04 UTC