Closed chuanxshi closed 13 years ago
Just wanted to add a note on WHY:
We discussed this initially on the group: http://groups.google.com/group/html5boilerplate/browse_thread/thread/c11efe86ed4e74b2
Of course, we're committed to making the standard boilerplate work well on mobile devices. But a custom boilerplate makes a lot of sense for mobile web apps, where you're not targeting all platforms. During the development of this, we'll also be identifying where mobile/desktop best practices can be shared and brought to the other form factor.. :)
Hi guys, looks great so far. I think in a typical web app the user should not zoom in and out, because the site is already optimized for the screen size. Most of the time you have a table/list view which is used to display the content. (Like the mobile gmail site) So I suggest to add "maximum-scale=1.0; user-scalable=0;" to the meta viewport tag.
@iNils: This is a really interesting issue, it has been discussed by many developers before at: j.mp/bplateviewport
The current setting is copied from the master branch, I see it from a few points:
"initial-scale=1.0; maximum-scale=1.0;"
Theoretically, it's more of a mobile browser, because (quoted from: http://bit.ly/aGYiTz)
But..........practically, I did a test by switching my PC Safari to user agent: iPad, and used it to surf google/yahoo, I didn't get redirected to the mobile site, instead, i landed at the main google/yahoo homepage, so I think most major website treats iPad as desktop device.
So for now, i will adopt this, if anyone think otherwise, we can further discuss.
Hi Shi,
thanks for the long analysis, let me add some additional thoughts: I think the reason for a mobile template is to create a site which behaves and looks like a native app. For example if you have a GMail account you can visit mail.google.com with user agent set to "Mobile Safari iPad" and see that they have created a special iPad version which looks like a native iPad app. If you visit the same page with user agent set to "Mobile Safari iPhone" you will get an optimized page which looks like a native iPhone app. (different design patterns for iPad and iPhone) I guess we will see similar pages for Android and GalaxyTab (and what else is coming...). So these are the kind of sites I was thinking of when I read "mobile template". What these "web-apps" have in common is that it is not possible for the user to zoom in and out. As well as you mentioned you are not seeing the iOS scroll bars.
Just my two cents ;-) Btw. jQuery Mobile Alpha released, yay.
just a quick question. are you going to replace the GA tracking script with the mobile version? AFAIK, some older version of BlackBerry phones have javascript disabled.
the reason it's not added for now is that the mobile version of GA relies on server side language. It can be pointed out as an alternative or addon but won't be used to replace the normal GA code.
I am still in the process of testing all the A-grade mobile browsers and investigate some of the B and C grade browsers. Although smart-phone has less than half the market share in the mobile market, but nearly all web browsing is done on smart-phones and most have js enabled.
This brings out a bigger question about if there is a need to support D, F grade mobile browsers. For desktop, there are also 1000+ browsers. But we see most websites only support A grade browsers.
So far, I have doubt in a one for all solution like Blueprint, I posted some of the ideas in my blog post here: http://www.blog.highub.com/mobile-2/yahoo-blueprint-too-good-to-be-true/
the user base might be a little different here in indonesia.
blackberry phones rules here.. and from what i can gather from several of our most popular sites. opera mobile, opera mini and blackberry are the top mobile browsers. while safari mobile or android webkit are nowhere to be seen.
but that's months ago. i have to get back to you on that. need to get more accurate data :) but i hope that can give you a few stuff to consider.
While I was doing some Indonesia mobile campaign, I did realized that the majority of Indonesians use Blackberry, and I know that everyone has a BB code, an alternative to a phone number.
Part of the mobile web is harder than i originally thought to develop due to the market and culture difference.
If you have any data related to Asia mobile market, it will be great if you can share. Any bit of data would help :)
I haven't really looked at the mobile branch until recently but I just wanted to say I agree on your first comment. There's no need for IE hacks etc. in a mobile version. Great work.
Bryan sent me a link to the Nokia's mobile web templates: http://www.forum.nokia.com/Develop/Web/Mobile_web_browsing/Web_templates/
I am yet to dig in though.
I have borrowed some ideas from Forum Nokia :)
Here is a breakdown of some the current experiment on Mobile HTML5 Boilerplate.
Markup:
CSS:
JavaScript:
Server:
General:
@shichuan getting a bit too complicated isn't it? damn, mobile :P but the links you gave are great resources.. thx for the links.
btw, a bit off topic.. does anyone here will be attending the BlackBerry Devcon in Bali this January? maybe we can discuss more about this mobile issue.. send me a message if u do..
yup, the mobile is complicated due to strong lack of standardization, different mobile vendors are making up their own rules. It ultimately depends on a common standard. But for now, I think we have to work out some creative way to make things work. It's still under testing, review, and experimentation etc. feel free to suggest any creative ways to implement these without make it bloated :)
very nice work.
@shichuan, have you considered documenting how to make use of the wurfl stuff in the tools directory?
until now, i've been using chris schuld's browser.php (http://chrisschuld.com/projects/browser-php-detecting-a-users-browser-from-php/) and it's seemed decent enough...missed some winmobile phone running opera mobile that i need to add in there.
a brief search of stackoverflow & google in general showed some recommendations of: http://detectmobilebrowser.com/ http://detectmobilebrowsers.mobi/
really not sure of the caliber of either, and think wurfl is probably the most extensive, just contributing food for thought i suppose.
edit: of course, i see your 'user agent detection' link after i finally decide to comment. still think it could maybe be refined to more simply show how to serve up at least 2 different mobile versions...
A brief chat on IRC (with Moo--) led me to believe WUFRL is actually good with features but spotty with real device detection/UA parsing.
He was a big fan of the accuracy of http://detectmobilebrowser.com/
that'd be great if it works well enough...seems so much simpler/cleaner to implement.
for anyone interested, mobile tuts+ did a brief tutorial on using it: http://mobile.tutsplus.com/tutorials/mobile-web-apps/mobile-browser-detection/
since we should keep html5 boilerplate platform independent, maybe the best is to use either the jQuery or JavaScript version of http://detectmobilebrowser.com/ ?
i was thinking apache, for devices that don't support js.
about to roll out the php version of this into a pretty big site...i'll report back with any issues i encounter, if any.
@dustinhorton: cool, please keep us posted :)
@shichuan Very Good!
hey guys, it will be great help if anyone can try out the latest mobile h5bp @ https://github.com/shichuan/mobile-html5-boilerplate
There has been a lot changes, enhancement since the idea was out. let me know if you have any comments or thoughts, it will help the release. :)
I am closing this because any new ideas need to be on mobile-html5-boilerplate issue queue!
No offense to hard core DRY fans, this is an experiment of having a mobile only HTML, CSS and JavaScript template. Due to the load speed, performance, browser nature and HTML support of mobile devices, many developers argue it might be a good idea to keep Mobile site separate from desktop site from the presentation template layer.
updated link: https://github.com/shichuan/mobile-html5-boilerplate
Please feel free to give suggestions and contribute to the development. :)
Currently, it's still pretty experimental:
.... future development: