One of the little things I like about Android is the "toast." If you are not familiar with the toast, it is the little transparent notice you get that operations are done. The best example is the toast that tells you how long you will have to sleep before your alarm goes off. (Pictured here.)
I really like the concept. It usually short-circuits the whole item editing process.
Without toasts:
- Click save button.
- Get feedback that item has been saved.
- Manually go back to previous screen.
With toasts:
- Click save button & go back & get feedback.
I wanted to implement toasts in an HTML PhoneGap application. Now I know I could do this with just JavaScript, or with jQuery, but I really wanted to give CSS transitions a try. CSS transitions allow you to alter a CSS property over a set period of time. They work really well for this sort of case.
So the first thing I have to do is apply the transition.
You'll notice a couple of things here. One the syntax for the transform is pretty simple:
[browser css keyword]: [property to animate] [duration] [easing method]
Once you do that, the rest is really simple. Basically, all you have to do is change the value for the property you have added a transform to, and the browser takes care of the rest. So to fade out my toast, I set the opacity to 0. That's it.
See the demo.
Why do I like this:
- I always prefer doing visual things in CSS.
- This seems to me to be simpler than using JavaScript animations
- CSS transitions will be hardware accelerated on environments that support doing so.
Now, I have to tell you there are caveats:
- It doesn't work in IE
- I'm sure someone who knows more than I will put more in the comments
But it does work within the mobile browsers I tested on iOS and Android, which means I'm free to use this in my PhoneGap application.
I've been fooling around with jQuery Mobile, and I really like what it's capable of accomplishing. However I've had one nagging gripe with it. The amount of <div>s you end up creating. Most of the sample code looks like this:
That's a crap ton of <div>s for just one view. Not that there's anything wrong with
<div>s. It's just you get this many on the page and things start being hard to keep track of. "Is this the <div> that closes the header, the footer, the content, or the page?"
HTML5 added all of the cool new semantic elements like <header>, <footer>, and <article>, which help you describe your content better. It would be cool if you could use them with jQuery mobile. The data-role attribute still makes sense because as elements there can be more than one of them on a page--for example, a page header and an article header.
This is especially weird when you consider that "data-role" itself is an HTML5 construct. So why do we have to use <div>s everywhere? You don't. Something that wasn't entirely obvious to me before I tested it out is that you can totally use the new HTML semantic elements in your code, as it would appear jQuery mobile only cares about the data-role attribute when it comes to picking out your application elements. In retrospect it makes sense. Doing nothing but
<div>s in example code simplifies things, but it can be done much more semantically if you want.
Now, to be clear, I'm not saying I recommend you mark up your code this way in all cases. I'd say a page could be considered a <section>
as it is a collection of related elements, but
<div> is pretty much just as correct. With headers and footers, it makes a lot of sense to use them. The whole <header data-role="header"> might seem a bit redundant to some, but it beats a crap ton of <div>s in my book. Finally, only really makes sense if the content is standalone.
So I don't think everyone should run out and do this. And I haven't tested it out more rigorously than just a rudimentary proof of concept. But I'm going to do this, because I really like it.
