Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)
On 6 February 2012 19:24, Irakli Nadareishvili ira...@gmail.com wrote: Boris, if you don't mind me saying it, I am afraid you may be missing the point of this request. In Responsive Web Design, device capabilities are used in a high-level fashion to determine a class of the device: smartphone, tablet, desktop. I'm afraid you have missed the point, not Boris. We do not care about device classes at all, those are a temporary and limited idea. We care about device capability. Right now we have to use screen-size as a clunky proxy for processor speed, gpu acceleration capabilties, bandwidth, latency, etc. The device class idea is no better than this already demonstrably ridiculous and inaccurate assumption that screen size correlates conclusivly with any of those values. There is *nothing* that states that a small screen means a mobile device. Or that a large screen means a desktop device. A phone today is much more powerful than a 8yr old desktop. A tiny screen device can be attached to a fast WIFI and a 27 iMac could be out in the sticks on a rubbish ISDN connection. This situation does not chance when a device reports some marketing-made-up class name. What's to stop a mobile class device having a quad core CPU and 100Mbps WIFI and a retina screen some 900px wide? What's to stop a desktop class device being hooked up to a 800x600 projector in farm country with poor connectivity? If you based your supplied assets on device class then you'd be doing both those users the wrong way around. Device class tells us *nothing* for certain. We are not interested in some temporary and imagined classing system; what we want are the device capabilities. Not assumptions of them based on other aspects (like screen size or this class idea). Such ideas do not hold up.
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)
On Mon, Feb 6, 2012 at 9:24 PM, Irakli Nadareishvili ira...@gmail.com wrote:
if you don't mind me saying it, I am afraid you may be missing the point of
this request. In Responsive Web Design, device capabilities are used in a
high-level fashion to determine a class of the device: smartphone, tablet,
desktop.
Firefox (at least from version 12 up), Opera Mobile and Safari already
expose this information.
Firefox for tablets includes the substring Tablet in the UA string
and Firefox for phones includes the substring Mobile in the UA
string. If neither Tablet nor Mobile is present in the UA string,
the browser is running on a desktop.
In the case of Opera (excluding Mini), the indicators are Tablet and
Mobi (and desktop otherwise).
In the case of Safari, if the substring iPad is present, it's a
tablet. Otherwise, if the substring Mobile is present, it's a phone
form factor. Otherwise, its desktop (or a non-Safari browser spoofing
as Safari).
IE differentiates between desktop on the phone form factor as well:
the mobile form factor in closest substring IEMobile.
Unfortunately, the Android stock browser on Android tablets does not
include a clear tablet indicator.
So you get something like
/**
* Returns desktop, tablet or phone
* Some 7 tablets get reported as phones. Android netbook likely get
reported as tablets.
* Touch input not guaranteed on phones (Opera Mobile on keypad
Symbian, for example) and tablets (non-Fire Kindle)!
*/
function formFactor() {
var ua = navigator.userAgent;
if (ua.indexOf(Tablet) -1) {
// Opera Mobile on tablets, Firefox on tablets, Playbook stock browser
return tablet;
}
if (ua.indexOf(iPad) -1) {
// Safari on tablets
return tablet;
}
if (ua.indexOf(Mobi) -1) {
// Opera Mobile on phones, Firefox on phones, Safari on phones
(and same-sized iPod Touch), IE on phones, Android stock on phones,
Chrome on phones, N9 stock, Dolfin on Bada
return phone;
}
if (ua.indexOf(Opera Mini) -1) {
// Opera Mini (could be on a tablet, though); let's hope Opera
puts Tablet in the Mini UA on tablets
return phone;
}
if (ua.indexOf(Symbian) -1) {
// S60 browser (predates Mobile Safari and does not say Mobile)
return phone;
}
if (ua.indexOf(Android) -1 ua.indexOf(Safari) -1) {
// Android stock on tablet or Chrome on Android tablet
return tablet;
}
if (ua.indexOf(Kindle) -1) {
// Various Kindles; not all touch!
return tablet;
}
if (ua.indexOf(Silk-Accelerated) -1) {
// Kindle Fire in Silk mode
return tablet;
}
return desktop;
}
Seems like the coarse form factor data is pretty much already in the
UA strings. Things could be improved by Opera Mini, Safari, Amazon's
browsers and Google's browsers saying Tablet when on tablet. Symbian
is dead, so no hope for its stock browser starting to say Mobi.
The inferences you may want to make from the form factor data may well be wrong.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)
Boris, if you don't mind me saying it, I am afraid you may be missing the point of this request. In Responsive Web Design, device capabilities are used in a high-level fashion to determine a class of the device: smartphone, tablet, desktop. There is no need for exact viewport state. All the image, css and javascript optimizations that need to happen on server-side can happen based on that information. Everything else (including things related to turning orientation or changing window size) are already covered by media queries in CSS3. This is so much so that, in our discussion on the Firefox forum, it was suggested that maybe browsers just report device class: https://support.mozilla.org/en-US/questions/917322 This could be a great solution for all purposes, with one caveat: logic for which devices should belong to which category may change and whether browser vendors can adapt quicker or it's better if they provide raw data and let server developers adapt their server-side code, is debatable. Hope this clarifies the intent of the request/proposal. Thank you, Irakli
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)
On 2/6/12 2:24 PM, Irakli Nadareishvili wrote: if you don't mind me saying it, I am afraid you may be missing the point of this request. I certainly hope I am! What I understood the request to be doesn't make any sense. In Responsive Web Design, device capabilities are used in a high-level fashion to determine a class of the device: smartphone, tablet, desktop. If that's the information you need to know (why, exactly?), why not just send _that_ information instead of various proxies like device screen size? Incidentally, what class is this device: http://eee.asus.com/en/eeepad/transformer/specification/ ? It has a 10 touchscreen, 1280x800 device resolution, and an optional keyboard. Is this a tablet or a desktop? Compare to the 11 version of http://www.apple.com/macbookair/specs.html (which has a pretty similarly sized non-touch, for now, screen and similar resolution; the aspect ratio is 16:9 for this device and 16:10 for the Asus device above). Presumably this device is uniformly classified as a desktop by everyone attempting such classifications? There is no need for exact viewport state. OK. Then what state do you need, exactly, and why? This is so much so that, in our discussion on the Firefox forum, it was suggested that maybe browsers just report device class: https://support.mozilla.org/en-US/questions/917322 This would be a lot more useful than trying to guess device class based on proxies like screen size. It would, in particular, allow the UA to claim that the Asus device above is a desktop if that leads to a better user experience. Or to claim that the Macbook Air is a tablet, especially when it grows a touchscreen. This could be a great solution for all purposes, with one caveat: logic for which devices should belong to which category may change and whether browser vendors can adapt quicker or it's better if they provide raw data and let server developers adapt their server-side code, is debatable. I may be biased, but I think the browser has a much better idea of device class than you can infer from a screen size. Hope this clarifies the intent of the request/proposal. Well, it clarifies that I understood it correctly -Boris
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)
Boris, fair enough. Two use-cases off of my head that do not currently have a non-ugly solution and could if browsers reported device class: 1. Adaptive images: To optimize user-experience on smart-phones (most of which have relatively small screens, and are on slow connections most of the time) we need to send lower-resolution or resized versions of high-resolution images that would be sent to desktop clients. The best way to do it is if markup referred to an image resource with single URL and server, depending on header information, sent different crop or resolution of the image to different classes of devices. The two underline assumptions here are: it's much easier to detect device type than quality of network connection. It's also more correct because small-screen devices do not need high-def images even if they can download them fast. 2. Adaptive CSS/Javascript. Most websites use CSS/JS aggregation. Different devices need special CSS/JS code. For instance, touch-screen devices need all kinds of libraries like jqueryMobile. Likewise, Desktop experience may need large javascript libraries that are not needed on smart-phones. If server could easily detect device type/capabilities it would have the ability to tailor aggregated js/css files to a class of a device, thus providing greatly improved experience. I am sure there are other use-cases that could benefit from improved device type/capability detection. After all, that's exactly why people have put enormous effort in projects like WURFL. Alas, WURFL is not accurate enough or easy enough to use. Hence the motivation for the proposal to ask browsers help with the effort. Thank you Irakli
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)
On 2/6/12 3:00 PM, Irakli Nadareishvili wrote: 1. Adaptive images: To optimize user-experience on smart-phones (most of which have relatively small screens, and are on slow connections most of the time) we need to send lower-resolution or resized versions of high-resolution images that would be sent to desktop clients. The best way to do it is if markup referred to an image resource with single URL and server, depending on header information, sent different crop or resolution of the image to different classes of devices. OK, so just to make sure I understand: 1) You want to use device class as a proxy for connection speed. 2) You want to use device class as a proxy for size the user will be able to see the image at. Users who zoom, or save your page to a PDF for later viewing or printing, screw them, right? The two underline assumptions here are: it's much easier to detect device type than quality of network connection. If you sufficiently restrict your definition of device type, perhaps. It's also more correct because small-screen devices do not need high-def images even if they can download them fast. Why not? Every single such device allows users to zoom. Many allow the user to send the image on to other media (external monitors, PDFs, etc) where they may well want high-def images. I think that you're assuming particular usage patterns for these devices which may even be true today but that we don't necessarily want to lock into the architecture of the web. Most websites use CSS/JS aggregation. Different devices need special CSS/JS code. For instance, touch-screen devices need all kinds of libraries like jqueryMobile. Likewise, Desktop experience may need large javascript libraries that are not needed on smart-phones. If server could easily detect device type/capabilities it would have the ability to tailor aggregated js/css files to a class of a device, thus providing greatly improved experience. I agree this is a use case worth addressing. Please tell me which device class your server would like to put http://www.lenovo.com/products/us/desktop/ideacentre/a-series/a700?cid=us|disp|badg|pcmag|display_dr|21620dfaid=1 and why (summary for those not wanting to read the specs: it's a desktop system with a 23 touchscreen running at 1920x1080, with the system itself built into the base of the screen; similar to modern iMacs, but with a touchscreen). Which JS libraries would you send or not send to this device based on its screen size and the fact that it's obviously a desktop? It seems to me, honestly, that given the current state of the market the main effect of guessing about device classes and sending them different content, as opposed to directly detecting the device capabilities you really care about one way or another, will just lead to you sending the wrong content to devices as the lines between device classes blur more and more. I do think there are classifications that are worth making between devices so as to adapt your content to them, but the primary one I care about (is this device running on a battery right now?) is not one I've even heard anyone mention... and has nothing to do with device class, except insofar as tablets and phones are almost always doing that while desktops (but not laptops) are almost never doing that. I am sure there are other use-cases that could benefit from improved device type/capability detection. After all, that's exactly why people have put enormous effort in projects like WURFL. Quite honestly, as far as I can tell a major reason people have put a lot of effort into things like WURFL because so many phones shipped with completely broken browsers for so long... So you needed a big database just to figure out how the browser was going to screw up your content This is clearly not a concern for new proposals, right? Again, I agree that exposing device capabilities would be useful. I think that if people are going to infer things like device class from screen size and things like level of support for touch interfaces from device class, then exposing the capabilities would actually be worse for users because sites would get things wrong so often. -Boris
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)
On Mon, 06 Feb 2012 20:00:45 -, Irakli Nadareishvili ira...@gmail.com wrote: 1. Adaptive images: To optimize user-experience on smart-phones (most of which have relatively small screens, and are on slow connections most of the time) Be careful with generalizations like that. Mobile devices can be connected to high-speed networks. Laptops can be tethered via mobile networks. There are many permutations of screen size, DPI, zoom, network speed, bandwidth cost and memory availability that influence decision what image resolution is best, and it's not as simple as mobile vs non-mobile. There aren't even clear device classes. Basic device characteristics like physical screen size and presence of a hardware keyboard can change dynamically! Smartphones can be connected to TVs and projectors. Tablets can be connected to keyboards. Laptops can be flipped into tablet mode. Desktops can have touchscreens — and these aren't obscure things. It's iPad with AirPlay and dock. It's most tablet PCs. You can expect many laptops to have touchscreens soon. Mobile or smartphone can mean anything from Opera Mini on GPRS connection to a quad-core 4G smartphones more powerful than desktops were few years ago. I appreciate optimisations you're trying to make, but simply reporting basic capabilities in an HTTP header isn't going to work well in other than few most common cases. I hope we could come up with a better solution that can all the optimisations and improved experience you want to achieve, but doesn't have pitfalls of assuming that slow networks and touch screens go hand-in-hand, or that devices with keyboards also have mouse and 100dpi screen, etc. 2. Adaptive CSS/Javascript. CSS has media queries already. New queries can (and I think should) be added to query more capabilities like presence of a touch screen (Mozilla experiments with -moz-touch-enabled media query already). Media queries are dynamic and can be observed by JavaScript, so when you switch from tablet's own touch screen to an external display, pages could theoretically switch UI too. If server could easily detect device type/capabilities it would have the ability to tailor aggregated js/css files to a class of a device, thus providing greatly improved experience. Sure, but it doesn't mean that the server has to do that and that it's the only way to do that. For example: script src=touch-ui.js media=input-type: touch script src=mouse-ui.js media=input-type: mouse (although I'm not suggesting using that form literally, as it has some drawbacks of its own) Next version of JavaScript is going to have modules, which makes loading of JavaScript cleaner than script. Perhaps modules could be loaded conditionally based on media-query-like declarations? -- regards, Kornel Lesiński
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)
On Mon, 2012-02-06 at 22:16 +, Kornel Lesiński wrote: On Mon, 06 Feb 2012 20:00:45 -, Irakli Nadareishvili ira...@gmail.com wrote: 1. Adaptive images: To optimize user-experience on smart-phones (most of which have relatively small screens, and are on slow connections most of the time) Be careful with generalizations like that. Mobile devices can be connected to high-speed networks. Laptops can be tethered via mobile networks. There are many permutations of screen size, DPI, zoom, network speed, bandwidth cost and memory availability that influence decision what image resolution is best, and it's not as simple as mobile vs non-mobile. There aren't even clear device classes. Basic device characteristics like physical screen size and presence of a hardware keyboard can change dynamically! Smartphones can be connected to TVs and projectors. Tablets can be connected to keyboards. Laptops can be flipped into tablet mode. Desktops can have touchscreens — and these aren't obscure things. It's iPad with AirPlay and dock. It's most tablet PCs. You can expect many laptops to have touchscreens soon. Mobile or smartphone can mean anything from Opera Mini on GPRS connection to a quad-core 4G smartphones more powerful than desktops were few years ago. I appreciate optimisations you're trying to make, but simply reporting basic capabilities in an HTTP header isn't going to work well in other than few most common cases. I hope we could come up with a better solution that can all the optimisations and improved experience you want to achieve, but doesn't have pitfalls of assuming that slow networks and touch screens go hand-in-hand, or that devices with keyboards also have mouse and 100dpi screen, etc. 2. Adaptive CSS/Javascript. CSS has media queries already. New queries can (and I think should) be added to query more capabilities like presence of a touch screen (Mozilla experiments with -moz-touch-enabled media query already). Media queries are dynamic and can be observed by JavaScript, so when you switch from tablet's own touch screen to an external display, pages could theoretically switch UI too. If server could easily detect device type/capabilities it would have the ability to tailor aggregated js/css files to a class of a device, thus providing greatly improved experience. Sure, but it doesn't mean that the server has to do that and that it's the only way to do that. For example: script src=touch-ui.js media=input-type: touch script src=mouse-ui.js media=input-type: mouse (although I'm not suggesting using that form literally, as it has some drawbacks of its own) Next version of JavaScript is going to have modules, which makes loading of JavaScript cleaner than script. Perhaps modules could be loaded conditionally based on media-query-like declarations? I can't remember where right now, but I do recall seeing an article which said that it was a common misconception that mobile devices were most often on a slow connection. Personally, I tend to make most use of my mobile for browsing when I'm on a wireless connection. Just because someone is using a mobile device, it doesn't naturally mean they are on the move. -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)
On 2/6/12 5:21 PM, Ashley Sheridan wrote: I can't remember where right now, but I do recall seeing an article which said that it was a common misconception that mobile devices were most often on a slow connection. Personally, I tend to make most use of my mobile for browsing when I'm on a wireless connection. Just because someone is using a mobile device, it doesn't naturally mean they are on the move. And even if you are on the move, EVDO rev B is in the 5-15 Mbit/s range, and HSPA+ services that deliver 28 Mbit/s are on the market right now, with theoretical peak bandwidth for the standard closer to either 84 Mbit/s or 168Mbit/s depending on the hardware configuration. A real problem with network performance on many cell networks is not the bandwidth, which is at least comparable to basic DSL, but latency. Of course for latency issues image size is a smaller problem, and desktops on sattelite connections have latency issues of their own -Boris
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header (Boris Zbarsky)
2012/2/6 Kornel Lesiński kor...@geekhood.net On Mon, 06 Feb 2012 20:00:45 -, Irakli Nadareishvili ira...@gmail.com wrote: 1. Adaptive images: To optimize user-experience on smart-phones (most of which have relatively small screens, and are on slow connections most of the time) Be careful with generalizations like that. Mobile devices can be connected to high-speed networks. Laptops can be tethered via mobile networks. Right. When I had a smart phone, it was on WiFi 90%+ of the time because I'm either at work or at home although I browsed on the phone when I was on move disproportionally more than I was at work or home. I appreciate optimisations you're trying to make, but simply reporting basic capabilities in an HTTP header isn't going to work well in other than few most common cases. I hope we could come up with a better solution that can all the optimisations and improved experience you want to achieve, but doesn't have pitfalls of assuming that slow networks and touch screens go hand-in-hand, or that devices with keyboards also have mouse and 100dpi screen, etc. I'm totally with you. While I do sympathize with the view that we need some ways to let servers figure out which resource to be sent and how it should be sent, I don't think web developers should be making such decisions solely based on the types of devices they're serving. On Mon, Feb 6, 2012 at 2:30 PM, Boris Zbarsky bzbar...@mit.edu wrote: And even if you are on the move, EVDO rev B is in the 5-15 Mbit/s range, and HSPA+ services that deliver 28 Mbit/s are on the market right now, with theoretical peak bandwidth for the standard closer to either 84 Mbit/s or 168Mbit/s depending on the hardware configuration. A real problem with network performance on many cell networks is not the bandwidth, which is at least comparable to basic DSL, but latency. Of course for latency issues image size is a smaller problem, and desktops on sattelite connections have latency issues of their own On the other hand, mobile networks tend to have a huge variance on the packet loss rate (sometimes 100% if the user is moving into an elevator) and websites need to behave differently, e.g. cache more images on Map app. On that note, it might be more useful to add a header indicating that they're on slow network, mobile network, and such although it might be better for servers to auto-detect latency and bandwidth for that kind of use cases. - Ryosuke
