Mobile detection

[David Greenspan]

Hey web devs,

What are your thoughts on mobile detection?  In particular, say you are making a photo gallery and you want to have a different experience on mobile vs desktop.  How do you know you're on mobile?  Do you use presence of touch event support, screen size, or some combination of this and other factors?  What are the edge cases?

I'm not talking about redirecting to another site (mobile.mysite.com) -- that's silly -- just using different (potentially very different) CSS and JS.  I realize that for many sites/apps, activating some CSS based on the window size may be enough (that's media queries, right?), but it seems like that would break down for richer apps.

What do you do in your apps?

Thanks,

David

[Silly Clown]

https://github.com/Snugug/north#device-detection

[Arunoda Susiripala]

I simply use media queries to apply some different CSS and hide and show some content. 

Sometimes, bootstrap also helps. 

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Arunoda Susiripala

@arunoda

https://github.com/arunoda

http://www.linkedin.com/in/arunoda

[emgee3]

Bootstrap and other responsive design frameworks handle the majority of these considerations for me at present but I do have one site that if on mobile uses different javascript libraries that I don't necessarily want to send down to every client. What I do is feature detection and dynamically load the additional libraries needed at the stage when they are needed. 

Mobile detection when combined with different javascript and css payloads (https://trello.com/c/24s6vyxo/55-incremental-loading ) would be a welcome addition.

That said, I rarely need this sort of functionality. 

[Pascal Richier]

Same as Arunoda.

[Abigail Watson]

Hi David,

AgentString detection is a fairly standard approach, but has the problems of browser spoofing.  I've had fairly good success with mystor's device-detection package from Atmosphere.  But it has all the problems that Silly Clown mentions.

Detecting touch-event support seems like it's a better approach, but remember that there are touch-screen desktop and wall monitors, ala Perceptive Pixel and the first generation versions of Microsoft Surface.  (We've all seen those huge multitouch monitors on news channels.)  So, that's where touch support falls apart. You can't assume that supporting multitouch means they're using a tablet or phone.  They could be sitting at a multitouch wall. And, increasingly, we'll be seeing multitouch interfaces making their way into kitchens, homes, bus-stops, cars, etc..  So the only thing that touch support tells you is that you need to render with UI designed for touch interfaces... meaning big buttons UI elements.  That, in turn, means assigning CSS classes. 

Responsive design and properly structured @media queries are generally the best way for detecting screen size and resolution, in my experience. That's where Bootstrap comes in.  But it should be remembered that there ways of spoofing/changing screensizes as well. 

That being said, I'm a really big fan of @media queries, and find that they absolutely *don't* break down for richer app. They hold up very well, especially if you're using LESS or SCSS.  Some people have heard me going on about HTML/CSS/JS as an MVC paradigm interpretation (or maybe an MPC paradigm?  ie. Model, Presentation, Controller).  And @media queries are a big part of that. The following works quite well for displaying mobile versions of a Meteor apps on mobile devices.  

// default desktop view

#signInPage{

     border: 1px solid gray;

}

// landscape orientation view for tablets

@media only screen and (min-width: 768px) {

  #signInPage{

     padding: 20px;

  }

}

// portrait orientation view for tablets

@media only screen and (max-width: 768px) {

  #signInPage{

     padding: 0px;

       border: 0px;
  }

}

// phone view

@media only screen and (max-width: 480px) {

  #signInPage{

                   .footer{

                       display: none;

    }

  }

}

All of my apps running on mobile devices have used a version of the above, and it works quite well.  And it's a very clean interface for adding printable versions of the website, audio versions, ultra-high resolution versions,  etc. Any time you want to take your site and present it on a different media interface (i.e. a different Presentation/View), the @media statements are your go-to code format.  All sorts of magic can be done with @media statements and LESS.

Also, just as an FYI, CSS3 currently supports the following media_types:

media_type: all | aural | braille | handheld | print |
  projection | screen | tty | tv | embossed
media_feature: width | min-width | max-width
  | height | min-height | max-height
  | device-width | min-device-width | max-device-width
  | device-height | min-device-height | max-device-height
  | aspect-ratio | min-aspect-ratio | max-aspect-ratio
  | device-aspect-ratio | min-device-aspect-ratio | max-device-aspect-ratio
  | color | min-color | max-color
  | color-index | min-color-index | max-color-index
  | monochrome | min-monochrome | max-monochrome
  | resolution | min-resolution | max-resolution
  | scan | grid

And the CSS4 specs include a 'pointer' type, for touchscreens, kinects, wii, styluses, touchpads, mice, etc.  So, for future browsers to be CSS4 compliant, they'll need to expose hardware input information via CSS (which is in keeping with traditional ideas about what MVC is, ala Xerox Parc, etc).  

The other approach to detecting screen size is to do it in Javascript with a $(window).width() and $(window).height() detection.  (Basically doing it in the Controller, rather than the View). That's much more liable to introduce performance issues if done incorrectly.  I've found that the following pattern is the best way to handle orientationchange events, resize events, and so forth, and can be a great way to kick off screen-size specific controls.  And I wind up adding it to nearly every project.  So, if you're looking for some mobile functionality to bake into Meteor, detecting resize events would be a great start for a Mobile API.   

Session.set("resize", null); 

Meteor.startup(function () {

    $(window).resize(function(evt) {

                  Session.set("resize", new Date());

    });

});

Template.homePage.resized = function(){

  var width = $(window).width();

  var height = $(window).height();

  

            doSomethingCool(width, height);

 

  return Session.get('resize');

}; 

<template name="homePage">

  <div class="panel">

    random content... 

  <div> 

  <div class="hidden">{{ resize }}</div>

</template>

Of course, the best way to detect mobile is for the hardware to notify you directly.  Cordova PhoneGap exposes a 'deviceready' event, that you can add an event listener to.  So, the cordova-phonegap package does the following:

      document.addEventListener('deviceready', function(){
          Session.set('deviceready', true);
      }, false);

That's the sure-fire, bullet-proof method of knowing that you're on a mobile device.  So, exposing a deviceready event might be something else to look at if you all are considering a Mobile API or Device API of some sort.

Now then, Morten, Alan, and I have been discussing Chrome Apps as a target compilation point for mobile apps.  And Google recently announced that they're bringing Chrome Apps to Cordova (thanks Alan, for that heads up!).  So, if you're looking for some really interesting possibilities, check out these links:

 

Run Chrome Apps on Mobile Using Apache Cordova/Phonegap 

Google Brings Chrome Apps to Google Play and Apple App Stores

Chrome Apps on Mobile Toolchain

What Are Chrome Apps? 

Create Your First Chrome App

The next thing I've been planning to experiment with, by way of Meteor and mobile, is taking the /bundle/programs/client directory, after running the bundler, and adding a manifest.json, background.js, and window.html file.  In theory, that directory is an ideal compilation point for hooking the Meteor toolchain to the Chrome App/Cordova toolchain.  If that works, it might be worth modifying the Meteor bundler, and adding options for compiling mobile specific versions of Meteor apps.  I dare say that there are lots of folks who would love the following options:

mrt bundle -mobile output.tar.gz

mrt bundle -ios output.tar.gz

mrt bundle -android output.tar.gz

mrt bundle -all output.tar.gz

Or something like that.  Anyhow.  $0.02 of thoughts.  
Abigail

On Friday, January 31, 2014 1:23:00 PM UTC-5, David Greenspan wrote:

[Adrian Lanning]

We customize our user experience with:

• CSS - @media queries
  
• JS - user-agent detection
  

Our main user-agent detection script is from http://detectmobilebrowser.com/.  We use it to include special javascript for non-mobile devices which enables nicer-looking UI controls; for mobile, we just use the native controls.

We also use FastClick which avoids the 300 ms click delay.  It performs a few checks to determine whether to activate itself: window.ontouchstart, checking for Chrome Android, and msTouchAction.

[Silly Clown]

I've thought about this more this weekend;

/client/mobile

/client/desktop

package.on_use {

   smaller.jpg, {

   forMobile: true

   forDesktop: false

   }

}

bundling/delivery system might be worth thinking about.

Particularly if the community is big enough to have someone dedicated to keeping device detection up to par.

 
On Friday, January 31, 2014 1:23:00 PM UTC-5, David Greenspan wrote:

[Serkan Durusoy]

I think the greater problem here is having to bundle everything all together and send down to the client whether or not it is a mobile client with restricted capabilities, that would not require some/much of the bundled js/css anyway. 

But laying this down as a bundling problem would not be a good solution. Every app can have a different idea of what needs to be delivered to what kind of device.

Being able to deliver the right package at runtime would be a great but it may be codependent on much more than the device type alone.

Therefore, I think what we need is a lazy loading mechanism that can be triggered on the client and fulfilled by the server. The criteria to decide what the load would be left to the developer.

[Abigail Watson]

Silly Clown's suggestion is good if you truly have different content you want to display on each device.  However, it introduces doubling or tripling of code.  I'd be liable to use something like that to display a 'this site is built for desktop, please access on a larger device' or similar error messages.  That would be cool.  

Which brings to another point.... most of the device detection capabilities I've used in the past, have been tied to, at some point along the way, a screen or two saying 'this browser not supported' or 'this device not supported' or 'please access on a desktop' or 'please access on a mobile device'.  Which basically boils down to error handling, and what to do when the wrong device is detected, or a device isn't detected at all.

--
You received this message because you are subscribed to a topic in the Google Groups "meteor-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-talk/ku7kvNJp8ek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-talk...@googlegroups.com.

[Serkan Durusoy [DNA | encoding the future]]

I think the cases around wrong device type detection or not being
detected should be so minor, I believe they should be treated as any
other software bug. And the fact that the number of users accessing the
app with un/mis-detected devices would be so small, you may even be
inclined t mark that as a low prirority bug.

Regarding code duplication, I don't think it is too big an issue if the
app is well structured and abstracted enough into dry components.

In any day, I'd prefer taking on these challenges rather than sending
down megabytes of unnecessary js and overly complicated css to an
incapable mobile device with slow network connectivity.

[Abigail Watson]

We have different experiences coding for mobile. :)

I find wrong device-detection to be ubiquitous in my apps.  But then, I'm focusing on a market (healthcare), where it's okay to draw strong delineating lines, and say 'yeah, IE simply isn't supported... AT ALL.'  Or, 'sorry, no phones. End of story.'   There's no expectation of cross-browser compatibility that reaches 99.9% of all devices. It's perfectly fine to aim for 80% compatibility, and call it a day.  

So, for instance, I target WebKit browsers, Chrome and Safari, and anybody on Firefox or IE is simply out of luck.  They need a browser page that say's 'browser not supported'.  

Likewise, with device detection, if I have an app that has NFC and GPS enabled, I need to say hey...  your phone doesn't support that feature.  Don't access this application.  End of story. They get an error page (that's maybe prettied up as a landing page, marketing page, etc.).  

So, yeah... I use redirects and error pages extensively.  

And megabytes of js and css?  If done well, it can be done in less than a few kilobytes.  Totally worth baking in.  :)

--
You received this message because you are subscribed to a topic in the Google Groups "meteor-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-talk/ku7kvNJp8ek/unsubscribe.

To unsubscribe from this group and all its topics, send an email to meteor-talk+unsubscribe@googlegroups.com.

[Serkan Durusoy [DNA | encoding the future]]

I do have similar experiences where we targeted specific browsers, in
fact in one project we even had to pin down the browser version - IE7 :( -

There are many projects, though, the desktop demand is for a fuller and
richer experience that do actually want and appreciate the mb's of extra
js plugins, widgets, goodies, fonts etc but also ask for the plainest of
experiences for mobile.

In many of these cases we opted for separate clients maintained within
the same project structure, reusing many (non-visual) components. And in
some cases, the css/js of the visual components were generated
dynamically and cached (JSF resource management goodies).

This is where I'm coming exacly from. Being able utilize the same
toolchain on both the server and the client, I sure would like to test
for some criteria (on the server and/or the client) and be able to say,
hey, here's what you're gonna need to render that view/app.

So I'm not actually tying this down to device detection alone.

For example, we may have a site where we display our products, targeting
the whole world, but also have ecommerce functionality built in,
targeting just some geographies, while also presenting an additional
rocket-science product configurator on desktop.

So to sum up my point, I think we need a mechanizm where we can lazily
and selectively load resources to the client.

[Abigail Watson]

If your mobile and desktop versions are that different, why not simply run different sites and selectively load resources based on DNS and URL?  

[Serkan Durusoy [DNA | encoding the future]]

Because there may be times (in fact very often in our experience) the
amount of reused code is so much (even though the final experiences feel
so much different) that it becomes much saner to keep the code
structured within the same context/project for better maintenance,
refactorability, testability etc.

This becomes especially true during the early to mid stages of
development where anything and everything can suddenly slide away from
under you.

We also found out in many cases that the pre and post deployment, and
monitoring becomes easier in a unified app.

Of course as projects get bigger, this strategy may lose its validity.

But again, my point is, this should become a developer option, through a
built in mechanism, in contraire to today's situation where everything
is bundled together and sent in one go to any and all clients regardless
of any criteria.

[Ry Walker]

Hi Serkan —

I agree with you that this would be nice to have. Right now we serve the same JS to all clients, regardless of what features they have access to. Files would need to be tagged somehow to know which build they should be included in.

This sort of thing would fall quite low on Meteor Development Group's priority, so this would need to come from the community most likely.

It'd be interesting to see how you would structure your app code, assuming a package existed to make it work.

-Ry

--

You received this message because you are subscribed to the Google Groups "meteor-talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk+unsubscribe@googlegroups.com.

[Serkan Durusoy [DNA | encoding the future]]

Hi Ry,

I'm coming from a javaee world where we develop in large teams (I'm the
dreaded management guy, but I also like taking on problems no one else
bothers to solve) and I'm currently working on a new startup where I'm
the sole developer. I'm unlearning many of those java paradigms while
trying to maintain my experience intact. So I keep finding myself asking
questions such as "Am I doing this instinctively? Is there a better way
in the Meteor world for this?"

I'll have an early-alpha release in a few weeks and I see no reason not
to share the codebase with you. I'd also enjoy discussing what I would
have preferred in what condition if such a package were to exist. Please
feel free to contact me directly.

But first things first, I must clarify that I'm against multiple
bundles. I think it should either be ad-hoc (generated at first valid
request) and cached for further requests unless/untill invalidated.

I feel "marking" individual files/components to "targets" would not be a
good idea. I beileve a solution the other way around, listing
dependencies on a file/component as "sources", would be more beneficial
and much eaiser to manage.

Either case, I'm having a hard time grasping how this would be handled
as a package since it would involve breaking/overriding the current core
"gather all and send" functionality.

You guys are more experienced in Meteor, so if you think it is possible,
count me in. I'll do whatever I can to help release such a package.

[Abigail Watson]

Having that kind of functionality would suggest a Meteor.isMobile() and Meteor.isDesktop() sort of syntax, similar to Meteor.isClient() and Meteor.isServer(). But then you get into the problem of all the different device types:

Meteor.isMobile()

Meteor.isDesktop()

Meteor.isPhone()

Meteor.isTablet()

Meteor.isWatch()

Meteor.isTV()

Meteor.isMobile()

And, suddenly, we're just talking about the functionality that device-detection implements.
https://atmosphere.meteor.com/package/device-detection

And it begs the question... if you've already defined all those media types, what about Print, Braille, and other handicap accessible media and device types?

Personally, I'd really like to see device-detection make it's way into core.  It's an imperfect package in what it does, but it has high value and utility.  I think it does a lot of what Serkan and others want; and could be quickly integrated with a little help from the Core team.  Top few things that would probably need to be done would be...

- refactor the Meteor.Device namespace to just be the Device namespace.  

- make some best-practice determinations on how to integrate with Meteor UI Templaets

- bump from meteor-router to iron-router.  

After those pieces are in place, maybe figure out how to integrate it into the bundler pipeline, and start doing build optimizations.  

--

You received this message because you are subscribed to a topic in the Google Groups "meteor-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-talk/ku7kvNJp8ek/unsubscribe.

To unsubscribe from this group and all its topics, send an email to meteor-talk...@googlegroups.com.

[Serkan Durusoy [DNA | encoding the future]]

Hi Abigail, I was in fact considering device-detection as an intermediate solution to present device based views as an alternative to css media queries. (Given that this still does not solve my parallel concern of unnecessary code getting delivered to the client)

Broadening on your suggestion, I'd say why not a Meteor.isClient(/* options, arguments */)

I'd still feel that would be missing something, though. I think laying down possible use cases is in order...

[Michael Layzell]

Both of those changes to device-detection should be trivial to make. I simply am still working with projects which use router rather than iron router, so I have yet to update the package.

I do question the value of adding code like this to core, as I feel that it rests firmly in package domain.

Also, this code doesn't help to reduce download sizes for Mobile devices, it only helps when radically different experiences are required which I have found to be infrequently.

[Silly Clown]

Is reducing the download size for mobile important?

[Ran Tavory]

reducing download time for mobile is important, yes. 

--

You received this message because you are subscribed to the Google Groups "meteor-talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

/Ran

http://tavory.com

[Pieter Soudan]

I think 'mobile detection' is not the way to go.

In your case 'mobile' is a concept covering too much different cases, so you end up cutting too much corners.

What you need is feature detection.

Is my end user capable of interacting with my app using touch gestures on his current device?

Is my end user's bandwidth sufficient?

Is my end user's screen big enough?

In what direction is it pointed?

Does a certain UI component have sufficient space (element queries VS screen quries using media queries)

...

Use modernizr (http://modernizr.com/) to cover most of the feature detection

use http://kumailht.com/responsive-elements/ for element queries

use https://github.com/WickyNilliams/enquire.js for JS media queries

Hope this helps.

Pieter

[Abigail Watson]

+1 feature detection.  

modernizer-meteor 
https://atmosphere.meteor.com/package/modernizr-meteor  

That being said, as much as I want to love feature detection in principle, in practice it can be a pain.  Most features group together according to device type, which makes querying by platform time generally easier.  Also, there's way more features in Modernizer than most people are concerned with; many of which are fairly obscure.  And it's missing many features that maybe people are concerned with (NFC, Bluetooth, Camera, and other features available through the hardware APIs...).

But yeah... 'mobile' covers a whole lot of use cases.  Would love to see a good feature detection solution.  

And thanks for the links, Pieter.  The syntax for responsive-elements isn't semantic enough for my needs, but the enquire.js package is really interesting.  I'd hate being able to give up my @media queries with nested Sass/Less syntax, but having javascript functions hooked up to media queries is very interesting.  I may get a lot of use out of that!  :)

--
You received this message because you are subscribed to a topic in the Google Groups "meteor-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-talk/ku7kvNJp8ek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-talk...@googlegroups.com.

[Marc d'Entremont]

I think the default, i.e. trivial web app should default to it’s current approach of sending a everything appropriate up to the client. 

With extra configuration the dev could break things down so that only appropriate stuff went to the client. 

This implies that when the developer had configured specific resources for specific capabilities, i.e. features, that they get delivered.

I don’t really like the approach of saying do x if the client isMobile or such. There are just too many permutations and the group maintaining that codebase would be in world of hurt, especially as there is no sign that the explosion of devices will slow or regress. 

Modernizr and enquire.js seem to have the best approach at this point, i.e. detecting based upon capabilities, i.e. features. They probe to determine if the platform supports a specific capability and then if it does allow the code that uses that capability to run or have other code loaded dynamically. 

That said, I don’t have a problem with detecting the platform, only with coding against.

For the most part it’s the markup and CSS that is the most critical. Javascript can be coded such that when a specific element does not exist that the code doesn’t run, so it’s much less important, but it does imply that different elements must be there. Also, determining the viewport size and executing code is what really what media queries are designed for, so we shouldn’t be trying to reproduce the wheel. Unfortunately, media queries don’t tie into the JavaScript event model so things like the enquire.js seem like the best solution for that type of logic

Media queries are largely limited to layout and moving things around in a visual manner. When the client has the same markup for radically different screen dimensions, and you want different layouts for those screens, you end up pulling elements out of the flow and absolute positioning them with JavaScript. This is really suboptimal. It’s better to send up different markup and CSS and let the browser do what it’s designed to do.

So it seems that there are three base problems:

1. Packaging of assets
• Expressing what is supposed to go to the client based upon criteria
2. Loading of assets
• When JS, CSS and HTML are loaded by the browser the appropriate assets need to be loaded. This should likely be based upon the markup, but if the assets are already there, all the better
3. Functioning correctly for the  platform: 
• Running of code based upon a capability, e.g. orientation, location, SVG support, ...
• Layout the document, i.e. loading the correct template
• Styling the DOM elements, i.e. having the correct CSS so that things look nice.

So when developer must express what goes up based upon capability I think there are two viable approaches. 

1. Folder layouts
• Easy to conceptualize, but can potentially explode, e.g.
• client
• views
• screen_min-width_45em
• screen_max-width_50em
• ...


2. Config file
• Certainly more cognitive effort, but easier to manage as it’s really just a manifest file
• “all” #asset common to all clients
• styles
• global.css
• all.styl
• behaviors
• login.js
• accounts.coffee
• data
• login.html
• layout
• main.html
• header.hbs
• footer.jade


• “screen and (max-width: 768px)”
• styles
• about.css
• store.styl
• behaviors
• cart.js
• data
• cart.html
• layout
• main.html
• header.hbs
• footer.jade

Loading of assets would likely have a small piece of JS with something like Modernizr and/or enquire.js that would do some detection and report back to the server. While that is happening things that defined as going to all clients is being pushed up. After detection specific assets could be pushup.

Functioning correctly would likely mean making being able to make decisions on the client. I expect that a package that provided a holistic interface to enquire.js and Modernizr would be handy.

My 2 cents.

Marc

[Serkan Durusoy [DNA | encoding the future]]

This has become a great thread. I'd like to thank everyone.

I'm not pro or against any of the device/type/feature detection,
progressive enhancement or graceful degradation techniques. They all
have their usecases.

As I said earlier, we had a project where we needed to specifically
target IE7 (and actually a specific version of Blackberry browser). The
client was *very* specific about this and wanted all other
browsers/devices to be presented with a warning message only.

I also like to reiterate my original opinion. I'm seeking a solution
where I would be able to send a set (or bundle) of css/js files to the
client selectively and on demand (lazily).

Deciding *in which conditions* to send them is a whole other subject,
which I believe is actually pretty mature in the Meteor world. Any
Meteor developer can go for device detection, "mobile" detection,
feature detection with already available native or third party
solutions, today! And yes, there is certainly room for much improvement.

But, my argument is something different, something that takes whatever
strategy deemed appropriate by the developer as *input* to generate a
*customized output*.

Such input might be something totally different than these discussions.
For example, I may want to target admin users with a different bundle. I
may want to target a specific geography with a different bundle. One may
come up with countless other reasons as such.

[Abigail Watson]

Remember that the /client directory is synonymous with the Meteor.isClient() function, and /server is synonymous with Meter.isServer().  The bundler goes through and combines all the files in /client with all the code in Meteor.isClient().  

So a folder layout approach is possibly symmetrical to the device-detection package's approach.  I'm fairly lukewarm about the following folder structure:

/client/view/phone
/client/view/tablet
/client/view/desktop

/client/view/watch

/client/view/tv

And I'm not sure if this is all that much better:

/client/view/screen_min-width_45em

/client/view/screen_max-width_50em

The following doesn't make any sense:

Device.screen_min-width_45em()

Device.screen_max-width_50em()

But something like this might work nicely, and be in keeping with the enquire.js approach:

Device.Screen({min-width: "45em"}, function(){ . . . })

Device.Screen({max-width: "50em"}, function(){ . . . })

Also, it's interesting you mention a config file as a manifest file.  Because that's exactly the approach Google Chrome Apps and the Google/Apache/PhoneGap toolchain is taking.

--
You received this message because you are subscribed to a topic in the Google Groups "meteor-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-talk/ku7kvNJp8ek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-talk...@googlegroups.com.

[Marc d'Entremont]

I agree. I don’t really like the folder approach. It would impossible to keeps things DRY. 

Device.Screen({min-width: "45em"}, function(){ . . . })

Device.Screen({max-width: "50em"}, function(){ . . . })

The Device.* makes an API that divides the application into mutually exclusive bits. 

It would be better to have something more like a match or selector metaphor we allow a much more DRY elegant approach, as not everything is about screen size, e.g. rgba, HTML Audio, touch, … This functions that run would therefore not be mutually exclusive. 

It could be tied in in a similar manner as events are currently, e.g. 

device = {

“all and min-width: 45em”: function(){ …},

“all and max-width: 50em”: function(){ …},

“svg”: function(){…},

“web workers”: function(){…},

“touch”: function(){…},

“multitouch”: function(){…}

}

All device feature matches would run. As far as ordering goes. I don’t know what approach would be best, but may be from top to bottom. Obviously, it would be better if it did not matter though.