Detect by Screen Size

Do you have a concrete idea how to do this on server side? Client detection is done by investigating the HTTP headers.

Any news on this?

I still have no idea how to realize such a feature.

This feature would be interesting but I don't see how Themekey would be able to react when the browser window is adjusted. I think detecting based on the width of the browser window is an awesome idea for Themekey -- but I think that is only processed during the onLoad.

Responsive Web theming does have an advantage over Themekey - but maybe I am wrong?

Responsive Web theming does have an advantage over Themekey - but maybe I am wrong?

For client detection, yes. In general I recommend doing responsive design on top of ThemeKey. ThemeKey does the job regarding channels, user roles and more stuff like that, responsive design satisfies the different clients.

Exactly. I was thinking on this last night and there is no reason Themekey would need to respond to anything as it is more of a controller based on internal Drupal paths, tokens, etc.

To add functionality such as "responsive design" would take Themekey outside of what it does best -- loading a theme based on platform, browser, path, etc. I suppose the argument could be made that Themekey should work with media queries but I don't think it is appropriate. Besides, media queries are essentially meta data (and their related style sheets) and that has nothing to do with what Themekey is made for.

Perhaps a tutorial on this would be helpful. I will consider writing one up for "Themekey and Responsive Web Design" (or something like that). They are connected...but not. Any thoughts on what I would certainly need to cover in a tutorial/documentation page -- specifically in regards to Themekey?

Documentation would be great.

Here's an example of a project that's already online but not yet finished:
https://gene-verstehen.de/catalog/pgskits
https://shop.bio.logis.de/de/catalog/pgskits

It's the same page of one drupal installation: /catalog/pgskits

ThemeKey switches the theme on the domain.
One theme is responsive. The other one is not because this version is embedded in an older site that is not responsive itself.

Another advantage is that using two different themes gives you two independent block configurations.

Which is what Themekey does best. It can work at a domain level, path level, etc.

It is the responsibility of the design itself to deal with the responsiveness based on browser width. I don't see any reason for Themekey to be involved at that level.

I will tinker with some ideas for a tutorial based on RWD ideas and come up with some context for Themekey.

I am dumb. Something that only just occurred to me is doing param look up to see if there is a "mobile" designation or not. For example, the user agent for iPad says "iPad" while the iPhone says "iPhone". Android has "Mobile" within the user agent on a phone while Android tablets lack that part.

Perhaps this is a way of looking at Themekey. You could use the RWD layouts to be loaded based upon the user agent (again!) reducing the need for pixel counting, which I find unreliable most of the time.

Anyway, just needed a quick brain dump before I think about this further...

Testing with Android tablet and Android phone.

Property: user:role
Operator: =
Value: anonymous user

-- Property: system:user_os
-- Operator: =
-- Value: Android

---- Property: system:user_agent
---- Operator: *
---- Value: Mobile

---- Property: system:user_agent
---- Operator: !*
---- Value: Mobile

What the above rules do: First, I ask what user role is active for the session. I then ask what OS is visiting. I follow those rules with two entries, asking if Mobile is present in the user agent. Android devices run both phones and tablets and if you merely ask for the platform (like iPhone or iPad), you may get lost as there is no "tablet" declaration in any user agent. The rule for Android is phones have "Mobile" within their user agent while Android tablets do not. This allows you to differentiate between the two platforms. I then load the theme for a phone or a theme for the tablet. You may not require the tablet theme as most designs should work within a tablet form factor.

This seems to work well. It doesn't answer the RWD portion but, as stated earlier, Themekey isn't meant for RWD. RWD is great and I have been tinkering with it -- but I am someone who like more control and I find scaling and collapsing designs do not work for every single web site. It really doesn't work when you have clients who don't like the idea of RWD and dislike scaling of elements on the fly and would rather have different designs for different platforms/sizes.

Anyway, there is my brain dump for the evening.

First off, I am a complete ThemeKey newbee. So please forgive any babbling below.
Thanks for your comment Shane, and it is very true what you say.
"Scaling and collapsing designs do not work for every single web site"
--> this is very very true. And that is exactly the reason why I think ThemeKey is very important in RWD (and has a role in this)

So how is this:
I am doing a project and I think it would be great to have ThemeKey work in sync with the Omega Theme. So, what I want to attempt is to have Themekey respond to the different CSS layouts Omega loads.

If you, or anyone, could point me in the right direction I would be very thankful.
Unfortunately I only just recently finished my first course in PHP and programming, so please be gentle.... :P

It seems that WURFL is still the best (or only) solution. Theoretically we can switch themes depending on all capabilities listed at http://wurfl.sourceforge.net/help_doc.php including screen size:

resolution_width	any integer number	This field represents the screen width expressed in pixels
resolution_height	any integer number	This field represents the screen height expressed in pixels

But therefore we have to vote for this issue first: #1321338: WURFL data is no longer open source

From my point of view the dual license of WURFL including AGLv3 should be OK.

So only task for ThemeKey than would be to port the existing WURFL integration for D6 to D7.

Due to the fact that there's no progress on the WURFL integration for Drupal anymore I close this issue.
Feel free to re-open it if you come up with a different approach.