[css-forms-1] Can we simplify select::picker(select)?

[bramus]

(Disclaimer: I haven’t been involved in any of the discussions that lead to this selector, so I am most likely missing a lot of backstory and info … this is me personally looking at it without any extra knowledge about it.)

Every time I see customizable select demos, the select::picker(select) stands out to me … in a weird way. It feels very weird because of the extra select at the end there. To me, select::picker(select) reads as “Give me the select that is part of the ::picker which belongs to the <select>”. Huh?

The spec reads that the argument to picker() is the unique picker name that you want to target, and for <select> that is select. But that feels redundant to me, because the select at the start of select::picker(select) already implies that you are trying to access something related to the <select> element.

Looking at the explainer https://open-ui.org/components/customizableselect/#styling (which I don’t know if it’s up-to-date or not) it says the pseudo targets the popover that contains the options that you can choose from. But AFAICT there is only popover per control. I also looked at #10462, #10758, and #10440 but could not find back an exact explanation to why the extra select at the end is required.

This leads to me these questions:

• Why is the argument there? Is it because you would be able to a different picker name in the future – E.g. when one rolls their own custom picker on a certain element?
  • If not, then why have it?
• Allowing custom picker names or not, can’t we omit it by default and have the browser then target the default picker of that element?
  • E.g. select::picker() gives you what select::picker(select) currently gives you.
  • It knows what to select because it the context from the part before ::picker … so for <select> it could choose the select unique picker name and for something like a date-picker it (in the future) would use the one for that control.

I’m sure I’m missing a lot of info/backstory here, so feel free to enlighten me on why this extra picker is absolutely necessary.

Perhaps, if this can’t be simplified, the spec could add a note that explains the reasoning behind it?

/cc @josepharhar @annevk @dbaron @fantasai who participated in the previous discussions on this.

[annevk]

The idea is to require the argument for now to make it easier to roll this out to other elements over some period of time. Once we are satisfied and have covered all elements that need it, we can make the argument optional (to ::picker sans parenthesis I'd hope) without fear of breaking forward compatibility.

Documenting that in a note makes sense to me.

cc @nt1m

[nt1m]

You can just write ::picker(select) instead of select::picker(select). Eventually when we support all pickers, you'd be able to write select::picker too. But it doesn't seem like a major inconvenience now to just write ::picker(select) instead of select::picker.

[bramus]

But it doesn't seem like a major inconvenience now to just write ::picker(select) instead of select::picker

But this is a deviation from what we currently write. For example, it’s p::before and not ::before(p).

Eventually when we support all pickers, you'd be able to write select::picker too.

Is there a reason why we can’t do that now? I understand that ::picker itself would target all pickers which could work against authors in the future because they target too many pickers. However, part of the guidelines that DevRel can give here – and which could also be a note in the spec – is to warn authors to always prepend the targeted element before ::picker, e.g. select::picker.

[nt1m]

Is there a reason why we can’t do that now? I understand that ::picker itself would target all pickers which could work against authors in the future because they target too many pickers. However, part of the guidelines that DevRel can give here – and which could also be a note in the spec – is to warn authors to always prepend the targeted element before ::picker, e.g. select::picker.

The main reason is to avoid compat hazard. If someone writes

::picker { 
   ...
}

Right now it would only apply to select, but as support for more pickers are added (datepicker etc.), that rule would start applying to more things (potentially against the will of the author, or not as they expect).

Having a mandatory argument during the transitional period, allows pickers to be incrementally rolled out control by control without compat problems.

[nt1m]

However, part of the guidelines that DevRel can give here – and which could also be a note in the spec – is to warn authors to always prepend the targeted element before ::picker, e.g. select::picker.

I'll let @fantasai comment on whether this is a reasonable alternative to a mandatory argument.

[annevk]

Unfortunately we cannot rely on DevRel or specification guidance. Web developers will use all permutations of an API and rely on them. We have to design it in a way such that it cannot be misused.