[css-forms-1] Which form controls does ::field-text apply to?

[fantasai]

Pulling out of #12950 (comment) ...

fantasai wrote:

do we really need ::field-text for <textarea>...?

Joey wrote:

Since the textarea element supports the placeholder attribute just like the input element, I don't see why they shouldn't have the same pseudo-elements. Whether ::field-text is needed for either element is probably worth justifying.

fantasai replied:

I think if we have ::field-text for some form controls that look like text fields, we should have it for all of them. It's an even stronger argument than consistency between single-line inputs and multiline inputs, which behave differently in a number of ways. :)

Proposals to discuss:

• ::field-text applies to <input type=text> and anything that has a derivative interface, including date, time, number, password, etc.
• ::field-text also applies to <textarea>.

Related issue: #13355

[lukewarlow]

One thing I've just realised too is that on mobile devices the individual components of the "temporal" (date, datetime-local, time, month, week) inputs aren't actually editable like they are on desktop. These inputs are essentially buttons that open pickers on mobile. Now I think it would be problematic to style them drastically differently on mobile compared to desktop BUT I do think that the specification might need to take this into account.

For example currently ::field-text is defined as The [::field-text](https://drafts.csswg.org/css-forms-1/#selectordef-field-text) pseudo-element represents the portion of the [input](https://html.spec.whatwg.org/multipage/input.html#the-input-element) that contains the editable text.

The "editable text" part especially might need to be adjusted.

Though it also effects exactly which components are focusable and which are the click target so this perhaps should be it's own issue?

[nt1m]

I think we should leave textarea out for now until we have use cases, happy to reconsider then.

[css-meeting-bot]

The CSS Working Group just discussed [css-forms-1] Which form controls does ::field-text apply to?, and agreed to the following:

• RESOLVED: ::field-text applies to <input type=text> and anything that has a derivative interface

The full IRC log of that discussion

<bramus> fantasai: question about which form controls ::field-text applies to
<bramus> … clear from the spec that it’s definitely text inputs
<bramus> … but should basically apply to all that look like a text field – that contain text-ish content
<bramus> … and a separate thing about textarea
<fantasai> PROPOSED: ::field-text applies to <input type=text> and anything that has a derivative interface, including date, time, number, password, etc.
<masonf> q+
<emeyer> q+
<bramus> … proposal that it appplies to input type=text and antyhing derivative
<astearns> ack masonf
<bramus> masonf: I like the second point in the proposal
<lwarlow> +1
<bramus> … textarea and input should be as similar as possible
<bramus> fantasai: yes, but separate point
<bramus> masonf: yes, great
<astearns> ack emeyer
<bramus> emeyer: you mentioned “etc”. does that include color inputs that show a hex value?
<SebastianZ> q+
<bramus> fantasai: they are considered button-like
<masonf> range
<bramus> lwarlow: would not apply to checkbox, radio, color, file, and range
<bramus> … color is very much defined as a button that opens a picker
<masonf> image?
<bramus> … it mostly renders the color in a color swatch
<masonf> also not image, reset, submit
<dbaron> also not apply to hidden
<bramus> … we should make that color input is kinda always a button, but depending on how presciptive we are to a UA … but if it did show the color, then maybe it should apply
<bramus> … IIRC WebKit doesn’t have a datepicker for week (or month) so it renders as text-ish
<bramus> astearns: you also had comment about desktop and mobile?
<bramus> lwarlow: main difference is whether it allows you to edit the text freehand
<bramus> … and I think that is a separate issue
<masonf> So this applies to date, datetime-local, email, month, number, password, search, tel, text, time, url, week
<masonf> q+
<bramus> … on mobile (chrome and safari) you can only change date with the picker, not the keyboard … but it could still be considered a textual input
<astearns> ack SebastianZ
<bramus> SebastianZ: shouldn’t input[file] match?
<bramus> … at least on some platforms it has text in it
<bramus> lwarlow: I personally think that it should ahve a pseudo, but a different one
<bramus> … maybe ::field-text is not prescriptive enough
<bramus> … but for text inputs it generally the name of the file or some “2 files” when multipicker
<bramus> … probably do want a pseudo
<bramus> … but a different one I htink personally
<bramus> … but could be persuaded otherwise
<bramus> SebastianZ: maybe when we strictly say “this is for text input”, then a file input wouldnt fit
<bramus> … but depends on the definition we take
<astearns> ack masonf
<bramus> masonf: feels like it’s an _editable_ field text, which is not true for a file input
<bramus> … wanted to ask about lwarlow’s mobile date picker fields
<bramus> … that’s an appearnce: auto behavior
<bramus> … would expect that we don’t do that for appearance: base
<bramus> … so would consider the pseudo to apply to all things that is directly editable as text
<bramus> lwarlow: this speudo would apply when an input is readonly. whethehr its actually editable, is somewhat tangential
<bramus> … ideally appearacne based behavior is as consistent as possible
<bramus> … maybe more of an HTML question than CSS?
<bramus> … maybe we have a UA property that can changes whether something is editable
<bramus> … at the very least i want the structure to be consistent on mobile
<astearns> ack fantasai
<bramus> masonf: I was agreeing with you here
<bramus> fantasai: let’s not focus too much on the direct editability of the text
<bramus> … in some cases it could be ??? or through a popup that feeds back into the text input
<bramus> … we have clear concept of things that are input like
<lwarlow> +1
<bramus> … (missed)
<masonf> Let's just make it clear by listing them. These? date, datetime-local, email, month, number, password, search, tel, text, time, url, week
<fantasai> s/(missed)/There's a rectangle, it contains text that represents the input the user is submitting into the form./
<bramus> astearns: sounds like we are in general agreement that it should apply to input type text and anything that has a derivative interface
<bramus> … can consider more things indiviually
<lwarlow> (also invalid types too fwiw)
<bramus> … objections?
<bramus> masonf: shouldn’t we get a fixed list?
<masonf> An illustrative list is what I was going for
<bramus> fantasai: should have a defintion tha tis not a list. the list should be illustrative, for if we later add more input types
<bramus> astearns: and if you have a list here, paste it in IRC
<bramus> … (mason already pasted it)
<astearns> Proposed: ::field-text applies to <input type=text> and anything that has a derivative interface
<bramus> RESOLVED: ::field-text applies to <input type=text> and anything that has a derivative interface