$ git clone git://github.com/shichuan/mobile-html5-boilerplate.git
$ cd mobile-html5-boilerplate
$ ./build/createproject.sh
-bash: ./build/createproject.sh: Permission denied
$ sudo ./build/createproject.sh
sudo: ./build/createproject.sh: command not found

Can't run the build script for some reason

Hey, what are your thoughts/plans for the CSS used in MBP?

I get this error when running the build script.
ERROR: For JavaScript or CSS compression YUI compressor jar file must be present in the same directory as HtmlCompressor jar.

I read an issue on the build script for the regular html5 boiler plate and someone recommended to just rename yuicompressor-2.4.5.jar to yuicompressor-2.4.2.jar. So i tried that but some reference somewhere doesn't get updated cause the script still searches for the old jar. Paul Irish recommended to download the new htmlcompressor jar and so i tried that to but with the same result. The script searched for the old jar file.

I have searched like a mad for where in the build script the jar's get referenced but i just can't seem to find it.

Is there a reason that the BP uses single quotes for attributes on things like this:

document.write("<script src='js/libs/respond.min.js'>\x3C/script>")

Shouldn't the JS use single quotes and give the HTML double quotes? Also happens on the jQuery write as well.

Just curious. Obviously not a huge priority. Thanks.

Hi,

I think I found a small bug, in /index.html, on line 68, the jquery fallback url is wrong.

unescape('%3Cscript src="js/jquery-1.5.0.js"%3E%3C/script%3E')

Do you mean this?

unescape('%3Cscript src="js/libs/jquery-1.5.0.js"%3E%3C/script%3E')

missing "/libs"

Br,
kisPocok

You can replace

<!--[if (gt IEMobile 7)|!(IEMobile)]><!-->

with

<!--[if gt IEMobile 7]><!-->

and get the same result.

The build script concatenates project styles before default styles. Should change line 21 of build.xml from:

I don't know exactly why but the jquery is overwriting the css background property of the body. This happens only with boilerplate.

If I add jquery on a simple html file and add a background property do my body, it works.

This happens only with BlackBerry. o.O

I have tried putting MBP.hideUrlBar(); at the bottom of my page above scalefix but nothing seem to happen, I have it working on one site but this new site I'm work =ing doesn't work and I can't see why. Any suggestions?

As a new user to mobile-html5-boilerplate, and being somewhat new to HTML5 in general, I ran into quite a snag with trying to use mobile html5 boilerplate. My sample appeared to be running into some very aggressive cache issues. Try though I might, I was unable to get changes to my index.html file to reload in my browser. Short of actually flushing my cache (or opening in an incognito window), the browser wasn't event attempting to redownload the index.html.

In retrospect, this was probably something I should have figured out more quickly. However, I know much more now after having spent several hours trying to figure this problem out.

@paul_irish suggested I don't use an appcache and that I should remove it. Me removing it from my code at this point is not the issue. To me, the issue is that the appcache was enabled by default on a fresh download. Jumping into the standard html5 boilerplate does not have this issue. A developer can immediately start tweaking the index.html page and see their changes on reload. As I understand it, for the standard html5 boilerplate, getting an appcache is something you opt into.

At the very least, it would be nice if it were made more obvious on the mobilel-html5-boilerplate homepage (or at least documentation) what kind of ramifications having appcache enabled will have on a developer. Especially for those of us who are new to HTML5. Then we could make the decision to remove it (if appropriate) and hopefully avoid hours of head scratching wondering why updated content won't show up even after force reloading a page.

I would be happy to help contribute some notes for the website if that is the appropriate place to put them. I'd also be happy to contribute to the wiki documentation. If someone can point me in the right direction and anyone thinks this is a good idea to point out, I'll make it happen.

With iOS5 you can now use CSS media queries to serve correctly sized apple-touch-startup images for iOS web apps. No need for JS hackery any more. Maybe worth adding a note?

http://miniapps.co.uk/blog/post/ios-startup-images-using-css-media-queries/

The inclusion of the property initial-scale=1.0 in the meta viewport causes the zoom on rotation "bug" to happen on iOS devices. If you remove this property, the bug does not occur and the OS performs it's system default zoom on rotation.

I vote for removing this property as default on the mobile boilerplate because:

1.) it means messy JS hacks like the meta viewport JS fix are not needed.
2.) we stop seeing lots of sites that either a.) break on rotate/zoom b.) fail to pinch/zoom until the second gesture occurs
3.) it lets iOS perform it's default system behaviour, keeping in-line with user expectations.

Until there is a better fix I just see the current defaults causing more trouble than they're worth?

Just some food for thought.

Currently we have Cache-Control "no-transform" disabled by default in our apache config file and we are discussing if this should be enabled by default, if so, should it be applied to all files or just certain type of files under apache config. For those who don't know what Cache-Control "no-transform", here is a short description:

By including a no-transform directive in your Cache-Control header, you are indicating to proxies and transcoders that they should NOT modify your content. This is important where you have designed a mobile site, and you do not want a proxy or transcoder to modify it.

there are a couple of things we might need help (not super critical, but will be good to consider)

1. I have been thinking of adding in normalized events to our MBP helper: https://github.com/shichuan/mobile-html5-boilerplate/blob/master/js/mylibs/helper.js
   a. this includes touch/click virtual events: touch events, gestures, orientation
   b. normalized virtual events that bind to both mouse and touch events and keep whatever bubbles up first (so it works for both browsers with native support and those don't)
   c. custom scroll event, no?
   d. the events are independent from any framework
   issue #11

2. a practical use of Cache-Control "no-transform" to prevent mobile trans-coding.
issue #34

1. what's the best use of appache, maybe with more research (could be added to wiki, what are the things to consider). sometimes it messes up with scripting loading if not used properly.
2. jon neal has a suggestion about using class instead of medie queries, need more people's view
   issue #36
3. and the rest of less important issues: https://github.com/shichuan/mobile-html5-boilerplate/issues

there are a couple of things need to sort out for the js portion of mobile bp. which is the main remaining thing.

i try to make sure that the mobile version inherits the same nature as the main one:

1. keep it super lean, only the essential
2. platform independent, no self-imposed philosophy

currently there are only two extra js files compare to the main boilerplate, one is respond.js for css media queries polyfill.

anther is helper.js, which is the one i am improving, 1. want to make it framework independent, 2. still thinking if it's needed for the mobile boilerplate in the first place (if it's essential)

any feedback and help will be appreciated.

I keep getting a javascript errors in IE.

Only tested in IE8 and IE7, not sure about the others

I was just looking at this for ideas on how to improve my own templates, and noticed you only have an iphone-specific splash screen. I use this bit of code to allow for both iphone and ipad splash screens:

    <!-- For both iPhone and iPad support, we have to conditionally check which startup image to display. -->
    <script type="text/javascript"> 
    (function () {
      var filename = navigator.platform === 'iPad' ? 'splash-big.png' : 'splash.png';
      document.write('<link rel="apple-touch-startup-image" ' + 'href="/media/images/mobile/' + filename + '" />' );
    })();
    </script> 

https://github.com/doat/TouchyBP

I'm curious what they took from MBP and what we can take from them.

We could think of an alternative approach to media queries, there are a couple of reasons for this to at least worth considering (pointed out by Jon Neal on html5 irc):

1. files will get downloaded regardless of query matches
2. a lot backward compatibility issues
3. respond.js seems like a fix for media queries, but not without issues: scottjehl/Respond#12
4. it's quite slow to loop through all the content in CSS for browsers without default CSS MQ support

Alternative approach:
Jonathant Neal has a gridquery uses js query: https://github.com/jonathantneal/gridquery

Example usage:
http://www.liferay.com/

The build script works fine in the original boilerplate-mobile distro. But after I create a new project via the .createproject.sh, change to that new project, run ant, I get the following errors:

....
[apply] ERROR: For JavaScript or CSS compression YUI compressor jar file
[apply] must be present in the same directory as HtmlCompressor jar
[apply] Result: 1
[apply] ERROR: For JavaScript or CSS compression YUI compressor jar file
[apply] must be present in the same directory as HtmlCompressor jar
[apply] Result: 1
......
BUILD FAILED
/Users/mtaylor/Documents/mt/mobileapp1test/build/build.xml:137: The following error occurred while executing this line:
/Users/mtaylor/Documents/mt/mobileapp1test/build/build.xml:690: Warning: Could not find file /Users/mtaylor/Documents/mt/mobileapp1test/publish/default.appcache to copy.

Andy Clarke released his 320 and Up boilerplate earlier this week: http://www.stuffandnonsense.co.uk/blog/about/320_and_up

He writes that it's heavily based on the Mobile/HTML5 Boilerplate, but differentiates it from the MBP by saying it's written for the small screen first and works up to the desktop, not the other way around:
"Paul Irish, Divya Manian and Shi Chuan launched Mobile Boilerplate — a collection of mobile best practices that happens to include my previous Hardboiled CSS3 Media Queries but one that still starts, as I did previously, with a large screen first."

However the documentation for MBP clearly shows that it has been built with Mobile First in mind:
"CSS Media Queries bubbling up from a mobile baseline (aka Mobile First or Yiibu-style)" - V1.1 Changelog
"We use CSS bubbling up for mobile first responsive design" - The Style

We're being told two different things here, and while I'm in the process of working through both boilerplates in detail, making head and tails of the differences, I'm keen to see you guys weigh in with your own thoughts. All respect to Andy, but aren't his claims that the MBP starts with a large screen first inaccurate?

Consider Zepto (by @madrobby) for mobile version of boilerplate, instead of jQuery. Just an idea. Moved here from boilerplate issue tracker.

@paulirish said:

We currently support non-webkit mobile environments and plan to remain that way for a bit.
So zepto wont work. XUI however is worth considering..

If your target group from South America, Africa or India you must worry about Opera Mini. All other popular mobile browsers is based on Webkit:

• iOS (Safari)
• Android (Chrome)
• BlackBerry browser is based on Webkit and Mango
• WebOS
• Nokia (40 and 60 series)

Sources: 1, 2

The particular check should at least be made within that timed funtion.

should bump jQuery to 1.5.2 and there are still vestigial tests leftover from the OG boilderplate (which don't pass and aren't relevant to our interests).

There are 2 closely related issues:

1. (min-width) is a malformed media query. Safari/Chrome will pass the test, Firefox and Opera will fail the test and load Respond.js. When Respond.js loads in Opera, after the opening body tag, it exposes a bug and Opera does not extend the body background to fill the viewport.
2. Placing the test at the bottom of the page results in a FOUC in browsers without adequate media query support.

May I make a suggestion? This test should be placed in the head to avoid the problems above:

<script>Modernizr.mq('(min-width:0)') || document.write("<script src='js/libs/respond.min.js'>\x3C/script>")</script>

This will result in a pass in all modern browsers with support for (min-width), no background bug in Opera, and no FOUC in old IE.

I can provide this in a pull request later if it helps. Thanks

More details: Modernizr/Modernizr#241

Is the chrome frame reference really neccessary here? Surely it doens't work for mobile?

Hi,

I was reading your doc and wondered why you only try to hide the adress bar on IOS (with the scrollto(0,1) trick). The same scrollto also works in Android.

The main problem is that for the adress bar to hide, the height of the page must be sufficient to scroll either on IOS or Android. So if you want a full page without adress bar set to 100%, it can be a hassle.

For IOS, the best way is to use media query, as it's quite easy to only detect iphones & ipod. I can't remember the exact number, but I think the height must be at least 455 (portrait) or 178 (landscape) px to have a full page without adress bar.

As usual, on Android, it's a bit more complex, due to the different screen sizes. It can be achieved using js :

var real_height = window.outerHeight; // the real, "physical" height of the device
var pixel_ratio = window.devicePixelRatio; // the pixel ratio
new_height = (real_height / pixel_ratio ); // the total height of a fullscreen page without adress

Then set the min-height of html or body to this new_height. You page will always be high enough for scrollto to work and hide the bar.

There's a big problem : on orientation change, your new min-height will be false.

So you must add a listener on orientation change and re-fire the function. I personnally prefer to listen for resize and check if the height/width ratio changed, but it's up to you.

By the way, same problem on BBOS, although i did not make a lot of test here. For what I seen, it's quite easy to get a height enough to have a fullpage (the adress bar is 10 or 20px depending of the resolution), but scrollto(0,1) does not work. I could only test on my BB Bold 9770 and some emulators, and it seems that using strollto(0,60) works on all device (curve, bold, torch) using BBOS6.

Pardon my english,

currently, we specify mobile style in media queries, i think since we are mobile first, we could consider the default style is made for mobile, so to bubble up, we can do something like (not exact code, but the idea):
/*** default smartphone ***/

/*** smartphone landscape ***/
@media only screen and (min-width : 321px)  {
}

/*** iPad ***/
@media only screen and (min-device-width : 570px)  {
}

/***desktop***/
@media only screen and (min-width : 1024px) {
}

Just throwing this in here for discussion - I'm not 100% sure what is best to use, but Apple now recommends using a new 'sizes' attribute for different resolution home screen icons. This was introduced in iOS 4.1.

So, instead of using something like:

<link rel="apple-touch-icon" media="screen and (max-resolution: 80dpi)" href="apple-touch-icon.png">

<link rel="apple-touch-icon" media="screen and (min-resolution: 150dpi)" href="apple-touch-icon.png">

They now suggest you use something like:

<link rel="apple-touch-icon" href="apple-touch-icon-57x57.png" />

<link rel="apple-touch-icon" sizes="72x72" href="apple-touch-icon-72x72.png" />

<link rel="apple-touch-icon" sizes="114x114" href="apple-touch-icon-114x114.png" />

The big question is, why do Apple suggest using this over max-resolution? I'm not actually 100% sure max-resolution worked correctly across every iOS device, but I could be wrong.

I guess we also have to ask how many other platforms take notice and make use of this media query rule? Do any? If not, then I'd suggest following Apple's newer attribute?

EDIT - I do understand other platforms use the apple-touch-cion link rel, but what I am talking about here is do they use the max-resolution rule also?

Finally, it is also possible to provide these icons at different resolution without having to include the links in your HTML at all. So another thing to consider?

More info here in Apple's docs:

http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html#//apple_ref/doc/uid/TP40002051-CH3-SW4

This is arguably a corner-case, but I see it all the damn time anyway.

A designer makes an awesome-looking PSD that's fixed at 320 or 480 pixels or something.

That just doesn't work with the mobile paradigm, which thrives on fluid layout.

You've gotta implement it anyway.

Here's what you can do:

Here's what that does:

1. Android, iOS, and WP7 will render the page at the full width of the device, regardless of the device's own resolution.
2. iOS and WP7 will not allow user rescaling; Android doesn't listen to user-scalable unfortunately and users are allowed to pinch/zoom (maybe this can be disabled via JS without killing scrolling).

Fluid-width designs are harder to design and implement, that's all there is to it. People will continue to make fixed-width layouts, and this provides a friendly path which satisfies multiple platforms sufficiently.

Is it a best-of-best practice? I'm not sure, but it's a good thing to know.

my colleague @borismus grabbed the MBP and got that reaction.
I just downloaded the mbp 2.0 from the site (documented) ... here are my reactions

• can be removed: readme, .gitattributes, .gitignore, demo, .DS_Store's
• does sitemap.xml need to be in here? does the build script update it?
• mobile-bookmark-bubble seems cool though it took me a bit to figure out what was going on
• wspl seems needless as Gears is dead.
• GA for mobile ... not so sure. i think MBP is for apps and therefore we require JS. so phones without JS i'd say we dont support.
• modernizr is out of date

and

• we should run a mobiledemo.html5boilerplate.com to check out these bookmarkbubble etc

:)

re: http://news.ycombinator.com/item?id=2379585

We need to provide more detail on

• what this does
• why you'd use it
• some perspective on alternative approaches
• how you would toss users to mobile site by default but then allow them to return to the "desktop" experience

See also our discussion on H5BP vs MBP: https://groups.google.com/forum/#!msg/html5boilerplate/dNbB8ZGFNcM/u94fhLeVCg8J

See http://nerd.vasilis.nl/prevent-ios-from-zooming-onfocus/

Would be something like:

var $viewportMeta = $('meta[name="viewport"]');
$('input, select, textarea').bind('focus blur', function(event) {
  $viewportMeta.attr('content', 'width=device-width,initial-scale=1,maximum-scale=' + (event.type == 'blur' ? 10 : 1));
});

Thoughts? Let me know if I can add this :)

The following section,

@media 
only screen and (-webkit-min-device-pixel-ratio : 1.5), 
only screen and (min-device-pixel-ratio : 1.5) { 
/* Styles */
}

should also include:
only screen and (-o-min-device-pixel-ratio : 3/2)

That way, Opera Mobile 11 also understands the device-pixel-ratio query - note that 1.5 won't work, as Opera only accepts fractions as device-pixel-ratio values.

Shichuan,

To target landscape view in iphones you're currently using: @media only screen and (min-width : 321px). This is an actual mobile template but if you guys decide to merge with an html/mobile, the following MQ is the proper way to target landscape:

@media only screen and (min-width: 321px) and (max-device-width: 480px)

The reason is min-width by itself will take effect in regular browsers and adding that max-device-width will fix that.

Cheers!

I probably misunderstood those functionnalities so correct me if I'm wrong ;)

Since HTML5 is not implemented in older browsers (especially IE6-8, others are, generally, updated automatically), we need apache (and others) expires configuration to cache our files. Appcache is a great thing and avoid to change our filenames (cache-busting) but we must have both appcache and server conf so it leads us to put updated files on the both sides.

Then, I think using the both it's quite redundant and the default.appcache should be in the experimental features in the wiki, maybe while IE8 is largely used.

Another solution: a js library could add the manifest functionnality to IE<9...

What do you think about adding a smallish max-width to the body (or any container) on the base mobile-first styles? That way, for the few users with JS disabled in desktop browsers without Media Query support, the content will be readable and not go full-width of the monitor.

Scott Jehl (of jQuery Mobile, Filament Group, respond.js) has been doing a lot of work and doesn't see a case where the device- aspect is neccessary.

We use the hardboiled media queries which uses device- heavily.

Does anyone have a use case that is satisfied by device-max/min-width/height support only?

Was asking @nimbupani about whether these parts could be moved into an external JS file (perhaps the existing helper.js?).
Opening an issue as requested.

The 'hide location bar' code I found in MBP seemed a bit buggy, as the scrolling occured even if the user scrolled down the page within the one second. I believe this code fixes the issue. Perhaps someone could test and confirm it? And then update the MBP source?

Simon.

/iPhone/.test(MBP.ua) && !location.hash && setTimeout(function () { if (!pageYOffset) window.scrollTo(0, 1); }, 1000);

Minifying and delivering all the javascript in one big file leads to javascript errors because of the missing semicolon at the end of the modernizr-custom.js. Please also add exact (i.e. revision or released version number) version information into each javascript file.

I did a quick blog post here detailing a 1 line JS hack to enable CSS active pseudo styles in Mobile Safari:

http://miniapps.co.uk/blog/post/enable-css-active-pseudo-styles-in-mobile-safari/

I believe this also works on Android (although I have yet to test exactly which versions using the emulator). It also works on the Playbook browser (tested).

Maybe worth considering for inclusion? It should be commented out be default, since it is only needed it your web app is not already using touch events on click-able areas.

The idiot's guide to viewport and pixel ( https://docs.google.com/present/view?id=dkx3qtm_22dxsrgcf4 ) mentions the following:

[Slide 5] "You will need to specify target-densitydpi=160dpi to make sure the consistency of device-width on Android, so with this applied, the device-width will always be 320px:"

Afaict, this is not always correct: when used in landscape mode at 160dpi for instance, the Android browser and Opera Mobile 11 don't report a device-width of 320px, but rather of 426.6667px.

Using a 160dpi setting seems to make the Android browser, Opera Mobile 11 indeed behave a bit more as an iPhone browser at first sight, but I'm not sure if it is something to rely on. It already behaves differently in landscape mode (due to its 3/4 aspect ratio instead of the iPhone's 3/2), and I wouldn't be surprised if this difference would be even more explicit on devices with non-standard form factors and high screen resolutions. Indeed, what will happen when we force 160dpi on retina screens (you can't test it on the iPhone as it doesn't support target-densitydpi)? My guess is that this will result in text that is way too small.

Hence, the part on [Slide 6] "If left unspecified, it will not cause as much problem as the above, but you can't control the default dpi used, and that will cost inconsistency when used with CSS media query or JavaScript to detect screen width." does not make so much sense... Even if specifying it, you will encounter "inconsistencies" in the screen width (see previous paragraph). The good news is that we have media queries to catch those inconsistencies, so I don't see this as a "bug" we have to work around.

So, all that to say that at present and unless I've misunderstood something, my advice would be to stick with width=device-width (leave it up to the browser to handle DPI stuff), and tweak images where needed with device-pixel-ratio specific overrides. Only in very specific cases you'll want to specify a target-densitydpi value.

• site.. currently at http://www.lab.highub.com/mobile-h5bp/
• need video,
• more docs on viewport/devicedpi
  • probably just add to this http://www.blog.highub.com/mobile-2/the-complete-idiots-guide-to-pixels-on-mobile/ and integrate it into the site or something.

comment to keep track of additional stuff

Just a suggestion, it seems like a good idea to set -webkit-text-size-adjust to 100% instead of none. Setting it to none prevents font zooming in desktop WebKit browsers, which seems like an accessibility issue. Mobile Safari's default value is over 100%, which is why text is bigger -- so if you set it to 100% instead of none, fonts stay the correct size on mobile but can still be zoomed on desktop.

I don't think any desktop browsers support -ms-text-size-adjust, so the issue probably isn't relevant there, but for consistency's sake (and assuming the rule works exactly the same as WebKit's) it might make sense to change that value from none to 100% also.

I've found that the YSlow tool complains about none gzipped content for JS & CSS resources.

Despite the fact that the type attribute is optional in HTML 5, adding type="text/css" and type="text/javascript" respectively eliminates this problem.

Does anyone else find that YSLow reports CSS and / or JS content as not gzipped, or do I have some other localised issue (perhaps to do with MIME types on my server??)

If this is not a localised problem to me, I would suggest adding these attributes to the index.html file in order for gzipped content to work correctly.

i wonder if the boilerplate would benefit from commenting out, by default, lesser used boilerplate items.

according to the linked to http://appcachefacts.info :
"All resources must successfully return. If any do not — returning a 404 or 500, for example — the entire cache will be ignored."

so if, for instance, if the user has not included the splash.png (which i'd assume many users aren't), if they haven't updated the cache manifest to reflect that, they wont reap any benefits of the manifest.

could obviously be argued that anybody that cares about the benefits would be sure to update their manifest. and also what determines lesser-used items is debatable too.

MBP.fastButton() uses invalid JavaScript by passing an object instead of a function to element.addEventListener. This throws an invalid type error in blackberry 6 browser.

W3C specifies that the second argument to addEventListener needs to evaluate to a function.