CSS Form Styling Module Level 1

A Collection of Interesting Ideas,

This version:
https://drafts.csswg.org/css-forms/
Issue Tracking:
GitHub
Inline In Spec
Not Ready For Implementation

This spec is not yet ready for implementation. It exists in this repository to record the ideas and promote discussion.

Before attempting to implement this spec, please contact the editors.


Abstract

This document is currently a loosely-structured set of ideas and inspiration for CSS form styling. It is not an implementable standard. Do not look at this as anything but a collection of ideas.

1. New Pseudo-Elements

This section defines some pseudo-elements for styling parts of form elements.

1.1. Styling form control pickers: the ::picker() pseudo-element

The ::picker() pseudo-element targets the popup picker of form control elements which have popup pickers, such as the select element. It is an element-backed pseudo-element.

::picker() = ::picker( <ident>+ )

Note: Once all of the controls that might support picker styling have it, then we might add a (no-argument) ::picker pseudo-element as well.

The ::picker() pseudo-element only matches when the originating element supports base appearance and has a popup picker. The specified <ident> must also match the unique picker name of the originating element. For example, the unique picker name for the select element is "select".

Since it is an element-backed pseudo-element, There is no restriction on which properties apply to the ::picker() pseudo-element.

In order for the ::picker() pseudo-element to be rendered, it and its originating element must be rendered with base appearance by applying appearance: base to both of them.

<style>
  select, select::picker(select) {
    appearance: base;
  }
  select::picker(select) {
    border: 5px solid red;
    background-color: blue;
  }
</style>

2. Basic Styling Proposals

This section sketches a few proposals for solving the form styling problem.

2.1. Prototypes

This idea, originally suggested by fantasai, is that we can style a handful of "prototype" elements. Browser UI designers can then take the styling of those elements and extrapolate the design into their own UIs. At minimum, things like text, backgrounds, and borders can be used. At the limit, things like internal padding, border-radius, etc might be used.

@control button {
  <declaration-list>
}

@control input {
  <declaration-list>
}

input::selection {
  <declaration-list>
}

...
You would be able to use styles for:

Most form controls, even a calendar widget or clock, are a combination of these three primitives in some way. If the UA is given the styling for these three primitives, and perhaps one or two more it can figure out how to style the rest.

For example, a calendar widget might have the month, the year, some buttons to move them around, the ability to click into them and edit them directly, and a representation of the days of the month. The selected day is selected. Perhaps the buttons only show up on :hover or :focus -- the UA decides. But it knows that a button should be this particular shade of blue with that particular border-radius and drop-shadow. The calendar might be shown in the colors of the input field, and the selected day in the selection color, and in all ways it will match the way the input fields look in the rest of the page.

Now, the author can’t decide, for example, the spacing between the year and the month name, or whether the button to change years has a solid arrow or a hollow arrow or a frilly one, and she can’t decide that there should be a black solid half-border between the month and the day field below it with 5px spacing. But the calendar will look like it belongs to the page, and the UA can come up with a different calendar layout when it ships one on a wide but short smart watch where the month and year are better placed on the side without breaking anything.

The black area is the button color; a very light transparency of it can be the glass color. The rollers are the input colors.
It’s hard to tell without more context, but for the one on the right, the clock face and the digital readout are @input colors, the highlighted bits are the highlight color, the Done button is the button styling, and the shaded area around the clock face is the same color as the button background.

2.2. Inverse System Colors

This idea, originally sketched by Florian and Tab, is to define an abstract set of colors that UI designers can then choose from when coloring their UI.

Tab’s suggested set of colors, from an Android color-extraction API proposal:

(where light ~75% lightness, normal is ~50%, dark is ~25%; vibrant is at least 30% saturation, ideally 100%, and muted is at most 40% saturation, ideally 30%)

That’s 11 colors, many of which should be drawable from the webpage’s own color scheme. We can auto-gen a bunch of them if you specify at least some of them, like genning the light/dark variants from the "normal-vibrant" color, or automatically setting text colors to white/black as appropriate.

There’s no guarantee that the input UIs will use the colors in the *same way* that the rest of the page does, though.

3. Miscellaneous Control-Specific Suggestions

<progress> and <meter> styling

Insert <select> and <datalist> styling proposal and/or whiteboard photo.

3.1. Select/Datalist Dropdown

  1. Only allow styling if both color and background are set.

  2. Option container:

    • backgrounds

    • borders

    • padding

  3. option

    • padding

    • borders

    • border-collapse?

    • backgrounds

    • display-inside is allowed, automatically blockified

    • not margins, position, float, width, height

    All options are contain:paint and BFCs.

4. Input UI Examples

This section catalogues as many input UI examples as we can screenshot, especially on mobile devices where they’re a bit "weirder".

4.1. Time Pickers

iOS time picker
Android time picker 1
Android time picker 2

4.2. Date Pickers

Android date picker

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[CSS-BACKGROUNDS-3]
Elika Etemad; Brad Kemper. CSS Backgrounds and Borders Module Level 3. URL: https://drafts.csswg.org/css-backgrounds/
[CSS-COLOR-4]
Chris Lilley; Tab Atkins Jr.; Lea Verou. CSS Color Module Level 4. URL: https://drafts.csswg.org/css-color-4/
[CSS-PSEUDO-4]
Daniel Glazman; Elika Etemad; Alan Stearns. CSS Pseudo-Elements Module Level 4. URL: https://drafts.csswg.org/css-pseudo-4/
[CSS-UI-4]
Florian Rivoal. CSS Basic User Interface Module Level 4. URL: https://drafts.csswg.org/css-ui-4/
[CSS-VALUES-4]
Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 4. URL: https://drafts.csswg.org/css-values-4/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[SELECTORS-4]
Elika Etemad; Tab Atkins Jr.. Selectors Level 4. URL: https://drafts.csswg.org/selectors/

Issues Index

<progress> and <meter> styling
Insert <select> and <datalist> styling proposal and/or whiteboard photo.