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.
tpryan.blog 
Hey Terry,
My question would be about how these html5 tags are handled by older mobile devices? Basically the non web kit ones or third party browsers.
LikeLike
Hi..,
this is karthikeyan.., i have tried as you have told above..,so now i can sure that it never gonna work out on devices like i-pad.., it works in our normal Browsers., Jus test it.., Correct me if i am not right.
LikeLike
My knowledge of mobile browsers isn’t great, but I suspect the reason they use elements in all the examples is that’s the only way to guarantee the supported features work as advertised. While more modern Smartphones based on newer WebKit engines are likely to work fine using the HTML5 tags.
If you look at the list of supported mobile platforms (http://jquerymobile.com/gbs/), the list is actually quite vast. I suspect the “Grade A” browser will only handle the HTML5 tags fine, but I suspect as your get down the list, that’s when you could see browsers having issues with HTML5 tags.
This is just an educated guess, and I could be wrong, but it’s something to think about if you choice to go this route.
That said, I personally love the semantics of HTML5!
LikeLike
Sorry to be late to updating this, but yes, these Semantics are challenging for older browsers. The jQuery Mobile team tweeted that to support this on older browsers you have to use the HTML5 shiv, and it makes things a little brittle.
That’s a fair point, but I’m targeting Android and iOS through PhoneGap, so I can keep my semantics. But make sure that your intended audience has browsers that understand this stuff.
LikeLike