How does viewport detection differentiate tablet from phone?

Question

Everywhere I look, people keep saying stay away from UA-sniffing, even JQuery dropped that feature...

So how in the world does viewport-detection fill this gap of tablet vs phone (since newer models overlap in resolution)?

Can anyone explain how viewport detection is THE WAY to go on this...

The difference there is in viewport size, not feature detection. — Blazemonger, Jan 29 '14 at 00:55
but thats exactly the problem, viewport sizes are increasingly overlapping eachother, with newer phone models — user3160134, Jan 29 '14 at 01:08

Norguard · Accepted Answer · 2014-01-29T03:12:27.153

According to your comments, what you really want to be doing is setting

<meta name="viewport"
      content="width=device-width,
               initial-scale=1.0,
               minimum-scale=1.0">

In your <head>, which will force the pages to render at the device's width (or individual browser's width on that device, if you have, say Opera+Chrome+Android+etc installed on an Android, which will all likely be the same viewport, anyway).

For most 10" tablets, the viewport is the resolution of the device.
For most phones, the viewport-width (in portrait) is 320px - 360px.

So even though the Galaxy S4 and Note 3 might be 1920x1080, they're really 640x360 when the viewport is enabled (where each CSS pixel has 9 [3x3] screen-pixels worth of "sub-pixel" anti-aliasing applied, and where fonts/images are rendered at the full-resolution of the screen-pixels [a 200x100 image in CSS width/height could actually be a 600x300 image]). Instead of 3:1, "retina" iDevices have a 2:1 viewport DPPX (dot-per-pixel).
Other Androids/BBs/browsers have wonky, potentially-fractional DPPXs (so depending on Int-based DPPXs in equality tests should be avoided, too).

Then, you can test in JS, by using document.body.getBoundingClientRect().width, assuming that your body and layout are set appropriately in CSS.

If you aren't already doing this, then you probably have more to worry about in your responsive-design than whether an ad seems too big or too small.

In terms of UA-sniffing, it is occasionally valid.
That is, it's valid when you sniff the UA from your server-side language, against a DB of all-known UAs for phones/tablets, and then pre-compose an HTML page with baked-in CSS/JS, and pre-optimize images for that exact model...

However, that's not sniffing for specific sections of a UA string, that's searching every UA string for an exact match, and building to the specs of that device.

The reasoning is simple here:
How do you differentiate, in a UA, between all Android phones, all Android tablets and all other "miscellaneous" devices which run on the Android platform, when there is no standard way of defining every facet of the device+browser?

You might know the difference between an iPhone and an iPad, but how do you know the difference between Chrome on a generic 6" Taiwanese cell-phone and a generic 7" Taiwanese tablet?

The one instance of UA-sniffing that I can think of being valid is the .toDataURL() method of canvas in Android 2.2, which was technically added (you can detect it), but was never implemented (it just returns blank data, because the function was never actually written).

EDIT

SASS example, assuming Meta-Viewport is set properly

// my-widget.scss

// assuming a 1920x1080 phone (Samsung S4, Note 3 / Google Nexus 5 / HTC One)
// assuming 1920x1080 is max tablet size (with portrait width 1080)
// assuming that larger than 1080 is desktop
.my-widget {
    // default experience
    background-color : grey;
    color     : black;
    font-size : 1rem;

    // 1080px phone
    @media screen and (max-width : 360px) {
        font-size : 2rem;
        background-color : white;
        color : black;
    }

    // tablets up to 1080px, or phones in landscape-mode
    // (or really-really big phones... none in North America, that I know of)
    @media screen and (min-width : 361px) and (max-width : 1080px) {
        background-color : black;
        color : white;
    }
}

Don't want to allow phones in landscape to move to a different layout, then increase it to 640px, or add an orientation-check to the @media rule.

Realistically, you shouldn't be targeting device-constraints. What you should be doing is targeting content-restraints.

Where does it make sense for your widgets to flow out into three or four columns, and where does it make sense (at what pixel/em-widths) to make everything break down into single-column mode, because your experience breaks otherwise.

But the point is that with the viewport set, you can now serve the super-small experience to the Samsung Galaxy Gear, the Nintendo 3DS, etc... a small experience to phones, a medium experience to iPads and 7"/8" tablets, a larger-medium experience to full-sized tablets, a desktop/TV experience, and a stupid-huge experience to people with multiple-monitors, or the Nexus 10, or 4k TVs, et cetera.

And it all comes at no extra sniffing...
Just a little planning, and some media queries.
You can add as many or as few breakpoints as you like.

Heck, knowing that the iPhone is 320px, you could serve an experience specifically to things sized exactly like iPhones, and then serve generic mobile from 321 up to 480 (or 640), or just make one responsive-grid flow all the way from 320px to 768px (iPad width), and have that be your "small", and serve everything larger as desktop...

Sky is the limit.
You just need to know what breakpoints you care about.

Good answer, I was aware of the problems of spoofing and unknown devices, but Im not worried about spoofers & unknown models... every website designer has its limits in maintaining his site... — user3160134, Jan 29 '14 at 01:27
@user3160134 of course there are limits. In my personal-projects, it's just me. At work, there may be more people, but also way more projects. But starting a website by specifying your viewport is a cornerstone requirement at this point, if you plan on serving a single HTML page which responds/adapts to desktop+tablet+"phablet"+phone+micro-devices. You're totally moving your maintenance into the realm of CSS, but if you have the benefit of using something like AngularJS (or can otherwise write tiny, focused template-partials), and have a decent build-process + SASS/LESS, it gets easier. — Norguard, Jan 29 '14 at 01:35
@user3160134 it also comes with the benefit of being a super-generic solution. Generic UA-sniffing leads to huge swaths of "oops" in the Android field, where tablets get mobile treatments -- these aren't just off-name experiences, either (though I hope they're getting better). Alternatively, viewport-specific layouts will bind a device to the competency of the device(+browser) vendor. If the vendor thinks that device should have a 2.057:1 DPPX, then that's what your CSS will provide, with no extra work from you. — Norguard, Jan 29 '14 at 01:43
I see, can you show me a code snippet how you would differentiate between tablet & phone (in SASS)? I would greatly appreciate it, thank you — user3160134, Jan 29 '14 at 02:35
@user3160134 It's not that hard. If you have a 1920x1080 10" tablet and a 1920x1080 Samsung Note 3 ***AND YOU HAVE SET THE META-VIEWPORT TAG***, then `@media screen and (max-width : 360px) { /*phone*/ }` and `@media screen and (min-width : 1080px) { /* tablet or desktop -- set a max-width too, to serve a desktop-specific version above this */ }` will work just fine. `.my-widget { @media ...360px { color : blue; } @media ...1080px { color : red; } }` You're done. — Norguard, Jan 29 '14 at 02:49

How does viewport detection differentiate tablet from phone?

1 Answers1

SASS example, assuming Meta-Viewport is set properly