Toggle Switch Discussion

18 views
Skip to first unread message

Mark Tomlin

unread,
Oct 20, 2009, 3:25:18 AM10/20/09
to iui-dev...@googlegroups.com
I've been working on what I've been referring to the 'toggle switch problem' for the past 4 weeks now. I've come up with some solutions that I agree don't quite fit into the project at this point in time. However, I also feel that the current implementation must be changed to allow for a more standards compliant approach.

The current implementation.
The current state of things, in both 0.30 and the 0.40 dev-release, has a parent div with the class toggle and the non-standard attribute toggled, then child spans making up the thumb element, toggleOn and toggleOff parts. The problem with this? No way to make this data transfer to the server without JavaScript being enabled.

Markup example:
<div class="toggle" onClick="" toggled="true">
  <span class="thumb" />
  <span class="toggleOn">On</span>
  <span class="toggleOff">Off</span>
</div>

Past proposed changes.
In the past I proposed the use of the input element and the type checkbox be used, and that's good for the current implementation within the iPhone OS. Currently within the iPhone OS, the value of the toggle switch can be true or false, on or off, and this translates well into the checkbox input type as it's a Boolean type. However should functionally change in the iPhone OS to allow for a third, or even forth state, this implementation would fall short. The change also used static images as the precursor and did not allow for the graceful changing on one value to another (via the -webkit-transition [hat-tip jQTouch] declaration.) The problem? Does not fix all of the bugs it sets out to fix, and makes some of its own. Yes you can now post and get your information to your client with the use of the native browser functions, but this does not allow for a true abstraction from the model and the view (MVC). I have to hard code element type into the CSS to get it to show what color should go where. Fixes of this would be chaotic at best.

Markup examples:

<input type="checkbox" class="toggle blue" name="gauze" />


A current consensus?
Im looking for a consensus on how this should be handled. Sean Gilligan suggested the use of option elements. I like this idea as it allow for more then two values to be placed into the current format (future proofing the element) and the use of CSS gradients for the background color was a masterful stroke on his part. Seeing as it's supported in all webkit browers, and as of FF 3.6 we will have a gecko counterpart as well. I've already developed some elements with css gradients, and that is a non issue, what the main issue is however comes back to the element used to build the object in the first place. I can't think of a way to make the child elements (option) take over the select area. effectively when you click on the toggle switch it would jump to the next option in the list.

Markup examples:

<select name="gauze" class="toggle">
  <option value="On" class="blue">On</option>
  <option value="Off" class="orange">Off</option>
</select>

Now if only I could make that work.

--
Thank you for your time,
Lt. Mark 'Dygear' Tomlin (2922);

Mark Tomlin

unread,
Oct 20, 2009, 5:27:40 AM10/20/09
to iui-dev...@googlegroups.com
Floating some ideas between the my previous recommendation and the current recommendation goal (option select pairs, as proposed by Sean Gilligan) as stated in the last message. It will use a more advanced implementation of the input check box type though the use of the class attribute. Syntactically it will look like this:

<input type="checkbox" class="toggle onOrange offBlue" name="gauze" />

Each color will have to define it's own class name that can be used in both the on and off position, but coloring the button orange will not force that state in both on and off positions as my previous recommendation does without some heavy CSS workarounds. Yes, I'm poking holes in my old code, but like any good developer I'm also eating my own dog food and seeing where the short comings are. My previous code set out to fulfill a goal, and while it meets that goal with some hackish css, it does not do so elegantly.

Back to the Syntax example, and focusing on the class attribute you'll notice that toggle is it's main class. I am thinking about setting the CSS code up in such a way that would allow the use of these elements outside of the scope of a iUI project just by copy / pasting the CSS, I fell that not only does this produce agile code, but also conforms with an MVC architectural pattern that I really want to employ on this project. The toggle class it's self sets up the buttons default state, whereas it sets the unchecked color to white, and it's active checked color to blue. So by simply putting in class="toggle" your doing the equivalent of writing class="toggle onBlue offWhite", as is with the iPhone GUI. The class also sets up more basic things like element width, height and rounded edges radius.

input[type=checkbox].toggle {
  width: 94px
  height: 27px;
  -webkit-border-radius: 5px;
}

The more and more that I think about this, the more and more that I realize that the On off Off label will not display at all, unless JavaScript is used, but that breaks the MVC. We can't have a gradient and an background-image and the problem with that is, there is no way to tell if the element is on or off, people will have no idea it gives no feedback. The only way to handle toggle switches in any sane way currently that I can see is by using images, and that's not desirable at all. We need a better way then what we have, and we need a better way of so far anything I've come up with. This was meant to be a stopgap and it falls short.

Anyone else have any ideas?

On Tue, Oct 20, 2009 at 3:25 AM, Mark Tomlin <dyg...@gmail.com> wrote:
Past proposed changes.
[ ... ]

Markup examples:

<input type="checkbox" class="toggle blue" name="gauze" />


A current consensus?
[ ... ]


<select name="gauze" class="toggle">
  <option value="On" class="blue">On</option>
  <option value="Off" class="orange">Off</option>
</select>

Mark Tomlin

unread,
Oct 20, 2009, 5:44:51 AM10/20/09
to iui-dev...@googlegroups.com
On Tue, Oct 20, 2009 at 5:27 AM, Mark Tomlin <dyg...@gmail.com> wrote:
Anyone else have any ideas?
On Tue, Oct 20, 2009 at 3:25 AM, Mark Tomlin <dyg...@gmail.com> wrote:
<select name="gauze" class="toggle">
  <option value="On" class="blue">On</option>
  <option value="Off" class="orange">Off</option>
</select>

In case you where all wondering, yes, I do have nothing better to do at 05:35 in the morning then to think of problems and (hopefully) solutions to problems.

With the option select pair as shown in that quote, anyone have a plan on handling iPhone's list view. In the current version of the iPhone's Safari browser, when you click on select elements that have option values you are greeted with a list scroller. Anyone have any idea how to suppress that? We might just be stuck with the image checkbox toggle switch idea as far as standards compliant code within in the MVC architectural pattern.

And now it's time for me to get some sleep (30 hour days are killing me), maybe some fresh eyes will help me be more optimistic and see the light.

Sean Gilligan

unread,
Oct 20, 2009, 12:11:09 PM10/20/09
to iui-dev...@googlegroups.com
Mark Tomlin wrote:
> I've been working on what I've been referring to the 'toggle switch
> problem' for the past 4 weeks now. I
>
> A current consensus?
> Im looking for a consensus on how this should be handled.

I don't think there will be a consensus until people have compared
working examples of each approach. Or at least a working example of an
approach other than the current one.

> Sean Gilligan suggested the use of option elements. I like this idea
> as it allow for more then two values to be placed into the current
> format (future proofing the element)

I'm not so sure how important more than two choices are for the
"toggle". A slider with more than two positions would be useful, but
could be implemented separately from the "toggle". The reason I
recommended the select/option was so the ON/OFF labels would be in the
element and localizable.

> and the use of CSS gradients for the background color was a masterful
> stroke on his part. Seeing as it's supported in all webkit browers,
> and as of FF 3.6 we will have a gecko counterpart as well.

The gradient would be a stylesheet implementation and those wishing to
support older iPhone OS or other browsers could still use images.

> I can't think of a way to make the child elements (option) take over
> the select area. effectively when you click on the toggle switch it
> would jump to the next option in the list.
> Markup examples:
>
> <select name="gauze" class="toggle">
> <option value="On" class="blue">On</option>
> <option value="Off" class="orange">Off</option>
> </select>
>
> Now if only I could make that work.

Do you have a link to a page that demonstrates the problem and your
work-in-progress? I don't know if it will be possible to make
select/option approach work (i.e. look like a toggle) without
JavaScript. It might be necessary to hide the select/option and add
elements to the DOM to get the appearance correct. With JS disabled
you'd still be able to use the form, but it would not have the "toggle".

-- Sean

Reply all
Reply to author
Forward
0 new messages