
Detect iPad Mini in HTML5? - mrtnkl
http://stackoverflow.com/questions/13248493/detect-ipad-mini-in-html5
======
minikomi

        +-----------------------+
        |   Are you using an    |
        |      iPad mini?       |
        |                       |
        |  [yes]        [ No ]  |
        |                       |
        +-----------------------+

~~~
natep
Most people will just click yes or no to get past this screen. Better to ask
"What iPad device are you using?" With options (with pictures?) of "iPad Mini"
and "iPad 1/2/3"

~~~
devcpp
/4

------
supercoder
You shouldn't need to know if it's an iPad Mini.

If your fonts / buttons are too small, then just make them bigger. Easy.

This will then mean it will be even more accessible on the 10" device.

Plus we've never bothered to know the PPI of the screens before, I've got a
15" screen that is 1920x1080 as well as a 50" screen. But I don't see anyone
checking for that. Just stick to reasonable sized fonts and buttons and you
should be good.

~~~
calinet6
Dilemma: the size of a finger doesn't change just because your screen is
higher resolution. A button and interface designed for the mini might look
goofy on the larger device; an interface designed for the larger iPad might be
entirely unusable on the Mini. And it's reasonable for designers to want to
solve that problem.

Furthermore, your example is anecdotal and fairly meaningless. I've got a 15"
screen that's 2880x1800, so what of it? I definitely don't run it at native
resolution—it's scaled 2x, or 1.5x down. And it Just Works because there are
APIs for native applications and in CSS that expose the pixel density so that
developers can deal with it gracefully. Why not do the same for other devices
which are also supposed to be high resolution—and more importantly—resolution
independent?

The truth is, all of these devices have different pixel densities, and we're
supposed to be moving in a resolution-independent direction, such that the
physical size of the device and the number of pixels on its screen are
completely arbitrary and controllable variables. Especially on mobile,
interfaces depend on physical size, not on resolution; the size of a the main
input mechanism does not depend on screen resolution or device size—it is
static. It is a finger. We should be able to control the UI correctly instead
of kludging around the problem.

This idea that you shouldn't need to design apps correctly is simply an excuse
for the lack of means to do so. It's a poor argument.

~~~
ricardobeat
The size difference between an iPad and iPad mini is nowhere near 1920x1200 vs
1280x800 on a 15" screen, it's only 20% smaller (44px vs 36px).

<http://jsbin.com/inuxah/1>

~~~
calinet6
What if they made a device that was 2 inches smaller than that with the same
resolution? Surely that would be unimaginable.

The need for good standards remains.

~~~
ricardobeat
They wouldn't, because it would have too high DPI. That's why they went for a
multiple with Retina screens. I remember seeing an Android with a 1280x800
display or similar, using "mobile-optimized" sites was a pain.

------
MrScruff
I imagine this is an intentional omission based on Apple's own research.
Personally, while I'm not in the market for an iPad mini it would irritate me
if developers tried to treat it as a separate target for layouts. The whole
point is it's supposed to be a (slightly) more compact iPad but behave
identically.

~~~
Tyrannosaurs
Or based on the frustration of iPhone users being punted onto second rate
"mobile sites" when the full site in Safari with a bit of zooming is
absolutely fine.

Don't give people any more information which they're likely to use to do dumb
things?

~~~
lukifer
This is the paradox of platforms in general: the more you empower smart, nice
devs, the more you also empower not-so-smart, not-so-nice devs.

~~~
Tyrannosaurs
Agreed.

With this though I'm not hearing any argument that suggests there's a
compelling reason to distinguish based on this platform. I'm not saying that
there isn't one, just that in a situation like that the chances are there will
be a lot more implementations that do something stupid with it than do
something good.

~~~
lukifer
I tend to side with empowering devs by default (of course), but I see your
point. Readability should be addressed with adjustable fonts on all devices
anyway. The only possible case I could see is augmented-reality stuff where
the real size matters, maybe such as rendering a ruler to the screen. An edge
case, admittedly, but if it were my edge case, I'd be pissed.

~~~
Tyrannosaurs
I'd certainly never say don't do something because devs can't be trusted with
it, though I don't think that's Apple's logic here.

If it's an intentional thing I think they genuinely (possibly mistakenly but
genuinely) believe that it's unnecessary rather than that it would be useful
but abused.

------
marcus
Already posted it on SO but here goes:

Play a stereo audio file and compare the accelerometer response when volume is
high on the right channel and on the left channel - iPad2 had mono speakers
and iPad Mini has stereo speakers built in

~~~
UnoriginalGuy
I assumed that was a joke.

While this might work, wouldn't the sound have to be audible to the user in
order for this to work? And therefore when you browse to a web-site it is
going to let out a bloop on LOUD just to test the device?

Personally if that happened to me I would never visit your web-site again.

~~~
marcus
iOS audio will only play in response to user generated event (click for
example) never when the site loads.

And I am not saying it has to be a random noise or very loud the accelerometer
on the iDevices since the iPhone 4 is superb a very low sound will probably be
sufficient. The sound can be easily integrated into the natural flow of the
site, as many sites already do small beeps or play music etc to provide
feedback to the user.

~~~
williamcotton
If you play the sound using the Web Audio API, you're not restricted by user
interaction.

~~~
gojomo
This specifically arrived for MobileSafari only in IOS6, right? Do you have an
example of a page demonstrating a sound without interaction for testing?

~~~
chc
If they are running a version of iOS older than 6.0, they are definitely not
using an iPad Mini, so you have answered the question in that case.

~~~
gojomo
My interest is in the digression -- playing sound without a user click to
initiate -- rather than the Mini-detection. So still interested in a
clarification/example of where this is possible.

------
JoelSutherland

        iPhone 3GS: 160dpi
        iPad Mini: 163dpi
        iPad 2: 129dpi
    

The iOS guidelines are 40 points for a button on all devices. So a button on
an iPad mini is the same physical size as a button on an iPhone. Complaints
about fixed finger sizes don't really make sense to me. If buttons on the iPad
mini are too small, so are the buttons on every iPhone app made since 2007.

~~~
kamkha
Some sites have device-specific designs, and so they present different designs
for the iPad 2 and iPhone. Your comment would be applicable if the iPad Mini
were indistinguishable from the _iPhone_ and were served designs meant for the
iPhone as they have roughly the same pixel density, but as it stands it is
indistinguishable from the iPad 2 and thus it would be served a design not
meant for its pixel density.

~~~
JoelSutherland
You're missing the point entirely.

If you're concerned about the size of touch targets on the iPad mini, they are
already the EXACT same size as the touch targets on an iPhone since the two
share the same pixel density and recommended touch target size (40px).

~~~
kamkha
Re-read my comment. If someone has an iPad 2 specific design which uses
buttons which are 40 points wide on an iPad 2, those buttons will be _less
than_ 40 points wide when that design is inevitably served to an iPad Mini
user.

If iPad Minis are served iPhone-specific designs, then you're right—it doesn't
matter. And perhaps the solution is "you shouldn't be making iPad 2/iPhone-
specific designs," but that's not what I'm getting at.

~~~
JoelSutherland
It will be less than 40 points wide, but the physical size of that button is
still big enough. It is the exact same size as buttons on the iPhone.

You're saying that buttons on the iPad mini must be physically larger than
buttons on the iPhone? For what reason?

~~~
kamkha
It is the exact same size as buttons on the iPhone _if_ you are rendering the
iPad 2 design on the iPhone as well, but in that case the button on the iPhone
would be less than 40 points wide and also too small by Apple's guidelines. I
am saying that it would be against Apple's guidelines on _both_ the iPhone and
the iPad 2.

That's why I mentioned an iPhone-specific design, as well. The iPhone's pixel
density isn't a problem because it can be distinguished from the iPad 2. And,
as you've shown, if the iPhone-specific design is displayed on the iPad Mini
then there is no problem at all. The issue is that there is no way to
distinguish between the iPad 2 and the iPad Mini.

------
GotAnyMegadeth
Device fragmentation is a massive problem for Apple developers.

~~~
supercoder
I'm going to take that as sarcasm...

~~~
brador
It's actually becoming more of a problem. The longer screen of the new iphone
for example.

~~~
smackfu
Also, the fact that you need to keep devices around just to test older OS
versions. iOS has good upgrade stats but a lot of people are not upgrading to
iOS 6 yet, and Apple is also marooning some well used devices like the iPad 1.

~~~
huxley
Just to put some numbers to the upgrade stats you mentioned, Chitika reported
61% of iOS users were on iOS6 in late October about one month after its
release.

9% were on iOS 4

4% on iOS 5

25% on iOS 5.1

[http://bgr.com/2012/10/22/ios-6-adoption-rate-60-percent-
iph...](http://bgr.com/2012/10/22/ios-6-adoption-rate-60-percent-iphone-ipad/)

~~~
smackfu
The main issue is how fast those 5.1 people are moving on. Some of them are on
iPad 1, so they will never upgrade. Other people are just indifferent to iOS
upgrades, or don't have enough free space, or just plain don't want the
upgrade due to the Maps and YouTube changes.

Honestly, the main driver of the iOS 6 adoption at this point just seems to be
selling new devices that come with it.

------
blauwbilgorgel
Perhaps the following solutions are possible:

\- Hardware fingerprinting with the canvas-tag (
<http://cseweb.ucsd.edu/~hovav/dist/canvas.pdf> )

\- Somehow check which assets are preferred downloads:

    
    
      rel="apple-touch-icon" sizes="144x144"  
      rel="apple-touch-icon" sizes="114x114"  
      rel="apple-touch-icon" sizes="72x72"

------
nsxwolf
Please don't. The iPad mini is an iPad. It should run everything exactly the
same way. Please don't fracture the experience. The whole point of the mini is
that the screen size is large enough that it doesn't need to be a compromise.

~~~
dpcan
Yes, please do.

If someone is playing a game on an iPad, the buttons for controlling the
character should not be huge on the screen. They need to be shrunk down and
moved off to the corners so the thumbs can easily reach and touch them.

~~~
ricardobeat
The recommended minimum target size for iPad (44px) is fine on an iPad mini.
You don't need to change it unless it's already too small on the iPad.

------
andybak
Or just design your touch targets to be acceptable on both.

Visual size is much less of a concern as people will simple tend to hold a 7"
tablet closer than a 10" tablet.

~~~
pfisch
Honestly, that sucks and is really unacceptable. We are talking about
significantly changing the size of buttons/text between these two tablets. You
should be able to design for both.

~~~
Tyrannosaurs
I don't think we are. Every iPad mini review I've seen so far says existing
applications work fine and touch targets aren't an issue.

Font size is the only thing I've seen mentioned and there's a large element of
that which is user preference (hence the adjustable fonts in iBooks, Kindle,
Instapaper etc.).

The answer would seem to be sensible sized touch targets that work on both and
adjustable font sizes which are actually beneficial to everyone regardless of
what device they're using.

~~~
objclxt
Exactly - Apple have always been completely crystal clear that your touch
targets should be a minimum of 40x40pts. Your graphics themselves might be
smaller, but the touchable area should be at least 40x40.

Text size, certainly, but touchable targets shouldn't be a problem _assuming_
you're following Apple's guidelines. I appreciate that may not always be the
case, but then you only have yourself to blame.

~~~
smackfu
This question is about doing it in HTML5 though, so it's not like the iOS app
guidelines are particularly followed.

------
alextingle
Breaking the "cm" units in CSS is inexcusable.

~~~
jrmg
It's actually required by the CSS spec[1]: _1px is equal to 1/96th of 1in, 1pt
is equal to 1/72nd of 1in_

So, given that hard requirement, you have three options:

\- make your hardware have 96 dpi (or a multiple thereof).

\- have 1 'px' equal to 1 screen pixel (or point) but 'cm', 'in' etc. not
equal to real-world centimetres, inches etc.

\- have 'cm', 'in' etc. identical to real-world centimetres, inches etc., but
'px' without a direct relation to a screen pixel (or point).

Apple (and everyone else except perhaps printers) chose the second of those
options.

[1]<http://www.w3.org/TR/css3-values/#absolute-lengths>

~~~
taejo
In CSS, px does _not_ have a direct relation to screen pixel. From your
reference:

> The reference pixel is the visual angle of one pixel on a device with a
> pixel density of 96dpi and a distance from the reader of an arm's length.
> For a nominal arm's length of 28 inches, the visual angle is therefore about
> 0.0213 degrees. For reading at arm's length, 1px thus corresponds to about
> 0.26 mm (1/96 inch).

~~~
jrmg
True, but, also from there:

 _For lower-resolution devices, and devices with unusual viewing distances, it
is recommended instead that the anchor unit be the pixel unit. For such
devices it is recommended that the pixel unit refer to the whole number of
device pixels that best approximates the reference pixel._

------
saurik
This question is making me really wonder how anything useful ever gets done on
StackOverflow: every time I look back at it, there is some new answer with 50+
upvotes that is just as wrong as every other answer. Are people seriously
upvoting things because they "sound right"? There also tend to be a bunch of
comments from people with rampant speculation as to why various behaviors
occur, without having even taken the time to just test whether the things they
are talking about actually happen on real devices, or continue to happen if
you mess with the device some between tests (such as rotating it).

~~~
smackfu
Obviously stuff that gets linked externally all over the place has different
kind of answers and voting than your average SO question. Seems silly to judge
the whole site on it.

~~~
ygra
The average question is probably either one of the following anyway:

• How can I parse a bit of information from a HTML page? [regex] [php]

• Why does the compiler complain here? [c#]

• Regex question [regex]

• How to add two numbers in jQuery? [jquery] [html]

• What does this operator do? [java]

The long tail of not-very-highly voted questions is mostly beginner questions
about a particular language or environment. As for me, it gets tiring
explaining exactly the same thing in slight variations (adapted to the
problem) three times a day.

~~~
smackfu
And actual hard questions that can't be answered by Googling just sit there
with no answers. And then I win the Tumbleweed badge:
<http://stackoverflow.com/badges/63/tumbleweed>

That kind of thing is the problem with SO, not the ones with 5k views and
hundreds of votes.

~~~
dpark
Most questions on SO fit into one of three buckets:

1\. Trivial aka Dozens of answers aka Fastest gun in the west

2\. Hard aka Unanswered

3\. Interesting aka Closed

------
kamkha
One user posted a link to this blog post which describes a seemingly quick and
easy Javascript detection method: [http://konstruktors.com/blog/web-
design/4396-detect-ipad-min...](http://konstruktors.com/blog/web-
design/4396-detect-ipad-mini-javascript/)

I can't confirm it for myself, but if what the blog post says is true, isn't
this an easy method for detection? Though, I can't imagine that all of the
people who have deemed it impossible glossed over this.

------
zeteo
> we may want to scale certain images or buttons

Start with iPad2 mode. Add some invisible areas around those images and
buttons. If the user keeps touching these areas instead of actual UI, switch
to iPad Mini mode. This is also good for iPad2 users who have big and/or
clumsy fingers.

~~~
Tyrannosaurs
If you have that space available why not just make it part of the touch target
in the first place?

~~~
zeteo
You could do that and keep track of touches that are not very close to the
target's center instead. But it seems a bit more complicated to implement.

------
ck2
[http://konstruktors.com/blog/web-design/4396-detect-ipad-
min...](http://konstruktors.com/blog/web-design/4396-detect-ipad-mini-
javascript/#comment-24726)

iPad Mini: screen.availWidth = 768 screen.availHeight = 1004

iPad 2: screen.availWidth = 748 screen.availHeight = 1024

------
jhull
I think the approach of asking a user if they are using an iPad Mini or an
iPad 2 is a good one. Apple values the UX so much that anything which degrades
it will be noticed and updated.

------
gadders
Get Raymond Chen to patch iOs.

------
mrtnkl
I updated the question and gave a bit more reasoning to why it's ridiculous
that we aren't able to properly tell the difference between an iPad Mini and
an iPad 2.

Short version: It's not just about size. It's about weight and form factor.
The iPad mini can and will be used differently, like being held with one hand.
Designers/ developers such as myself should be able to provide users with a
different default controlscheme for the Mini that could make advantage of this
situation (such as using tap to walk instead of a virtual thumbstick - but
that's just an arbitrary example).

------
Hupo
Is there a difference in the default font size of iPad 2 and iPad Mini? Seeing
as the latter has a higher pixel density, it would make sense to me (but you
never know).

Anyway, if that is indeed the case, you could use CSS media queries built with
ems instead of pixels. I think it makes much more sense than the regular
pixel-based approach as our mobile devices get increasingly higher resolutions
and pixel densities.

------
dmethvin
window.screen.availHeight and window.screen.availWidth look like the best bet.

------
BenSS
Is everyone forgetting that you can easily zoom on any iOS device?

~~~
randomdata
Most sites that are device specific disable zooming.

~~~
BenSS
Which drives me crazy. If I want to zoom, let me. I don't care of the designer
wants a pixel perfect layout, that's not the web.

------
wildmXranat
Some way down in the answers is the proposition to simply ask the user. As
spartan and elegantly simple it is, I'm not sure the user will always be
accurate, what then ?

------
xvillain
All comments focus on the 'rendering' issue, what about log/traffic analyses ?
The root of the problem is Apple not following standards and pushing 'native
apps'.

------
irishcoffee
If a dev can ensure that the app works correctly (in terms of size
proportions) on the Mini, would it not also ensure it works on the non-Mini?

------
robomartin
Measure finger size:

<http://stackoverflow.com/a/13381781/576311>

------
taligent
The iPad 2 is ever so slightly faster:
<http://www.youtube.com/watch?v=YpV8AoToeHs>

Would a JS micro-benchmark work e.g. some integer calculation ? Of course
performance may change depending on the other apps the user has open but maybe
it doesn't.

