[css-forms-1] `::field-component` mechanism to determine what type of separator

[lukewarlow]

The ::field-component and ::field-separator can represent both date separators (e.g. "/") but also the time separators ":" and even the separator between day and time " ". It'd be potentially useful to have a way to distinguish these?

Perhaps the ordering is enough? But that might be problematic for Intl.

[nt1m]

I've intentionally kept them vague, since a lot of it is controlled by i18n, so you wouldn't want to end up in a state where separators are properly styled in one locale, but not in others.

However, if there are use cases for styling different types of separators differently, the pseudo-element could take a functional argument, e.g. ::field-separator(...). Then people can choose to style them differently, but also style them the same way.

I'm not quite sure what idents would make sense in the argument, but these are my initial thoughts.

[lukewarlow]

I'm thinking you might want to style the time portion but not the date if you wanted to indicate that's the chunk with the validation issue for example. So perhaps the same issue applies to field component too.

[Crissov]

This is currently limited to date and time input fields, but many “simple” text and number input values should actually also be separated into fields, at least visually, see #4875. For instance, either the decimal grouping character (period, comma, space, apostrophe, …) in large numbers or the decimal separator (usually comma or period) could be considered field separators.

That means the pseudo-element should either cover those as well, or it should get a less generic name.

[SebastianZ]

I do think a functional version of the pseudo-element taking some keywords makes sense. Those keywords might be:

• date-part
• time-part
• date-time
• numeric-seperator
• decimal-separator
• all (equivalent to the non-functional pseudo-element)

For the use cases outlined in #4875, we might also introduce a numeric version to target individual separators.

Sebastian

[mfreed7]

{I'm just copying my comment over from #11889, since I didn't notice this issue before posting.}

---

I appreciate the effort to give the UA enough control to handle things like internationalization. However, I'm afraid the customizability isn't enough for these controls, with the proposed pseudo element scheme. The proposal says:

::field-component The ::field-component pseudo-element represents the portions of the control that contain the date/time component values.
::field-separator The ::field-separator pseudo-element represents the portions of the control that separate the date/time component values if the user agent provides those portions.

But how, e.g., would a developer style the "month" field differently from the "day" field, e.g. making the month red and the day blue? And how would ::field-separator work for a datetime control, which commonly looks like this:

In this case, there are four different separators: /, :, ,, and . So the developer can't customize these at all without breaking the control, because they don't know which ::field-separator is which. Also I don't think (?) they can even select by position, because pseudo elements can't reveal their position with ::nth-child?

Additionally, the in-page control for date/time controls often have other "buttons" such as a clear button (a very common request/complaint from developers 1,2,3,4,5) or a "today" button, etc. These buttons might want to be provided via custom element button controls, also. Some design systems very commonly include an entire calendar picker in the page, e.g. on airline reservation sites to pick start and end dates.

Generally, it feels like date/time controls might need more composability - the ability to include custom HTML within the parts of the in-page control. I'm afraid there might be many use cases that aren't addressed with a CSS-only approach.

[lukewarlow]

Further to Mason's questions, I have one. How is it proposed that the UA uses these pseudo elements? One thing I would very much like is for as much UA behaviour to be explainable via CSS as possible. So if the UA is setting the content to "/" it would be good if that could be explainable via the UA stylesheet (which I imagine would need some additional capabilities).

[fantasai]

As Tim mentioned, the format of these controls is controlled by i18n requirements, and we don't want the author to be styling with assumptions that may turn out to be true. So I lean towards not making the separators distinguishable or customizable in terms of their content or their positions. (These aspects therefore don't need to be controllable via CSS.)

Composability with new control features should be handled through additions to HTML, which can then be exposed through new CSS pseudo-elements, but that's a separate discussion from introducing pseudo-elements for existing parts of existing controls.

[mfreed7]

As Tim mentioned, the format of these controls is controlled by i18n requirements, and we don't want the author to be styling with assumptions that may turn out to be true. So I lean towards not making the separators distinguishable or customizable in terms of their content or their positions. (These aspects therefore don't need to be controllable via CSS.)

That's fair, and as I said in the OP, I do see the point of architecting it this way. I just don't know how a developer would e.g. make the Month a different color from the Day. Or other simple things that developers might want to do. E.g. make the "date" fields/separators one color and the "time" fields/separators another color. Or font size. Or whatever.

Composability with new control features should be handled through additions to HTML, which can then be exposed through new CSS pseudo-elements, but that's a separate discussion from introducing pseudo-elements for existing parts of existing controls.

I'd submit that developers use both CSS and HTML. We shouldn't be designing only half the solution just because there are two standards in two different standards bodies. Hopefully we can use the joint forms task force meetings for this purpose, perhaps?

[nt1m]

I think it would probably be more reasonable (and useful) to allow distinguishing the type for ::field-component, but ::field-separator probably shouldn't be distinguishable given the possible orderings.