[selectors] :drop() should not be a pseudo-function

[Crissov]

Changes:

Changed the :active-drop-target, :valid-drop-target, :invalid-drop-target with :drop().

Selectors and values should (and usually do) use function syntax with parameters inside parentheses only if the possible parameters …

• cannot be enumerated, e.g. calc() and :nth-child() or
• are an open set controlled outside CSS, e.g. ISO 639 / BCP 47 language codes in :lang().

This selector, however, accepts only three optional keywords as its parameters which can be combined into just 6 canonically equivalent ways (since valid and invalid are mutually exclusive), one of which is already covered by a pseudo-class selector and two of which can be expressed by chained selectors:

:drop( [ active || valid || invalid ]? ) 

• :drop() = :drop
• :drop(active) (= :active-drop-target)
• :drop(valid) (= :valid-drop-target)
• :drop(invalid) (= :invalid-drop-target)
• :drop(active valid) = :drop(valid active) = :drop(active):drop(valid) = :drop(valid):drop(active) (= :active-drop-target:valid-drop-target)
• :drop(active invalid) = :drop(invalid active) = :drop(active):drop(invalid) = :drop(invalid):drop(active) (= :active-drop-target:invalid-drop-target)

The change therefore makes no apparent sense.

[fantasai]

:dir() is also enumerated, so I think your assertion is false.

[Crissov]

I wrote should, not must. :dir() may constitute a precedent, but not a good one.

PS: There is also no :dir() = :dir equivalence, since the latter does not exist.

[tabatkins]

The patterns you're noticing are not exhaustive or restrictive. (And omitting something else which does use the same pattern is kinda bad form.) We use whatever syntax best serves our needs, and the switch to :drop() made things shorter and easier to type, particularly in the final two cases you list.

[Crissov]

The pattern is followed almost everywhere in CSS. I’m pretty sure programming best practices advise against functions with such a small closed set of parameters. Perhaps the WG should explicitly adopt it as a design guideline for CSS syntax. Guidelines can be broken if there are good reasons to do so. I don’t see one here.

If shortening was the only goal, some renaming would also have done, e.g.:

• :drop
• :drop-target
• :drop-valid
• :drop-invalid
• :drop-target:drop-valid
• :drop-target:drop-invalid

[tabatkins]

No, programming uses this sort of pattern all the time. It's the entire reason we invented enums (both generally, and specifically for WebIDL).

[annevk]

FWIW, #2257 likely makes this moot.

(I do agree though that enums are pretty great and seem easier here than a whole bunch of related-by-name-only pseudo-classes.)

[SelenIT]

Also, combination of pseudo-classes increases the specificity by 2, while a single functional pseudo-class — only by 1.

[Crissov]

@SelenIT’s argument is the first that is convincing if that is indeed desired behavior.

[Crissov]

I know this is beating a dead horse, because @annevk was right in that the whole feature would be dropped, but just being reminded of this issue today, I really despise @tabatkins's reference to Enum. Enumerated keywords are always either mutually exclusive or may combine freely, but here you had three values of which two are mutually exclusive. If the active valid and active invalid combinations had separate keywords, this would be a different situation (which would probably be criticized on other grounds). My point holds: this was bad language design, and legacy dir() is only slightly better.

enum Validity { "valid", "invalid" };
enum Activity { "active", "passive" };
enum Activeness { "active", "inactive", "dormant" /*...*/ };
enum Availability { "available", "unavailable", "occupied" /*...*/ };
enum Interactivity /*?*/ { "active", "valid", "invalid", "available" /* = active+valid */, "unavailable" /* = active+invalid */ };
/* ... */

interface DropTarget {
  attribute Validity check;
  attribute Activeness state;

  void initialize(Validity check, Activeness state);
};