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

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?

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.

The build file minifies/concatenates the js, but does not update the path to the minified file.

How to reproduce:

Get a clean mobile boilerplate Build it open publish/index.html, notice the path the helper.js () navigate to that path, notice the file is not there.

Steps to fix:

Update the path to the minified and concatenated js file in html file. (see css file for example)

In 4989cf9ee7442f49c85fb7f15c48d486075f3930 tests were removed from the repo. I want to suggest to re-introduce them in a lightweight form for helper.js since there is a lot of functionality. I think it is important to have some tests for the functions we write. Also it might help people get started with tests on their projects. Keeping them maintained shouldn't be that much of a problem I think.

If there is a need for that I would love to submit a PR.

jQuery has become the de facto standard JavaScript library on the web. Switching to jQuery 2.0.0 means we remove support for Internet Explorer 6, 7 and 8.

Reference #152.

We should be aware that jQuery 2.0.0 is still bigger as Zepto: Zepto: 26.6 KB, 10.1 KB gzipped jQuery: 81.1 KB, 28.9 KB gzipped

These numbers might be irrelevant when concatenating and minifying all scripts.

Now that iOS6 has finally fixed the infamous initial-scale bug on meta viewport handling, is it now time to reinstate initial-scale=1 as a default in MBP?

Also, should the current bundled scaleFix helper now be limited to work on just iOS5 and below?

Could it be removed even?

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

index.html is not valid HTML5 because a value of cleartype is not permitted for the http-equiv attribute in <meta http-equiv="cleartype">. (Either that or http://www.w3.org/TR/html5/semantics.html#attr-meta-http-equiv is out of date, which I suppose is entirely possible since it's a work-in-progress and all that.)

Assuming I'm not completely off base here and that producing valid HTML5 is important to the project, perhaps an acceptable solution is to enclose that invalid markup in a conditional comment like I've done here.

The comments around the invalid markup already indicate that it's for Mobile IE.

I believe the conditional comments are only supported on Windows Phone 7 and later, so I guess earlier phones will have to deal without the smoother typefaces. (I'm OK with that personally, but Windows Phones before Windows Phone 7 constitutes a vanishingly small portion of traffic to my sites.)

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.

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.

https://github.com/h5bp/mobile-boilerplate/blob/master/js/helper.js#L109

does this here not point to MBP Object? MBP has no method 'addClickEvent' . I try to insepect in google develop tool：

Browsers disabled flash by reason of it secuire problems (but enabled it after fixes). Note sure that it still nessesary. Let's push browser native capabilities, not plugins.