- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 18 Feb 2026 16:51:44 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <bramus> fantasai: question about which form controls ::field-text applies to<br> <bramus> … clear from the spec that it’s definitely text inputs<br> <bramus> … but should basically apply to all that look like a text field – that contain text-ish content<br> <bramus> … and a separate thing about textarea<br> <fantasai> PROPOSED: ::field-text applies to <input type=text> and anything that has a derivative interface, including date, time, number, password, etc.<br> <masonf> q+<br> <emeyer> q+<br> <bramus> … proposal that it appplies to input type=text and antyhing derivative<br> <astearns> ack masonf<br> <bramus> masonf: I like the second point in the proposal<br> <lwarlow> +1<br> <bramus> … textarea and input should be as similar as possible<br> <bramus> fantasai: yes, but separate point<br> <bramus> masonf: yes, great<br> <astearns> ack emeyer<br> <bramus> emeyer: you mentioned “etc”. does that include color inputs that show a hex value?<br> <SebastianZ> q+<br> <bramus> fantasai: they are considered button-like<br> <masonf> range<br> <bramus> lwarlow: would not apply to checkbox, radio, color, file, and range<br> <bramus> … color is very much defined as a button that opens a picker<br> <masonf> image?<br> <bramus> … it mostly renders the color in a color swatch<br> <masonf> also not image, reset, submit<br> <dbaron> also not apply to hidden<br> <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<br> <bramus> … IIRC WebKit doesn’t have a datepicker for week (or month) so it renders as text-ish<br> <bramus> astearns: you also had comment about desktop and mobile?<br> <bramus> lwarlow: main difference is whether it allows you to edit the text freehand<br> <bramus> … and I think that is a separate issue<br> <masonf> So this applies to date, datetime-local, email, month, number, password, search, tel, text, time, url, week<br> <masonf> q+<br> <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<br> <astearns> ack SebastianZ<br> <bramus> SebastianZ: shouldn’t input[file] match?<br> <bramus> … at least on some platforms it has text in it<br> <bramus> lwarlow: I personally think that it should ahve a pseudo, but a different one<br> <bramus> … maybe ::field-text is not prescriptive enough<br> <bramus> … but for text inputs it generally the name of the file or some “2 files” when multipicker<br> <bramus> … probably do want a pseudo<br> <bramus> … but a different one I htink personally<br> <bramus> … but could be persuaded otherwise<br> <bramus> SebastianZ: maybe when we strictly say “this is for text input”, then a file input wouldnt fit<br> <bramus> … but depends on the definition we take<br> <astearns> ack masonf<br> <bramus> masonf: feels like it’s an _editable_ field text, which is not true for a file input<br> <bramus> … wanted to ask about lwarlow’s mobile date picker fields<br> <bramus> … that’s an appearnce: auto behavior<br> <bramus> … would expect that we don’t do that for appearance: base<br> <bramus> … so would consider the pseudo to apply to all things that is directly editable as text<br> <bramus> lwarlow: this speudo would apply when an input is readonly. whethehr its actually editable, is somewhat tangential<br> <bramus> … ideally appearacne based behavior is as consistent as possible<br> <bramus> … maybe more of an HTML question than CSS?<br> <bramus> … maybe we have a UA property that can changes whether something is editable<br> <bramus> … at the very least i want the structure to be consistent on mobile<br> <astearns> ack fantasai<br> <bramus> masonf: I was agreeing with you here<br> <bramus> fantasai: let’s not focus too much on the direct editability of the text<br> <bramus> … in some cases it could be ??? or through a popup that feeds back into the text input<br> <bramus> … we have clear concept of things that are input like<br> <lwarlow> +1<br> <bramus> … (missed)<br> <masonf> Let's just make it clear by listing them. These? date, datetime-local, email, month, number, password, search, tel, text, time, url, week<br> <fantasai> s/(missed)/There's a rectangle, it contains text that represents the input the user is submitting into the form./<br> <bramus> astearns: sounds like we are in general agreement that it should apply to input type text and anything that has a derivative interface<br> <bramus> … can consider more things indiviually<br> <lwarlow> (also invalid types too fwiw)<br> <bramus> … objections?<br> <bramus> masonf: shouldn’t we get a fixed list?<br> <masonf> An illustrative list is what I was going for<br> <bramus> fantasai: should have a defintion tha tis not a list. the list should be illustrative, for if we later add more input types<br> <bramus> astearns: and if you have a list here, paste it in IRC<br> <bramus> … (mason already pasted it)<br> <astearns> Proposed: ::field-text applies to <input type=text> and anything that has a derivative interface<br> <bramus> RESOLVED: ::field-text applies to <input type=text> and anything that has a derivative interface<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13400#issuecomment-3921931733 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 February 2026 16:51:45 UTC