Tag: HTML5

Android Toast-like Alerts in HTML using CSS

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:

  1. Click save button.
  2. Get feedback that item has been saved.
  3. Manually go back to previous screen.

 

With toasts:

  1. 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:

http://snipplr.com/js/embed.js
http://snipplr.com/json/62077

[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.

http://snipplr.com/js/embed.js
http://snipplr.com/json/62078

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.

 

jQuery Mobile and Semantics

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:

 

http://snipplr.com/js/embed.js
http://snipplr.com/json/61645

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.

 

http://snipplr.com/js/embed.js
http://snipplr.com/json/61647

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.

One Click PhoneGap Build to Android Device Script

I’ve been fooling around with PhoneGap Build, and I really love it. I love that I don’t need to fire up Eclipse or XCode to start fooling around with an app. All I need is a text editor and a browser. What I especially love is the ability to integrate a github repository to the whole process. It makes following proper development practice, while living in the cloud, very easy.

But I’ve been spoiled for the last year or so. Being able to immediately preview on a connected device has ruined me for the command line, multi-step, manual crap. So at least on Android I’ve fixed it for myself by building a nice shell script that takes advantage of PhoneGap Build’s Web APIs to create a one-step build.

What’s involved:

  • Commit all uncommitted files to git repository
  • Push git repository to github
  • Tell PhoneGap Build to poll github for changes
  • Poll PhoneGap Build until Android apps have been rebuilt
  • Download App
  • Use ADB to install onto attached device.

So I wrote a little shell script to do it all for me. I hope it helps someone else who is struggling with the same workflow issue. The script is below.

http://snipplr.com/js/embed.js
http://snipplr.com/json/61101

Semantic HTML has Other Benefits

Just got done reading Our Pointless Pursuit Of Semantic Value at Smashing Magazine today. It’s a good read, and clearly spells out a true point: There is not a lot of value in wrestling over how semantic your code is for semantic’s sake. I totally agree with this. While SEO and accessibility are often cited as reasons to pursue semantics, quite frankly, there is a lot of thought that semantics don’t help as much as people think (examples of which the author notes.)
Does that mean that semantics are worthless, and you should just use a div and a span for everything? No, and I don’t think that’s what the author is saying.
Semantics means different things to different people, but I’ve always looked at it as the process by which I identify things in the markup. This identification is important because it’s what I use to go back and manipulate things through CSS and JavaScript. In that way the process of making your HTML semantic is a lot like naming variables in more traditional programming.
So I see the new set of semantic options in HTML 5 as more choice, and I welcome it. Why? Because it makes it possible to turn this:

https://gist.github.com/1358362.js?file=gistfile1.html

into this:

https://gist.github.com/1358370.js?file=gistfile1.html

It’s not a huge differece, and doesn’t change anything about the presentation, but does make it easier to read. So it allows me to write more easily understood and maintainable markup. Now that doesn’t mean I arbitrarily use new tags. I do consider the meaning behind the tags when I use them. But not so much so that I allow myself to get paralyzed by it. Do I care that 
address doesn’t technically mean postal address? Not in the least. Do I care that dl might not be blessed to be used exactly the way I am using it. Nope.

It comes down to this, using Semantic HTML in the hopes of communicating to browsers and accessibility tools might have some diminishing returns. However using Semantic HTML to communicate to other developers can still yield a lot of value.

BrowserLab is Free

A few months back I did a post about rewriting my site with HTML5. It just got reposted by DZone. It picked up a few reads including one from the Product Manger for BrowserLab, Bruce Bowman.

He took me to task for claiming that you had to be a CS5 customer to use BrowserLab. To quote Bruce:

While it is true that when registering CS5 apps, you are given an opportunity to also get a CS Live account, which includes BrowserLab, it is not required to buy a CS application – anyone can register for a free BrowserLab account, even if they don’t own any Adobe products. All that is required is an AdobeID. They just need to go to http://browserlab.adobe.com and follow the prompts to sign up.

Awesome, BrowserLab is free. Go forth and correct for the fact that browser companies love features and hate developers!

BrowserLab and DOM manipulation

I was recently working on a redesign to my site that required some DOM manipulation to make HTML5 semantic content like <header> and <footer> show up. Basically, you have to create those elements on page load to get IE to render CSS effects on them.

I was running into a problem where BrowserLab showed basically a blank screen for the IE8 version of my site. It was as if the HTML5 elements weren’t being added and therefore IE 8 wouldn’t render them.

That was close to the problem, it was that the rendering didn’t happen immediately on page load. BrowserLab has a fix for this. In the upper right corner, there is a setting named “Delay”. You can use this to delay BrowserLab’s capture and therefore wait until the entire page is rendered.

An awesome little feature that makes BrowserLab that much more useful.

 

 

HTML5, Browser Lab, Typekit and New Design

I just got done with a site redesign. I had a few goals:

  • Fool around with new semantic HTML 5 elements
  • Use web fonts for typography
  • Do some jQuery for interactivity
  • Do a proper mobile version

Semantic HTML5
It seems like such a geeky little thing, writing header instead of div id=”header”, but I was shocked at the improvement it made. Much fewer divs made the HTML code so much easier to read, and so much easier to detect an improperly closed div.