[css-forms-1] ::field-component and ::field-separator should be children of ::field-text

[fantasai]

For internationalization, localization, and platform-dependent reasons, we can't let authors perform arbitrary layout of ::field-component and ::field-separator. Like, reordering the components using flexbox and order would be a real problem: if they hacked it up to work in their own OS configuration it's unlikely to work for anyone else. But it seems reasonable that the author might want to style various bits within the control while keeping this stream of text content as a unit, so I making these all children of a more ::field-text pseudo-element might be a way forward here. We can force the display value of ::field-text to flow and that limits the kind of trouble they can cause within the date/time text representation while still allowing the input field itself and other things like the picker-icon to be styled.

It also gives us a consistent way to style the inner text of a text-input style field: ::field-text is always available.

See also #11852

[css-meeting-bot]

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; }

The full IRC log of that discussion

<bramus> fantasai: this was about the structure and relationship of the various ::field pseudos
<bramus> … for datetime we have ::field-component and ::field-separator
<bramus> … and then we also have ::field-text
<bramus> … proposal was to have ::field-text appy to all input types
<bramus> … and if there are ::field-component and ::field-separator, they are children of ::field-text
<bramus> … makes it easy to consistently style things
<lwarlow> q+
<bramus> … e.g. setting padding or margin around it, or chang ecolor of text
<bramus> … just do that directly, wihtout having to figure out if there are separate ::field-component or ::field-separator parts
<masonf> q-
<astearns> ack dbaron
<bramus> dbaron: structure seems reasonable. hesitant about the names making sense with that structure
<bramus> … sounds like ::field-text is an innermost thing, just from the name
<bramus> … name also makes me nervous because we have a system color FieldText
<bramus> … but that might be a Gecko-specific one
<bramus> fantasai: I would expect that ??? so probably fine
<bramus> dbaron: innermost/outermost is bigger concern
<masonf> There is a FieldText: https://drafts.csswg.org/css-color/#valdef-color-fieldtext
<bramus> fantasai: it does only contain text, because the ::field-component and ::field-separator are text (not a button)
<masonf> ::field-text-wrapper ?
<bramus> … like in an input you have the field-text portion and the icons. the latter it outside of ::field-text
<bramus> s/it/is
<fantasai> https://www.w3.org/TR/css-color-4/#valdef-color-fieldtext
<emilio> q+
<bramus> fantasai: i think that ::field-text-wrapper is just more stuff to type
<astearns> ack lwarlow
<bramus> lwarlow: wihtout wanting to derail this, there is an important idscussion to have around the date field
<bramus> … currently they are not a single text
<astearns> ::field-contents?
<bramus> … they YMD are kinda separate contenteditables, individually focusable parts
<bramus> … and maybe in that world it doesn”t make sense to have a single ::field-text
<bramus> … should maybe specify that they are single block or text (or not). kinda have their own werid behaviors
<dbaron> I think Luke's description about the pieces of the control matches my nervousness about ::field-text wrapping the whole thing
<bramus> … on mobile it _is_ a single block of text
<bramus> … maybe not even editable text. you only have a picker (unless you have a keyboard)
<bramus> … does it make sense to have multiple texts?
<bramus> … can make styling easier. conceptually one block of text, even if sligthly separate
<astearns> q+
<bramus> … would be good to work out behavior on desktop on mobile (or mouse vs keyboard) to have some consistency?
<bramus> emilio: different components on mobile ???
<bramus> … how does this interact with placeholder?
<bramus> … does it layout atop? sibling? child?
<astearns> s/different components on mobile ???/the components are there on mobile - the whole date is displayed/
<bramus> fantasai: good question
<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
<bramus> … if we specced placeholder inside, then ::field-text would make more sense
<bramus> … with respect to other components of ??? would also want to shift the placeholder along with the rest of the text
<astearns> ack emilio
<bramus> emilio: tricky thing is explaining layout … its kinda magic right now
<bramus> … would make more sense as a child of the field text, then everything kinda works out
<bramus> … (missed)
<astearns> ack fantasai
<lwarlow> https://github.com//issues/11844. - issue about how they interact with each other
<bramus> fantasai: respond to behavior thing: i think we want the input to behave the same way as platform controls
<bramus> … main purpose is so that their bheavior is as comfortable and accessible to the user
<bramus> … which the developer might miss
<bramus> … shouldnt be too concernd about how many text editables there are
<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
<bramus> … and on styling of that content
<bramus> astearns: does this new wrapper give more styling control, or is it just a nice thing?
<bramus> … can you achieve the same thing wo styling the wrapper?
<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
<bramus> … not change the localization part
<bramus> … that whole set of text pieces is separate from the picker and the various other controls
<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
<bramus> … you cant change the spacing
<bramus> astearns: my ??? could give the impression that it would also be included in that
<lwarlow> field-value maybe?
<bramus> … contents tends to mean text in a lot of contexts
<lwarlow> But I think contents is better personally
<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 )
<astearns> s/???/suggestion of :field-contents/
<fantasai> dbaron https://www.w3.org/TR/css-color-4/#valdef-color-fieldtext
<bramus> astearns: so, are we convinced we need this wrapper?
<bramus> fantasai: I’m fairly convinced
<lwarlow> +1
<masonf> +1 to needing the wrapper, just sounds like we need a good name
<bramus> … easier to style things consistently
<SebastianZ> q+
<bramus> +1
<astearns> ack astearns
<astearns> ack SebastianZ
<lwarlow> It's a nice place to force display:flow (or whever we end up forcing)
<emilio> FWIW something that can be annoying is performance, creating lots of elements under an `<input>` shows up in Speedometer ;)
<emilio> (but no objection in principle :))
<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
<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
<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
<bramus> SebastianZ: so the general direction is to say we have a wrapper, and should figure out the details in a separate issue
<bramus> astearns: other opinions?
<emeyer> s/set a ??/suppress/
<fantasai> ::field-text/content { display: flow !important; } ::field-component, ::field-separator { position: static !important; }
<bramus> … shall we decide on a provisiional name?
<bramus> fantasai: we already have one: ::field-text
<bramus> … this is trying to set up the relation to other things
<bramus> lwarlow: and then we can follow-up about the ?? pseudo
<bramus> … kinda a separate thing
<masonf> s/??/naming of the/
<fantasai> PROPOSED: ::field-text contains ::field-component and ::field-separator
<bramus> astearns: do we also want to say ::feld-text contains the ::placeholder?
<bramus> lwarlow: maybe leave for a follow-up? I prototyped it as a sibling and worked kinda fine.
<masonf> +1
<lwarlow> +1
<bramus> astearns: objections?
<fantasai> PROPOSED: ::field-text/content { display: flow !important; } ::field-component, ::field-separator { position: static !important; }
<bramus> RESOLVED: ::field-text contains ::field-component and ::field-separator
<bramus> fantasai: one follow-up
<lwarlow> +1
<SebastianZ> +1
<bramus> astearns: to disallow changing the display value of field-text and position of field-separator
<bramus> … objections?
<masonf> +1
<fantasai> PROPOSED: ::field-text { display: flow !important; } ::field-component, ::field-separator { position: static !important; }
<fantasai> RESOLVED: ::field-text { display: flow !important; } ::field-component, ::field-separator { position: static !important; }
<bramus> astearns: is there an issue on what we need to disallow here?
<bramus> fantasai: need to open one
<bramus> astearns: can you do that?