The QColor component provides a method to input colors.
For handling colors, also check out Quasar Color Utils.
Usage
Basic
With QInput
There are helpers for QInput rules prop: full list. You can use these for convenience or write the string specifying your custom needs.
Examples: “hexColor”, “rgbOrRgbaColor”, “anyColor”.
More info: QInput.
No header or footer
You can choose if you don’t want to render the header and/or footer, like in example below:
Custom default view
You can also pick the default view, like in example below, where we also specify we don’t want to render the header and footer. The end result generates a nice color palette that the user can pick from:
Custom palette
Force dark mode
Default value
Lazy update
Disable and readonly
Native form submit
When dealing with a native form which has an action and a method (eg. when using Quasar with ASP.NET controllers), you need to specify the name property on QColor, otherwise formData will not contain it (if it should):
Accessibility v2.25+
QColor is only partially accessible, and which view is active matters. The Tune view — native text/number inputs plus sliders — is the keyboard and screen reader path. The palette swatches and the spectrum panel, on the other hand, are pointer-only: they cannot be reached with the keyboard and expose nothing to assistive technology.
The parts that are exposed carry localized accessible names from the Quasar Language Pack (colorPicker.*): the view tabs, the header’s color value field and the hue/opacity sliders, none of which the consumer can name from the outside.
A disabled QColor exposes aria-disabled="true" on its root element.
If your app needs accessible color input, start users in the Tune view (default-view="tune") or provide an alternative way of entering the color (e.g. a plain QInput accepting a hex value).