- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 18 Feb 2026 16:38:02 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-forms-1] ::field-component and ::field-separator should be children of ::field-text`, and agreed to the following:
* `RESOLVED: ::field-text contains ::field-component and ::field-separator`
* `RESOLVED: ::field-text { display: flow !important; } ::field-component, ::field-separator { position: static !important; }`
<details><summary>The full IRC log of that discussion</summary>
<bramus> fantasai: this was about the structure and relationship of the various ::field pseudos<br>
<bramus> … for datetime we have ::field-component and ::field-separator<br>
<bramus> … and then we also have ::field-text<br>
<bramus> … proposal was to have ::field-text appy to all input types<br>
<bramus> … and if there are ::field-component and ::field-separator, they are children of ::field-text<br>
<bramus> … makes it easy to consistently style things<br>
<lwarlow> q+<br>
<bramus> … e.g. setting padding or margin around it, or chang ecolor of text<br>
<bramus> … just do that directly, wihtout having to figure out if there are separate ::field-component or ::field-separator parts<br>
<masonf> q-<br>
<astearns> ack dbaron<br>
<bramus> dbaron: structure seems reasonable. hesitant about the names making sense with that structure<br>
<bramus> … sounds like ::field-text is an innermost thing, just from the name<br>
<bramus> … name also makes me nervous because we have a system color FieldText<br>
<bramus> … but that might be a Gecko-specific one<br>
<bramus> fantasai: I would expect that ??? so probably fine<br>
<bramus> dbaron: innermost/outermost is bigger concern<br>
<masonf> There is a FieldText: https://drafts.csswg.org/css-color/#valdef-color-fieldtext<br>
<bramus> fantasai: it does only contain text, because the ::field-component and ::field-separator are text (not a button)<br>
<masonf> ::field-text-wrapper ?<br>
<bramus> … like in an input you have the field-text portion and the icons. the latter it outside of ::field-text<br>
<bramus> s/it/is<br>
<fantasai> https://www.w3.org/TR/css-color-4/#valdef-color-fieldtext<br>
<emilio> q+<br>
<bramus> fantasai: i think that ::field-text-wrapper is just more stuff to type<br>
<astearns> ack lwarlow<br>
<bramus> lwarlow: wihtout wanting to derail this, there is an important idscussion to have around the date field<br>
<bramus> … currently they are not a single text<br>
<astearns> ::field-contents?<br>
<bramus> … they YMD are kinda separate contenteditables, individually focusable parts<br>
<bramus> … and maybe in that world it doesn”t make sense to have a single ::field-text<br>
<bramus> … should maybe specify that they are single block or text (or not). kinda have their own werid behaviors<br>
<dbaron> I think Luke's description about the pieces of the control matches my nervousness about ::field-text wrapping the whole thing<br>
<bramus> … on mobile it _is_ a single block of text<br>
<bramus> … maybe not even editable text. you only have a picker (unless you have a keyboard)<br>
<bramus> … does it make sense to have multiple texts?<br>
<bramus> … can make styling easier. conceptually one block of text, even if sligthly separate<br>
<astearns> q+<br>
<bramus> … would be good to work out behavior on desktop on mobile (or mouse vs keyboard) to have some consistency?<br>
<bramus> emilio: different components on mobile ???<br>
<bramus> … how does this interact with placeholder?<br>
<bramus> … does it layout atop? sibling? child?<br>
<astearns> s/different components on mobile ???/the components are there on mobile - the whole date is displayed/<br>
<bramus> fantasai: good question<br>
<bramus> … two ways we could relate field-text to placeholder. could be siblings where you display only one, or placeholder could be nested inside ::field-text<br>
<bramus> … if we specced placeholder inside, then ::field-text would make more sense<br>
<bramus> … with respect to other components of ??? would also want to shift the placeholder along with the rest of the text<br>
<astearns> ack emilio<br>
<bramus> emilio: tricky thing is explaining layout … its kinda magic right now<br>
<bramus> … would make more sense as a child of the field text, then everything kinda works out<br>
<bramus> … (missed)<br>
<astearns> ack fantasai<br>
<lwarlow> https://github.com/w3c/csswg-drafts/issues/11844. - issue about how they interact with each other<br>
<bramus> fantasai: respond to behavior thing: i think we want the input to behave the same way as platform controls<br>
<bramus> … main purpose is so that their bheavior is as comfortable and accessible to the user<br>
<bramus> … which the developer might miss<br>
<bramus> … shouldnt be too concernd about how many text editables there are<br>
<bramus> … point is to enable styling, and you want it to be consistent – single text or separate ones, the final styling of that control should allow for matching up against the pseudos<br>
<bramus> … and on styling of that content<br>
<bramus> astearns: does this new wrapper give more styling control, or is it just a nice thing?<br>
<bramus> … can you achieve the same thing wo styling the wrapper?<br>
<bramus> fantasai: datepicker for example has Y M D with separators in between. author is not allowed to change the order of those, we are allowing them to set the color and stuff<br>
<bramus> … not change the localization part<br>
<bramus> … that whole set of text pieces is separate from the picker and the various other controls<br>
<bramus> … auhtors could change the layout of those with respect to each other, so having a wrapper around the text content allows us to see it as a unit whose inside things you can style<br>
<bramus> … you cant change the spacing<br>
<bramus> astearns: my ??? could give the impression that it would also be included in that<br>
<lwarlow> field-value maybe?<br>
<bramus> … contents tends to mean text in a lot of contexts<br>
<lwarlow> But I think contents is better personally<br>
<dbaron> (FYI, I think the FieldText system color thing was never in the spec but the rationale for it is documented in https://lists.w3.org/Archives/Public/www-archive/2019Apr/0000.html )<br>
<astearns> s/???/suggestion of :field-contents/<br>
<fantasai> dbaron https://www.w3.org/TR/css-color-4/#valdef-color-fieldtext<br>
<bramus> astearns: so, are we convinced we need this wrapper?<br>
<bramus> fantasai: I’m fairly convinced<br>
<lwarlow> +1<br>
<masonf> +1 to needing the wrapper, just sounds like we need a good name<br>
<bramus> … easier to style things consistently<br>
<SebastianZ> q+<br>
<bramus> +1<br>
<astearns> ack astearns<br>
<astearns> ack SebastianZ<br>
<lwarlow> It's a nice place to force display:flow (or whever we end up forcing)<br>
<emilio> FWIW something that can be annoying is performance, creating lots of elements under an `<input>` shows up in Speedometer ;)<br>
<emilio> (but no objection in principle :))<br>
<bramus> SebastianZ: Wondering if the field component should use UA styles with important so that authors cant override things like the order of the field text inside it<br>
<bramus> … or the other way around: the field text to be a wrapper for the others just to explain the magic behind the styling but not to open up everything for styling for authors<br>
<bramus> fantasai: we probably should do a pass on the tings we would disallow. can avoid reordering effects by forcing display flow on the wrapper. also want to set a ?? position on all the pseudos<br>
<bramus> SebastianZ: so the general direction is to say we have a wrapper, and should figure out the details in a separate issue<br>
<bramus> astearns: other opinions?<br>
<emeyer> s/set a ??/suppress/<br>
<fantasai> ::field-text/content { display: flow !important; } ::field-component, ::field-separator { position: static !important; }<br>
<bramus> … shall we decide on a provisiional name?<br>
<bramus> fantasai: we already have one: ::field-text<br>
<bramus> … this is trying to set up the relation to other things<br>
<bramus> lwarlow: and then we can follow-up about the ?? pseudo<br>
<bramus> … kinda a separate thing<br>
<masonf> s/??/naming of the/<br>
<fantasai> PROPOSED: ::field-text contains ::field-component and ::field-separator<br>
<bramus> astearns: do we also want to say ::feld-text contains the ::placeholder?<br>
<bramus> lwarlow: maybe leave for a follow-up? I prototyped it as a sibling and worked kinda fine.<br>
<masonf> +1<br>
<lwarlow> +1<br>
<bramus> astearns: objections?<br>
<fantasai> PROPOSED: ::field-text/content { display: flow !important; } ::field-component, ::field-separator { position: static !important; }<br>
<bramus> RESOLVED: ::field-text contains ::field-component and ::field-separator<br>
<bramus> fantasai: one follow-up<br>
<lwarlow> +1<br>
<SebastianZ> +1<br>
<bramus> astearns: to disallow changing the display value of field-text and position of field-separator<br>
<bramus> … objections?<br>
<masonf> +1<br>
<fantasai> PROPOSED: ::field-text { display: flow !important; } ::field-component, ::field-separator { position: static !important; }<br>
<fantasai> RESOLVED: ::field-text { display: flow !important; } ::field-component, ::field-separator { position: static !important; }<br>
<bramus> astearns: is there an issue on what we need to disallow here?<br>
<bramus> fantasai: need to open one<br>
<bramus> astearns: can you do that?<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13355#issuecomment-3921864261 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:38:03 UTC