Stealing this answer mostly from our mailing list thread on the subject...
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.
We are planning an update to the mobile version with the newer files
as well, but there is no significant disadvantage to using it today. We do not yet have a meeting point where we could just have one project, but we are hoping in the future it does
merge into one :)
