Shi Chuan, an excellent frontend dev from Singapore joined our development team last fall and spearheaded the Mobile Boilerplate. I'm just very happy we have a smart avenue to distribute best practices-- mobile is a really hairy area.
I am bit reticent in using the .htaccess in this package; how would you go about still offering the option to visit the standard website? This seems to directly redirect all mobile user agents to the mobile variant.
Right now that UA sniff to mobile redirect is a little undercommented. We'll address this.
We just wanted to highlight one of the most robust detection sniffs available. It is left commented out by default. And it's up to you in case you want to hijack your mobile users to toss them to your mobile site. (And yes I agree we should allow them to go back)
This looks great! I'm assuming you could then plug-in jQuery Mobile to take advantage of the UI widgets for a very nice mobile-optimized website. Then use something like PhoneGap to bundle it as a native app (if needed).
The site says it works well with Sencha Touch. What would you gain there? It seems many of these features are built in to Sencha Touch and it's limited to iOS, Android and Blackberry 6, anyway.
Are you suggesting using Boilerplate as a complement where Sencha Touch doesn't work? I can see how this might work well. Any suggestions on how one might take this route?
Perhaps you could build around Boilerplate and conditionally include the js/css for Sencha on iOS, Android and Blackberry 6.
> This is the first time I've heard of Mobile Boilerplate. Can you provide
> some background info? Specifically I am wondering, why desktop/mobile are
> separate rather than combined into one download? What is the suggested
> implementation of a site with both desktop & mobile versions?
HTML5Boilerplate is the one you should use if you are getting started
on websites. It is optimized to work and adapt on mobile browsers.
Mobile HTML5 Boilerplate is optimized for web apps that are explicitly
written to have different UX while on devices other than the desktop.
* This means they might want to imitate the UI of native applications
or be close to it.
* They may make heavy use of touch-based UI paradigms and other
interactions that are not possible on a desktop browser.
* They explictly use media queries and other ways to detect a
non-desktop browser and serve an experience that is different.
When I say web apps, I mean websites that are used intensively to
accomplish certain tasks (like twitter.com / gmail.com / facebook.com
/ admin interface of wordpress.com ). These sites are required to take
advantage of the space available and help users accomplish their tasks
with minimal effort no matter what device.
On the other hand, we do have websites that users visit occasionally
because they found it on some friend's email or on reddit which has
content but users rarely interact with it (other than just visiting it
or at most leaving a comment), in which case html5 boilerplate would
be a good template to use. This would be a good option for most sites
that are content-rich and require minimal user interaction.
Unfortunately for us, mobile platforms are also creating silos by
specifying custom meta tags to use to optimize for their platform.
E.g. Apple recommends using apple-touch-icon meta tag to specify
things specific to webkit mobile browsers. Nokia has its own. We did
not want html5boilerplate to add such cruft to the defaults, but this
would be necessary for someone writing an application tailored to take
advantage of non-desktop devices. There is already a lot of
consistency, but we wish there was more standardization of mobile
optimizations.
His real html5 boilerplate isn't very useful. it's basically doctype html5 and css reset. It seems to me he's complaining that http://html5boilerplate.com/ doesn't have a better builder UI.
It is useful when you're just knocking something quick together as an experiment and you have no intention of ever deploying it in any serious way. The full boilerplate is overkill and actually creates more work for you in that scenario.
It seems the biggest problem is that the boilerplate seems to act more like a framework instead of just a library. If that's the case, then using this with other frameworks like Sproutcore and Cappuccino can prove quite daunting...
Paul Irish is really making front-end development exciting.