GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
GeezerVison is showing drafts.csswg.org — CSS Form Control Styling Module Level 1 1. IntroductionThis section is non-normative. User agents have long provided non-standard ways of styling form controls. However, all of these controls are implemented inconsistently across user agents, creating unnecessary friction for authors. This module aims to define a set of form control parts in enough detail that they can be used interoperably. It also defines some new ways of customizing form controls, covering common use cases that were previously only possible by implementing custom controls from scratch, which was a lot of work, hard to get right, and often broke either accessibility or platform conventions. 2. Opting Into Basic Appearance: the appearance: base valueMove definition of appearance here.
A control that has basic appearance is consistently styleable using standard CSS and the pseudo-elements defined below, and applies overridable default styles that are consistent across UAs. When a control is in that state, the user agent applies styles from the Appendix A: Basic Appearance User Agent Stylesheet to that control. The user agent must also enable the pseudo-elements defined by § 4 Pseudo-Elements. These pseudo-elements (excluding ::picker()) always inherit appearance from their originating element. The user agent may implement this using an appearance: inherit !important declaration. NOTE: The inheritance prevents authors from mixing native and non-native parts for the same control. 2.1. Design Principles for the Basic AppearanceThe following design principles apply to the design of the basic appearance stylesheet for form controls, in approximate order of descending importance:
NOTE: Authors may need to do extra adjustments to ensure their controls are accessible depending on any customizations as well as the context the form control is placed into. The basic appearance does not prevent adjustments by the author that are inaccessible.
For HTML form controls specifically, these principles are applied through the required user agent stylesheet defined in Appendix A: Basic Appearance User Agent Stylesheet. 2.2. ExamplesRefine these examples through implementation, experimentation, bikeshedding and improvements to the user agent stylesheet. The main purpose of these examples is to show how the design principles for the basic appearance apply in practice. To apply the basic appearance on individual controls, the following code is used: input NOTE: The form layout used by the following examples is not detailed. 2.2.1. Default User Agent ColorsHere are the basic appearance colors inheriting respectively the default light and dark mode colors from the root element:
2.2.2. Color/Font CustomizationHere are some examples of customization being done on top of the basic appearance: form
form
3. Styling Pickers3.1. The ::picker() pseudo-elementThe ::picker() pseudo-element represents the part of the form control that pops out of the page. ::picker() = ::picker( <form-control-identifier>+ ) <form-control-identifier> = select The ::picker() pseudo-element only matches when the originating element supports basic appearance and has a popup picker. The
specified <form-control-identifier> must also match the unique picker name of the
originating element. For example, the unique picker name for
the In order for the ::picker() pseudo-element to be rendered, it and its originating element must both have a computed appearance of base.
The following styles apply the basic appearance to the select picker and the select and add some additional styling to the picker:
select NOTE: The non-functional form of ::picker() currently doesn’t work to prevent unintended styling of pickers as new pickers become supported. Once styling for all form control pickers is finalized, this non-functional form will work for all pickers. 4. Pseudo-ElementsForm controls are composed of many parts that authors may want to style separately, hence the need for user agents to provide pseudo-elements for individual form controls. The section below introduces a set of pseudo-elements that attempts to cover the most common use cases, so they can be addressed in a consistent manner across user agents.
4.1. Picker Opener Icon: the ::picker-icon pseudo-elementThe ::picker-icon pseudo-element represents the part of the control that represents the icon denoting the presence of the picker. It is only generated when the originating element has basic appearance and if it opens a picker. It is a fully styleable pseudo-element and inherits from its originating element. ::picker-icon generates a box as if it was an child of its originating element, after any boxes generated by the ::after pseudo-element, with content as specified by content. 4.2. File Selector Button: the ::file-selector-button pseudo-elementThe ::file-selector-button pseudo-element represents the button used to open a file picker, if the UA renders such a button. It typically targets the
For example, the following example should show a green border around the
file selector button:
::file-selector-button 4.3. Styling Checkmarks: the ::checkmark pseudo-elementThe ::checkmark pseudo-element represents an indicator of whether the item is checked, and is present on checkboxes, radios, and option elements. It is only generated when the originating element supports the :checked pseudo-class, and either has basic appearance or an ancestor with basic appearance. It is a fully styleable pseudo-element and inherits from its originating element. For checkboxes and radio elements, it generates a box as if it was an child of its originating element, between the boxes generated by the ::before and ::after pseudo-element, with content as specified by content. For option elements, it generates a box as if it was an child of its originating element, preceding any boxes generated by the ::before pseudo-element, with content as specified by content.
The following example changes the background image of a checkmark:
::checkmark It may also be used in combination with :indeterminate::checkmark 4.4. Styling Parts of Slider-Like Controls: the ::slider-thumb, ::slider-track and ::slider-fill pseudo-elementsSlider-like controls are form controls that represent progress. That progress may be adjustable by the user. The following pseudo-elements are provided to style their different parts:
These pseudo-elements are fully styleable pseudo-elements and their structure is the following: <input type="range"> ├─ ::slider-track │ └─ ::slider-fill └─ ::slider-thumb The list of slider-like controls depends on the host language. For HTML, this corresponds to: 4.5. Styling Parts for Text Fields: the ::placeholder, ::field-content, ::reveal-icon, and ::clear-icon pseudo-elements
::field-content, ::reveal-icon, and ::clear-icon must be siblings. Collect parts used by autofill. Define how 4.6. Styling Parts for textareas: the ::placeholder and ::field-content pseudo-elements
Define something for the resizer. [Issue #11850] Define how 4.7. Styling Parts for Number Fields: the ::step-control, ::step-up and ::step-down pseudo-elementsThese pseudo-elements are provided for number inputs. They are fully styleable pseudo-elements.
Their structure is defined as follows: <input type="number"> ├─ ::field-content └─ ::step-control ├─ ::step-up └─ ::step-down
The following control:
can be re-styled like this:
using the following styles: input With appearance: textfield, the user agent must not generate this part. 4.8. Styling Parts for Date/Time Input Fields: the ::field-component and ::field-separator pseudo-elements
Those pseudo-elements are siblings. The exact structure of the control is determined by internationalization and by the host language, but must be consistent across user-agents. ::field-component and ::field-separator pseudo-elements are all contained within a ::field-content pseudo-element.
The following control:
may render like this in US locales: [ 08 / 22 / 2024 [v]] The resulting tree is: <input type="date"> ├─ ::field-content │ ├─ ::field-component (08) │ ├─ ::field-separator (/) │ ├─ ::field-component (22) │ ├─ ::field-separator (/) │ └─ ::field-component (2024) └─ ::picker-icon 4.9. Color Swatch: the ::color-swatch pseudo-elementThe ::color-swatch pseudo-element represents the portion of the control that displays the chosen color value.
For example, the following example should make the input and its color swatch rounded:
input 4.10. Compatibility With Vendor Pseudo-Element ExtensionsWhen possible, the user agent should use aliasing to implement any non-standard pseudo-elements. When not possible, the user agent must reserve the standard pseudo-elements for appearance: base and use any non-standard ones for appearance: none. 5. Pseudo-Classes5.1. Targeting Different Meter States: the :low-value / :high-value / :optimal-value pseudo-classesMake sure this is able to replicate UA logic. [Issue #11336] Link these to the HTML definitions. The :low-value pseudo-class matches on a The :high-value pseudo-class matches on a The :optimal-value pseudo-class matches on a 5.2. Targeting Selects that are ListboxesDefine something. [Issue #7422] 6. The control-value() functionThis is not ready for implementation, file an issue regarding this. Consider privacy implications, regarding data exfiltration. [Issue #11860] Consider adding more types. [Issue #11842] The control-value() function computes to the current value of the form control it is on. If it is used on an element that is not a form control, it returns an empty string. <control-value()> = control-value( <type>? ) <type> = '<' [ number | string ] '>' If used on a pseudo-element, it is evaluated against its originating element.
For example, to show on the value of a range input next to it:
input 7. Styling Widgets7.1. Switching form control sizing: the field-sizing property
For the purpose of this specification,
an element with default preferred size is an element
whose intrinsic size is fixed regardless of the size of its content.
The host language defines which elements are applicable to it.
For example, in HTML
For instance,
textarea has a fixed size regardless of its content by default:
⎸ The quick brown fox jumps over the lazy dog. If field-sizing: content is applied, the size of the former should fit to a text caret. ⎸ If field-sizing: content is applied and its width property has a fixed value like width: 10em, the element height depends on the number of the content lines: The quick brown fox jumps over the lazy dog.⎸ 7.2. Fieldset layoutWhen a fieldset is in base appearance mode the layout and rendering behaviour as defined in the HTML specification, do not apply to the fieldset or its legend. 7.3. Changing the Orientation of a Slider-Like Control: slider-orientation
7.4. Obscuring sensitive input: the input-security propertyThe CSSWG has agreed that while we believe that providing this piece of functionality to users is important, doing it via CSS+JS is the wrong approach, and that instead it should be built into user agents: this needs to work consistently from site to site for it to be discoverable and understandable by users, this needs to work even when JS is turned off, and this needs to have consistently solid accessibility… We therefore intend to remove this from the specification, and instead, we would like to see this behavior specified in the HTML specification as part of the interaction model of password fields. Holding off deleting until the situation with HTML is clarified. See https://github.com/w3c/csswg-drafts/issues/6788 and https://github.com/whatwg/html/issues/7293.
For the purpose of this specification,
a sensitive text input is
a text input whose purpose is to accept sensitive input,
as defined by the host language.
For example, in HTML By default, user agents obscure the contents of sensitive text inputs in order to prevent onlookers from seeing it. Users may wish to temporarily disable this obscuring in order to confirm that they’ve typed their sensitive information correctly. The input-security property may be used by authors to enable or disable this obscuring.
While the exact mechanism by which user agents obscure the text in the control is undefined, user agents typically obscure sensitive text inputs by replacing each character with some suitable replacement such as U+002A ASTERISK (*) or U+25CF BLACK CIRCLE (●).
For instance, given this style sheet
and this HTML
a user agent might render the <input type=password> like so:
●●●●●●●●●●●
Appendix A: Basic Appearance User Agent StylesheetThis section needs refining with implementation. Basicsinput Layout
SlidersRefine meter, progress, switch and range input styling. [Issue #12267] input Checkboxes & radiosinput Buttons (and button-like controls)button Color Inputinput SelectsSee base appearance user agent styles specified in HTML. Text inputstextarea The above must apply to textareas and textual inputs only.
ChangesSince the First Public Working Draft of 25 March 2025
Privacy ConsiderationsNo new privacy considerations have been reported on this specification. Security ConsiderationsNo new security considerations have been reported on this specification. AcknowledgementsThanks to Aditya Keerthi, Anne van Kesteren, Elika Etemad, Jen Simmons, Joey Arhar, Jon Davis, Simon Fraser and Theresa O’Connor for their input on this proposal. Thanks to Ana Tudor for her detailed analysis of | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |