W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2012

Re: [whatwg] Allow empty string for input type=color

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 13 Jun 2012 22:19:04 +0000 (UTC)
To: Markus Ernst <derernst@gmx.ch>, Anne van Kesteren <annevk@opera.com>, Shaun Moss <shaun@astromultimedia.com>, Ashley Sheridan <ash@ashleysheridan.co.uk>, Alfonso Martínez de Lizarrondo <amla70@gmail.com>
Message-ID: <Pine.LNX.4.64.1206132213430.30734@ps20323.dreamhostps.com>
Cc: whatwg@lists.whatwg.org
On Thu, 3 May 2012, Markus Ernst wrote:
>
> I apologize in case this has been discussed before - the list archive 
> search seems to be broken right now, as it does not find any matches 
> when searching for "color".
> 
> I just noticed a note in the spec of input type=color 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#color-state-%28type=color%29:
> 
> "Note: In this state, there is always a color picked, and there is no 
> way to set the value to the empty string."
> 
> If I understand the spec correctly, entering no value defaults to 
> #000000, thus the required attribute does not apply. What are the 
> reasons for this? I am sure there were good reasons to specify it this 
> way, anyway I don't see them right now. "Not selected" is actually very 
> different from "black".
> 
> I see the following reasons for allowing the empty string:
> 
> 1. An application might want to give the user the choice of not 
> selecting a color. Not specifying a color is the easiest way to state 
> that the default color should be used, be it black or other.
> 
> 2. An application might want to force the user to make an explicit 
> selection. It may not be able to distinguish whether "black" was 
> explicitly selected, or the user forgot to specify a color.
> 
> 3. Applications need to deal with the empty string anyway, as legacy 
> browsers show a text field.

On Thu, 3 May 2012, Anne van Kesteren wrote:
> 
> "Not selected" is not something typically supported by native color 
> pickers.

On Fri, 4 May 2012, Shaun Moss wrote:
>
> The way things are done is not always the best way. Most colour pickers 
> are used in instances where "not selected" would make no sense.
> 
> However, as you're designing a widget for the web that may be used by 
> billions of people in any number of unforeseen ways, flexibility is a 
> virtue, and the option to clear the field would be an improvement. If 
> you don't allow a "not selected" or null option, this would basically 
> force all colour widgets to be required fields, which may not be what 
> the form designer wants.
> 
> To compare, some date pickers do not allow you to clear the field, but 
> some do. For the web, it's a useful feature.

On Thu, 3 May 2012, Ashley Sheridan wrote:
> 
> Would the colour pickers allow the selection of the alpha channel at the 
> time of choosing? If so, couldn't you allow a full transparent colour to 
> be used where null couldn't?

On Thu, 3 May 2012, Alfonso Martínez de Lizarrondo wrote:
>
> Being able to not select a color isn't so strange.
> Everyone is used to word processors, and they usually have an option to
> select the color for the text and background. And among those available
> colors there's an option to use the default text color or to use a
> transparent background/no color.

While it's true that certain colour pickers do have a "no colour" option, 
it is generally the case that, as with range controls, there's no "none" 
option in the typical UI.

I expect we will add support for this at a future time, just like we will 
likely add support for more detailed range controls (e.g. that have a min 
and a max slider).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 13 June 2012 22:19:42 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:43 UTC