Re: [whatwg] Add input Switch Type
On Wed, Dec 18, 2013 at 6:46 PM, Brian Blakely anewpage.me...@gmail.com wrote: A switch is definitely NOT simply a styled checkbox. As I mentioned earlier, you can slide/drag a switch to change its value. Also, a switch typically animates, whereas a checkbox is essentially a more static interaction. Sounds entirely presentational to me. A switch is often used to indicator more than true/false (which should ultimately be represented). A checkbox and a switch both have two states, which can always be reduced to true/false in principle. Both are used to indicate things which may not be superficially boolean, although I would agree that using a default-styled checkbox for that (though I've seen it in the wild) is unintuitive. Switches on the Web are currently janky, inconsistent and difficult to implement. A good reason to make them easier to implement by styling a checkbox. That is essentially the exact same reason that type=week or type=color have value. Before formal implementations, they had been implemented for a very long time with type=text and mountains of dubious code. Both have a specific meaning that wasn't adequately provided for by other input types. We already *have* a two-state input type. Making a switch out of input type=checkbox isn't abusing anything - it's a perfectly reasonable alternative presentation for the concept.
Re: [whatwg] Add input Switch Type
On Tue, Nov 19, 2013 at 6:29 AM, Elliott Sprehn espr...@chromium.orgwrote: On Tue, Nov 19, 2013 at 1:37 AM, Jonas Sicking jo...@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. 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. +1, a switch is just a styled checkbox. We don't need more input types or attributes, we just need to standardize how to style type=checkbox. - E A switch is definitely NOT simply a styled checkbox. As I mentioned earlier, you can slide/drag a switch to change its value. Also, a switch typically animates, whereas a checkbox is essentially a more static interaction. A switch is often used to indicator more than true/false (which should ultimately be represented). Regardless of what one's opinion might be on the similarity to checkboxes, input types in HTML are not subject to the same semantics as other kinds of elements. Half of them are purely presentational or pave cowpaths. Switches on the Web are currently janky, inconsistent and difficult to implement. That is essentially the exact same reason that type=week or type=color have value. Before formal implementations, they had been implemented for a very long time with type=text and mountains of dubious code. Considering that every major UI toolkit now includes switches discretely from checkboxes, it makes a great deal of sense to include them in the Web Platform. It does not make sense to exclude switches simply because we can abuse checkboxes to create something weakly approximate to a switch.
Re: [whatwg] Add input Switch Type
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:
++---+
| °C |== °F =| 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
Re: [whatwg] Add input Switch Type
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.
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.rantalai...@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
Re: [whatwg] Add input Switch Type
On Tue, Nov 19, 2013 at 1:37 AM, Jonas Sicking jo...@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. 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. +1, a switch is just a styled checkbox. We don't need more input types or attributes, we just need to standardize how to style type=checkbox. - E
Re: [whatwg] Add input Switch Type
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg- 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. Interestingly, Microsoft's Windows Store apps guidelines disagree. I find their reasoning somewhat compelling, although novel: http://msdn.microsoft.com/en-us/library/windows/apps/hh465475.aspx Use a toggle switch for binary settings when changes become effective immediately after the user changes them. Use a checkbox when the user has to perform extra steps for changes to be effective. These aren't exactly semantic differences, but I think they reveal different underlying semantics. Roughly, we have two controls which each have two states. But the meanings of those two states are completely different for switches vs. checkboxes; perhaps it could be boiled down to on vs. off for this thing and yes vs. no for this option.
Re: [whatwg] Add input Switch Type
On Tue, Nov 19, 2013 at 2:25 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Use a toggle switch for binary settings when changes become effective immediately after the user changes them. Use a checkbox when the user has to perform extra steps for changes to be effective. On the other hand, we have these two type of experiences on the web already and they are not limited to checkboxes. Introducing different controls for effectively the same action with the only difference being whether you need to hit submit seems somewhat contrived. -- http://annevankesteren.nl/
Re: [whatwg] Add input Switch Type
There is certainly a semantic difference between switches and checkboxes. As much of a difference as between buttons and links. A checkbox is part of a checklist, something you use to indicate or track the states of things. You put a series of checkmarks on a form, then bring it to the reception desk. A switch, like a button, is a mechanical control that actuates something. You flick a switch to turn the light on. Technically, a switch could be implemented as a styled checkbox with JavaScript attached. But as a website visitor, I would rather not deal with a dozen websites offering a dozen different switch appearances and behaviours attached to mousedown, mouseup, click, tap, drag, and swipe. MZ. -- Michael Zajac http://zajac.ca/ +1-204-943-6596 On 2013-11-19, at 8:39, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Nov 19, 2013 at 2:25 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Use a toggle switch for binary settings when changes become effective immediately after the user changes them. Use a checkbox when the user has to perform extra steps for changes to be effective. On the other hand, we have these two type of experiences on the web already and they are not limited to checkboxes. Introducing different controls for effectively the same action with the only difference being whether you need to hit submit seems somewhat contrived. -- http://annevankesteren.nl/
Re: [whatwg] Add input Switch Type
2013-11-19 16:25, Domenic Denicola wrote: From: whatwg-boun...@lists.whatwg.org [mailto:whatwg- 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. Interestingly, Microsoft's Windows Store apps guidelines disagree. I find their reasoning somewhat compelling, although novel: http://msdn.microsoft.com/en-us/library/windows/apps/hh465475.aspx Use a toggle switch for binary settings when changes become effective immediately after the user changes them. Use a checkbox when the user has to perform extra steps for changes to be effective. From the usability and accessibility point of view, this seems to address an important issue. Authors sometimes use checkboxes (or radio buttons) so that changing their state has an immediate effect, even submitting a form. This may violate normal user expectations and can be confusing. Normally, we enter some data, using various controls, and then click on a button (or do something equivalent) to request for an action. Checking a checkbox should not be a commitment, any more than typing text in a feedback form or selecting an item from a dropdown list in an order form should be a commitment. This means that things that have immediate effect should be buttons, or something else recognized as action-triggering control. So why not use a button? Maybe because a button does not normally have a visible state. A toggle switch would thus logically be a combination of a checkbox and a button: it has a direct effect, like a button, but it remains visible (or otherwise perceivable) in an on or off state, like a checkbox. And it should probably have a dual ARIA role: role=checkbox button. But maybe this means looking at things in a too narrow perspective, as if controls were only used in forms that submit data to a server. A purely application-like page may conceivably have checkboxes and radio buttons that have immediate effects (say, so that in an image processing application, checking a checkbox immediately turns the image to grayscale). Checkboxes probably wouldn’t confuse a user who knows at all what he is using. On the other hand, toggles could be used, too. Maybe even better than checkboxes. Yucca
Re: [whatwg] Add input Switch Type
On 19 November 2013 19.13.44, Jukka K. Korpela wrote: From the usability and accessibility point of view, this seems to address an important issue. Authors sometimes use checkboxes (or radio buttons) so that changing their state has an immediate effect, even submitting a form. This may violate normal user expectations and can be confusing. Normally, we enter some data, using various controls, and then click on a button (or do something equivalent) to request for an action. Checking a checkbox should not be a commitment, any more than typing text in a feedback form or selecting an item from a dropdown list in an order form should be a commitment. This means that things that have immediate effect should be buttons, or something else recognized as action-triggering control. So why not use a button? Maybe because a button does not normally have a visible state. A toggle switch would thus logically be a combination of a checkbox and a button: it has a direct effect, like a button, but it remains visible (or otherwise perceivable) in an on or off state, like a checkbox. And it should probably have a dual ARIA role: role=checkbox button. But maybe this means looking at things in a too narrow perspective, as if controls were only used in forms that submit data to a server. A purely application-like page may conceivably have checkboxes and radio buttons that have immediate effects (say, so that in an image processing application, checking a checkbox immediately turns the image to grayscale). Checkboxes probably wouldn’t confuse a user who knows at all what he is using. On the other hand, toggles could be used, too. Maybe even better than checkboxes. I think you're overthinking this. A checkbox represents an input with binary state. As I understand it, whether the input is immediate or takes effect only on some kind of submission is defined by context - specifically, whether the checkbox is associated with a form with a submit button. This does not affect the fact that the input is fundamentally binary. In contrast, a button represents a single action, atomic from the user's point of view. Pressing the button again should (it seems to me) logically perform the same action again; if the action performed every time the button is pressed can only be described as something like toggle the X, you've done something wrong in your design. You should be able to make a checkbox look like a button (albeit, one presumes, one that remains pushed in order to represent its state), and *could* even make a button look like a checkbox (although I can't imagine why you would want to), but they represent different things underneath. A toggle or switch is an input with binary state. Therefore, it is a checkbox, with a different shape from usual. Incidentally, in the case of text to the sides of a styled switch, as mentioned above, it seems clear to me that the actual switch part in the middle is the input, and the text parts are labels, all inside an outer frame block.
Re: [whatwg] Add input Switch Type
On Nov 19, 2013, at 1:37 AM, Jonas Sicking jo...@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.
Regards,
Maciej
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.rantalai...@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
Re: [whatwg] Add input Switch Type
2013-11-19 22:27, Qebui Nehebkau wrote: A checkbox represents an input with binary state. As I understand it, whether the input is immediate or takes effect only on some kind of submission is defined by context - specifically, whether the checkbox is associated with a form with a submit button. This more or less summarizes the alternative look at the issue that I mentioned. But I’m still inclined into thinking that distinguishing between checkboxes and switches, or giving authors the possibility of making the distinction at the level of control elements, is a useful thing to do. It’s not too late to introduce it. Most pages still use checkboxes just as selections, selecting options for some action to be requested shortly. (The select element may be a lost cause: as a user, you can’t know whether a dropdown just sets an option or actually “runs” it.) In contrast, a button represents a single action, atomic from the user's point of view. Pressing the button again should (it seems to me) logically perform the same action again; It would be too restrictive to require that, and an reality, things don’t work that way. For example, if the action consists of deleting something, you just can’t repeat it next. Yucca
Re: [whatwg] Add input Switch Type
On Tue, Nov 19, 2013 at 9:28 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: It would be too restrictive to require that, and an reality, things don’t work that way. For example, if the action consists of deleting something, you just can’t repeat it next. Well, you can. Deletion is idempotent - deleting something that has already been deleted does nothing. However, if the action a button represents is not currently applicable, the button should be disabled; pressing the button again doesn't need to be possible. In any case, I don't mean to suggest that that should be 'required', just that it is part of the concept of a button and following it where possible is likely a good idea if you want users to form correct conclusions about what things will do.
Re: [whatwg] Add input Switch Type
+1 from the web author perspective. would be nice if this wasn't so Hackish and if the look was more consistent. I do agree that this could be achieved (maybe more backwards compatibly) with an switch attribute on the ```checkbox``` input type. Twitter:@alonisser https://twitter.com/alonisser LinkedIn Profile http://www.linkedin.com/in/alonisser Facebook https://www.facebook.com/alonisser *Tech blog:*4p-tech.co.il/blog *Personal Blog:*degeladom.wordpress.com Tel:972-54-6734469 On Sat, Sep 21, 2013 at 9:06 PM, whatwg-requ...@lists.whatwg.org wrote: Send whatwg mailing list submissions to whatwg@lists.whatwg.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org or, via email, send a message with subject or body 'help' to whatwg-requ...@lists.whatwg.org You can reach the person managing the list at whatwg-ow...@lists.whatwg.org When replying, please edit your Subject line so it is more specific than Re: Contents of whatwg digest... When replying to digest messages, please please PLEASE update the subject line so it isn't the digest subject line. Today's Topics: 1. Re: Canvas - Somewhat inconsistent rules in the spec for drawImage (Robert O'Callahan) 2. Add input Switch Type (Brian Blakely) 3. Re: Add input Switch Type (Tab Atkins Jr.) 4. Re: Add input Switch Type (Brian M. Blakely) -- Forwarded message -- From: Robert O'Callahan rob...@ocallahan.org To: Justin Novosad ju...@google.com Cc: Simon Sarris simon.sar...@gmail.com, WHATWG List wha...@whatwg.org Date: Sat, 21 Sep 2013 10:13:43 +1200 Subject: Re: [whatwg] Canvas - Somewhat inconsistent rules in the spec for drawImage On Sat, Sep 21, 2013 at 6:40 AM, Justin Novosad ju...@google.com wrote: If we do anything, it should be the latter (draw nothing) to avoid breaking existing apps. I agree. I commented on this a while ago, and I still think it's simpler and more robust for drawing a zero-size anything to just draw nothing. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * -- Forwarded message -- From: Brian Blakely anewpage.me...@gmail.com To: whatwg@lists.whatwg.org whatwg@lists.whatwg.org Cc: Date: Fri, 20 Sep 2013 18:36:53 -0400 Subject: [whatwg] Add input Switch Type iPhone OS introduced the switch control (http://i.imgur.com/TA79fo2.png) in 2007. Since then, there have been many attempts to recreate this on the Web Platform by hacking existing control types and using a lot of meaningless markup, to varying degrees of success. The proposal is to add a switch input type. When it is active, the UA should render a switch control. It looks like this: input type=switch on / The on attribute indicates whether the switch is in its on or off state. There is no off attribute, as switches are off by default. The values corresponding to each state are true and false, respectively. List of OSs that implement switch controls (likely incomplete): - Windows 8 - OS X - iOS - Android - Blackberry OS - Windows Phone The major advantage here, as with all controls in HTML, is that the behavior and default appearance of the control is guaranteed to be consistent for a user across the Web, and likely match their host OS as well. This is sure to be a very attractive and convenient solution for authors. -- Forwarded message -- From: Tab Atkins Jr. jackalm...@gmail.com To: Brian Blakely anewpage.me...@gmail.com Cc: whatwg@lists.whatwg.org whatwg@lists.whatwg.org Date: Fri, 20 Sep 2013 15:44:55 -0700 Subject: Re: [whatwg] Add input Switch Type On Fri, Sep 20, 2013 at 3:36 PM, Brian Blakely anewpage.me...@gmail.com wrote: iPhone OS introduced the switch control ( http://i.imgur.com/TA79fo2.png) in 2007. Since then, there have been many attempts to recreate this on the Web Platform by hacking existing control types and using a lot of meaningless markup, to varying degrees of success. The proposal is to add a switch input type. When it is active, the UA should render a switch control. It looks like this: input type=switch on / The on attribute indicates whether the switch is in its on or off state. There is no off attribute, as switches are off by default. The values corresponding to each state are true and false, respectively. List of OSs that implement switch controls (likely incomplete): - Windows 8 - OS X - iOS - Android - Blackberry OS - Windows Phone The major advantage here, as with all controls in HTML, is that the behavior
[whatwg] Add input Switch Type
iPhone OS introduced the switch control (http://i.imgur.com/TA79fo2.png) in 2007. Since then, there have been many attempts to recreate this on the Web Platform by hacking existing control types and using a lot of meaningless markup, to varying degrees of success. The proposal is to add a switch input type. When it is active, the UA should render a switch control. It looks like this: input type=switch on / The on attribute indicates whether the switch is in its on or off state. There is no off attribute, as switches are off by default. The values corresponding to each state are true and false, respectively. List of OSs that implement switch controls (likely incomplete): - Windows 8 - OS X - iOS - Android - Blackberry OS - Windows Phone The major advantage here, as with all controls in HTML, is that the behavior and default appearance of the control is guaranteed to be consistent for a user across the Web, and likely match their host OS as well. This is sure to be a very attractive and convenient solution for authors.
Re: [whatwg] Add input Switch Type
On Fri, Sep 20, 2013 at 3:36 PM, Brian Blakely anewpage.me...@gmail.com wrote: iPhone OS introduced the switch control (http://i.imgur.com/TA79fo2.png) in 2007. Since then, there have been many attempts to recreate this on the Web Platform by hacking existing control types and using a lot of meaningless markup, to varying degrees of success. The proposal is to add a switch input type. When it is active, the UA should render a switch control. It looks like this: input type=switch on / The on attribute indicates whether the switch is in its on or off state. There is no off attribute, as switches are off by default. The values corresponding to each state are true and false, respectively. List of OSs that implement switch controls (likely incomplete): - Windows 8 - OS X - iOS - Android - Blackberry OS - Windows Phone The major advantage here, as with all controls in HTML, is that the behavior and default appearance of the control is guaranteed to be consistent for a user across the Web, and likely match their host OS as well. This is sure to be a very attractive and convenient solution for authors. This is just a checkbox input with different styling, yes? ~TJ
Re: [whatwg] Add input Switch Type
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 consider it a different input type the way range and number are different, despite being semantically identical. On Sep 20, 2013, at 6:44 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Sep 20, 2013 at 3:36 PM, Brian Blakely anewpage.me...@gmail.com wrote: iPhone OS introduced the switch control (http://i.imgur.com/TA79fo2.png) in 2007. Since then, there have been many attempts to recreate this on the Web Platform by hacking existing control types and using a lot of meaningless markup, to varying degrees of success. The proposal is to add a switch input type. When it is active, the UA should render a switch control. It looks like this: input type=switch on / The on attribute indicates whether the switch is in its on or off state. There is no off attribute, as switches are off by default. The values corresponding to each state are true and false, respectively. List of OSs that implement switch controls (likely incomplete): - Windows 8 - OS X - iOS - Android - Blackberry OS - Windows Phone The major advantage here, as with all controls in HTML, is that the behavior and default appearance of the control is guaranteed to be consistent for a user across the Web, and likely match their host OS as well. This is sure to be a very attractive and convenient solution for authors. This is just a checkbox input with different styling, yes? ~TJ
