[css-conditional] choose names for keyword-based feature queries in @supports and names for initial set of queries

[dbaron]

In #3559 (comment) we resolved to:

• adopt keyword based feature queries, with the expectation that we will use them rarely and test and message their addition carefully
• add a keyword for alignment on blocks

as proposed in #3559 (comment), with the names to be decided later.

As noted there, the names that I initially proposed were feature() and align-justify-properties-on-blocks. Other names for the keyword that were suggested during the discussion were align-content-on-block and align-content-block-flow.

What should we call these two things?

[dbaron]

Added Agenda+ to give a quick reminder for people to make suggestions in this issue, although maybe we have a better way to do that?

[dbaron]

On second thoughts, maybe it's better to just propose a resolution to prompt the discussion if anyone disagrees with that proposal:

Proposed resolution: Call the query function feature()
Proposed resolution: Call the keyword for CSS alignment on blocks align-content-on-display-block

(That said, at this point it's now already a little bit late, since Chrome has already shipped align-content on display: block.)

[astearns]

@dbaron I see comments on #3559 arguing against feature() - do you have responses to those concerns?

I think I’d like to see a few more people say yea or nay to your proposed resolution here before we try the async resolution route.

[dbaron]

I suppose the comment in question is #3559 (comment) 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()?

[css-meeting-bot]

The CSS Working Group just discussed [css-conditional] choose names for keyword-based feature queries in @supports and names for initial set of queries, and agreed to the following:

• RESOLVED: use `named-feature()` as the function name
• RESOLVED: call the keyword `align-content-on-display-block`

The full IRC log of that discussion

<TabAtkins> dbaron: About six months ago we had a discussion about adding a mechanism for one-off things in @supports that don't have an existing structure to fit in
<TabAtkins> dbaron: To solve some known problems that would otherwise be complicated to deal with.
<TabAtkins> dbaron: We resolved to do it, but not on what to call the things
<TabAtkins> dbaron: I opened an issue about naming, it has not had much discussion, but I have proposed names in the issue
<TabAtkins> dbaron: There was a bunch of disagreement about naming the last time we discussed it
<TabAtkins> dbaron: It seems like the sort of thing that might be easier in an issue but nobody was commenting, so telcon it is
<TabAtkins> dbaron: proposal is to call the query fucntion `feature()`
<TabAtkins> dbaron: And calling the feature for css alignment on blocks as `align-content-on-display-block`
<TabAtkins> dbaron
<TabAtkins> dbaron: I'm okay with resolving today or taking it back to the issue, as long as someone actually comments in the issue
<TabAtkins> astearns: The bit that's possibly not changeable is...
<TabAtkins> dbaron: It just might be less useful because the thing we want to detect has already been shipping for a while. So might not be useful/accurate.
<TabAtkins> astearns: I agree with the commenter that feature() isn't great, think named-feature() is slightly better. but don't have a strong opinion.
<kizu> +1
<TabAtkins> astearns: But since this isn't meant to be a very used feature, I think a longer name is fine
<TabAtkins> dbaron: fine with named-feature()
<miriam> q+
<TabAtkins> No opinion from me; lean slightly toward just feature(). keyword seems fine
<astearns> ack miriam
<TabAtkins> miriam: I think this is useful, having it matters more to me than bikeshedding it. happy with these proposed names
<schenney> q+
<TabAtkins> schenney: I'm in favor of named-feature(), makes it clear you're looking for a special name
<TabAtkins> astearns: We can reoslve on named-feature() and see if anyone complains afterward
<astearns> ack schenney
<TabAtkins> astearns: proposed resolution is to use named-feature()
<TabAtkins> RESOLVED: use `named-feature()` as the function name
<TabAtkins> astearns: do you want a resolution on the keyword too?
<TabAtkins> dbaron: We shoudl resolve on th ename, then figure out if we still want it
<TabAtkins> astearns: Proposed resolution: call the keyword `align-content-on-display-block`
<TabAtkins> RESOLVED: call the keyword `align-content-on-display-block`