W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2013

Re: [whatwg] Add <input> "Switch" Type

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 19 Nov 2013 12:46:48 -0800
Message-id: <EEB532CB-C7CB-40A3-805B-1C8DFFCA843F@apple.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Mikko Rantalainen <mikko.rantalainen@peda.net>

On Nov 19, 2013, at 1:37 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> Realistically speaking, I don't think this will help much at all. Few
> websites like using the default styling for form controls anyway and
> so people would be just as unhappy with the default switch rendering
> as they are with the default checkbox rendering.

Default-styled checkboxes seem to be somewhat more common than default-styled buttons. We also get requests for an easy way to get a switch that uses the native iOS look from time to time, from authors who don't want to replicate the artwork and interactive behavior by hand.

In my opinion, figuring out general styling for all form controls is very useful, but an appearance value to provide a standard switch look and behavior would also be useful.


> The real fix is to allow styling formcontrols. It's one of the most
> requested features from web developers, yet no one has taken the time
> to research what it would take to do it.
> I'm quite sure that if someone comes up with a comprehensive and well
> researched proposal, that browsers would jump on it.
> And the fact that we now have shadow DOM defined should help a whole lot.
> / Jonas
> On Tue, Nov 19, 2013 at 1:04 AM, Mikko Rantalainen
> <mikko.rantalainen@peda.net> wrote:
>> Brian M. Blakely, 2013-09-21 02:03 (Europe/Helsinki):
>>> I was contemplating whether to propose a new input type, or an
>>> attribute valid only for checkboxes. But it isn't a checkbox, so I
>>> went with a new type value.  You can choose to slide the switch or
>>> click it in most OS implementations, so even the behavior is
>>> different from a checkbox.
>> I agree that the look and feel is different from checkbox but all the
>> differences seem to be purely presentational. If you disagree, you need to
>> elaborate a bit more.
>> I'd suggest pursuing something along the lines
>> input[type="checkbox"].switch
>> {
>>        appearance: lightswitch;
>> }
>> instead. That way you could use CSS media queries and use "lightswitch"
>> appearance for narrow viewports and regular checkboxes for wider viewports.
>> However, if you're requesting for more featured switch seen in e.g. newer
>> Android applications where the switch has embedded text labels to declare
>> the switch positions, there might be need for a new markup.
>> An example of such UI in ASCII graphics:
>> +----+---------------+
>> | 蚓 |========== 蚌 =| Temperature unit
>> +----+---------------+
>> (That is, a label "Temperature unit" with a switch with labels "degree
>> Celcius" and "degree Fahrenheit". In the real UI the label is on the left
>> and switch is aligned to right margin but I put it this way to have a
>> slightly better change for ASCII graphics to work correctly.)
>> I personally hate this UI and would much prefer using two radio buttons for
>> this. Still, this is a native UI concept on this platform and I see no
>> reasonable way to convert a real HTML radio button group into this using
>> just CSS. The closest thing is allowing to allow rendering a <select>
>> element with just options with a "lightswitch" appearance.
>> --
>> Mikko
Received on Tuesday, 19 November 2013 20:47:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:14 UTC