Navigation

Search

Maybe in our world there lives a happy little responsive Curve2 over there

Posted by Antes on April 02, 2014, 03:47:58 PM

Hello,
I am going to explain what is coming up with SMF 2.1 and Curve2 the new default theme.

What Is Responsive Design?
Responsive design allows users to navigate the site more easily with their mobile devices. The site adapts itself base on device’s resolution and uses defined CSS rules.

Why Responsive?
The main reason is responsive design uses CSS and it doesn't require in-depth template changes, This makes it easier to adapt to mods and custom edits. Since our user base likes (as well as us) customizing their forums, responsive design will not make it harder for them. Even mobile themes are more flexible but they brings support / modification issues with them. That was the reason why we chose responsive design over mobile theme.

This design is in its very early stages and many more adjustment will be made. Please see the screenshots for further information.


Respect Bob Ross (October 29, 1942 – July 4, 1995) - "Maybe in our world there lives a happy little tree over there"

Comments

Antechinus on April 02, 2014, 04:12:00 PM said
The main reason is responsive design uses CSS and it doesn't require in-depth template changes. This makes it easier to adapt to mods and custom edits. Since our user base likes (as well as us) customizing their forums, responsive design will not make it harder for them.

Well, I can't necessarily agree with that. It depends on what they want to do. If they only want to do very basic customisation then sure, it probably wont make it harder.

The more customisation they want to do, the harder it will get, simply because responsive means more CSS and more complex CSS that requires a lot more testing to get it to work consistently (as I'm sure you're already finding out ;) ).

However, if people want something that will work on all devices, they're pretty much stuck with dealing with more complex coding. You don't get something for nothing.


Quote
Even mobile themes are more flexible but they brings support / modification issues with them. That was the reason why we chose responsive design over mobile theme.

I have mixed feelings about it all. The problem with only using responsive is that it basically leads to a certain amount of bloat. Usually there is heavy reliance on using display: none; to hide a lot of stuff on small screens. So you have to include the extra code for that in the CSS, and the device still has to process all the extra CSS, and all the hidden HTML and javascript, even if it doesn't use it.

In some ways, pure CSS responsive is the least efficient way of dealing with the problem. A lot of people probably don't realise this, because they just see the latest buzz word and think it must be awesome. Like anything else, it's a trade-off. Rather than thinking of responsive as the best way of handlng things, it's probably more accurate to think of it as the least bad way.

If there was simple and reliable detection available, not via media queries (which are limited in application) but by another method, then it would make sense to use this to drop unwanted content via PHP conditionals. This would reduce the amount of CSS required, and reduce the amount of unwanted HTML and javascript that mobiles had to process.

The problem is that due to the piecemeal way in which every manufacturer does their own thing, there is no simple and reliable way of automatically detecting all devices and using that to apply PHP conditionals. IOW, we're still stuck with the age-old problem of coding for the web: lack of consistent and useful standards support. Hey ho. :P
Antes on April 02, 2014, 04:26:37 PM said
I don't have anything to say :P all valid and unfortunately we have to accept some of the facts if we (and yea we did :P) are going to use responsive design, Mobile themes are FASTER indeed because you detect the device via PHP and you can tell theme/source what to output, not just a display:none tricks...

Simplifying the Curve2 is other thing we are trying now like merging some parts into one (#1471 & #1477).
Tekkla on April 02, 2014, 04:37:15 PM said
I have mixed feelings about it all. The problem with only using responsive is that it basically leads to a certain amount of bloat. Usually there is heavy reliance on using display: none; to hide a lot of stuff on small screens. So you have to include the extra code for that in the CSS, and the device still has to process all the extra CSS, and all the hidden HTML and javascript, even if it doesn't use it.

RWD does not mean to hide or show content in relation of the devices viewport. It means to present always the complete stuff in a different way on different viewports. Realizing this makes your statements effectively meaningless.
Akyhne on April 02, 2014, 05:12:23 PM said
I started on a mobile theme a few days ago, using Jquery Mobile.
 
 
Boardindex
 

 
User menu
 

 
Posts (Display)

 
Options when clicking a specific post

 
 
I'm maybe 50% done now. Admin panel will not be included.
Antechinus on April 02, 2014, 05:29:06 PM said
I have mixed feelings about it all. The problem with only using responsive is that it basically leads to a certain amount of bloat. Usually there is heavy reliance on using display: none; to hide a lot of stuff on small screens. So you have to include the extra code for that in the CSS, and the device still has to process all the extra CSS, and all the hidden HTML and javascript, even if it doesn't use it.

RWD does not mean to hide or show content in relation of the devices viewport. It means to present always the complete stuff in a different way on different viewports. Realizing this makes your statements effectively meaningless.

When you've coded an entire forum interface yourself, then you can start lecturing people on what it entails. ;) You seem to have missed that the OP agrees with me. There's a reason for that.
Antes on April 02, 2014, 05:36:26 PM said
I have mixed feelings about it all. The problem with only using responsive is that it basically leads to a certain amount of bloat. Usually there is heavy reliance on using display: none; to hide a lot of stuff on small screens. So you have to include the extra code for that in the CSS, and the device still has to process all the extra CSS, and all the hidden HTML and javascript, even if it doesn't use it.

RWD does not mean to hide or show content in relation of the devices viewport. It means to present always the complete stuff in a different way on different viewports. Realizing this makes your statements effectively meaningless.

That has to be the point, but the thing is forum software showing lots of lots of data to their users beside all that customizations adds extra data to users, as for core people we need to think all sides of it. For example I hide the user info part (where shows avatar/user-title/custom profile fields etc...), surely i can hide things one by one or show some of them but with some customization or adding some extra custom fields to your site, makes it look broken which we don't want to see it.


@Alex@ it would be better if you open a new topic about it :) Seems good, but the problem here we don't want to load another jQ Library to system. We may/not (its up to our development team) include new library(ies) to SMF in next versions (soon to talk about it).
Tekkla on April 02, 2014, 06:09:40 PM said
When you've coded an entire forum interface yourself, then you can start lecturing people on what it entails.
That isn't the point. It does not matter what content you want to show. If you start to hide content from the user, you are simply doing it wrong.


That has to be the point, but the thing is forum software showing lots of lots of data to their users beside all that customizations adds extra data to users, as for core people we need to think all sides of it.
I know about the complexity of transforming SMFs Curve theme into RWD. Really! :) I tried it by myself. But at some point I realized that the SMF 2.0 Curve theme is not very easy to convert and so  I lost the motivation to complete it. :(


For example I hide the user info part (where shows avatar/user-title/custom profile fields etc...), surely i can hide things one by one or show some of them but with some customization or adding some extra custom fields to your site, makes it look broken which we don't want to see it.
Do you hide the data completly or do you make it displayable by hover/click?

ApplianceJunk on April 02, 2014, 06:14:32 PM said
ok
Antes on April 02, 2014, 06:40:08 PM said
For example I hide the user info part (where shows avatar/user-title/custom profile fields etc...), surely i can hide things one by one or show some of them but with some customization or adding some extra custom fields to your site, makes it look broken which we don't want to see it.
Do you hide the data completly or do you make it displayable by hover/click?

At this point I'm hiding it completely, but its very early stages, I'm trying to make the main content visible clearly, i probably add some more jQuery-Toggle to some places so users can tap to see extra info, but still I think I'll hide some data from users completely. Because without complete rewrite of the theme its impossible to show everything, Curve and/or Curve2 didn't design for responsiveness. I think i can say this, you can't expect a complete responsiveness from Curve2 at this point.
Tekkla on April 02, 2014, 07:03:53 PM said
Do you hide the data completly or do you make it displayable by hover/click?
Because without complete rewrite of the theme its impossible to show everything, Curve and/or Curve2 didn't design for responsiveness.

Jupp, I know this too. :)

I think i can say this, you can't expect a complete responsiveness from Curve2 at this point.
And don't get me wrong please. It wasn't my plan to offend someone (@Antechinus) or demand anything.

Another question: Is your RWD approach your own work or do you use parts of a common CSS framework like BS or YAML?
Antechinus on April 02, 2014, 07:09:50 PM said
It takes more than that to offend me. I was just amused at what I saw as your idealistic but impractical views.

The thing is that on desktop people expect a lot of stuff filling up the interface. Most of this is arguably useless even on desktop, but people have come to expect it and want it. You could add stacks of toggles and the js to run them and all sorts of other crud, just to make all the useless stuff usable on a phone, but really people on phones don't want it anyway. This means simply hiding it becomes the best option (IMO, feel free to argue).

And (again IMO) the problem with frameworks is that they invariably introduce yet more bloat. This can lead to problems too.
Tekkla on April 02, 2014, 07:33:28 PM said
It takes more than that to offend me. I was just amused at what I saw as your idealistic but impractical views.
It's not idealistic. It's reality. I mean it for sure. Hiding content of one and the same system only because of uisng a different displaydevice is simply bad. Maybe you got me wrong in what I mean about content. It is not the fancy coloured theme or a toggleable header. It's about informations and the ways to get them.

The thing is that on desktop people expect a lot of stuff filling up the interface. Most of this is arguably useless even on desktop, but people have come to expect it and want it. You could add stacks of toggles and the js to run them and all sorts of other crud, just to make all the useless stuff usable on a phone, but really people on phones don't want it anyway. This means simply hiding it becomes the best option (IMO, feel free to argue).
What is the conclusion of this? Tapatalk.

And (again IMO) the problem with frameworks is that they invariably introduce yet more bloat. This can lead to problems too.

Bloat, bloat, bloat. Did you ever try the customizer for BS? And what problems do you mean?
Akyhne on April 02, 2014, 07:47:35 PM said
@Alex@ it would be better if you open a new topic about itSeems good, but the problem here we don't want to load another jQ Library to system. We may/not (its up to our development team) include new library(ies) to SMF in next versions (soon to talk about it).
You only have to load what's nessescary to the theme itself. No big deal, really.

What is the conclusion of this? Tapatalk.
Don't ever go there, please!
Antechinus on April 03, 2014, 02:08:06 AM said
It's not idealistic. It's reality. I mean it for sure. Hiding content of one and the same system only because of uisng a different displaydevice is simply bad. Maybe you got me wrong in what I mean about content. It is not the fancy coloured theme or a toggleable header. It's about informations and the ways to get them.

I knew what you meant. My point is that a lot of the information on the desktop interface is useless, IMO. It's not worth the code to run it, and I often ditch or hide a fair amount of it on custom themes, even for desktop. There's such a thing as feeding people too much information. However, people tend to expect to see things just because they've always been there, regardless of whether they're useless or not. My 2c is these things are even less likely to be worth the code on a phone, so why make the code twice as complicated?


Quote
What is the conclusion of this? Tapatalk.

Well, some people seem to love Tapatalk. Takes all sorts. But no, the logical conclusion is to give people enough tools to do the job they want to do, and no more than that.


Quote
Bloat, bloat, bloat. Did you ever try the customizer for BS? And what problems do you mean?

Nope, have no idea what the customiser for BS is. Bloat is a problem in itself, because it makes things more complicated to code and is slower to run. I like clean code.
Antes on April 03, 2014, 03:27:01 AM said
Another question: Is your RWD approach your own work or do you use parts of a common CSS framework like BS or YAML?

Completely my work. I worked with MetroUI & Bootstrap 2.x/3.x but they are not really good for SMF (I mean for already written theme).

It takes more than that to offend me. I was just amused at what I saw as your idealistic but impractical views.

The thing is that on desktop people expect a lot of stuff filling up the interface. Most of this is arguably useless even on desktop, but people have come to expect it and want it. You could add stacks of toggles and the js to run them and all sorts of other crud, just to make all the useless stuff usable on a phone, but really people on phones don't want it anyway. This means simply hiding it becomes the best option (IMO, feel free to argue).

And (again IMO) the problem with frameworks is that they invariably introduce yet more bloat. This can lead to problems too.

Heh ^^, I want to keep the view on mobile simple as well but feedbacks on beta shapes it and I'll change things based on user request at this time. :P

It's not idealistic. It's reality. I mean it for sure. Hiding content of one and the same system only because of uisng a different displaydevice is simply bad. Maybe you got me wrong in what I mean about content. It is not the fancy coloured theme or a toggleable header. It's about informations and the ways to get them.

I knew what you meant. My point is that a lot of the information on the desktop interface is useless, IMO. It's not worth the code to run it, and I often ditch or hide a fair amount of it on custom themes, even for desktop. There's such a thing as feeding people too much information. However, people tend to expect to see things just because they've always been there, regardless of whether they're useless or not. My 2c is these things are even less likely to be worth the code on a phone, so why make the code twice as complicated?

Lets say different approaches here, @Tekkla I'm not sure if you were around or tested the earlier builds of SMF2.1, it had the user-drop menu (hover the nickname) & we were hiding lots of data on desktop view as well. That raised concern some and we revert back to our normal systematic (surely that also upset some people).
Antechinus on April 03, 2014, 03:55:13 AM said
One thing you can be sure of. Whatever you do, somebody will complain about it. :D
Tekkla on April 03, 2014, 05:25:29 AM said

However, people tend to expect to see things just because they've always been there, regardless of whether they're useless or not. My 2c is these things are even less likely to be worth the code on a phone, so why make the code twice as complicated?
Agreed. At this point it is no more a discussion about RWD. ;)


Nope, have no idea what the customiser for BS is.
http://getbootstrap.com/customize/


Bloat is a problem in itself, because it makes things more complicated to code and is slower to run. I like clean code.
Clean isn't only small code. It's also should be readable and reusable within and outside of the scope it was created for. I know that this can and does not fit for each line of code you create.
After many years of "unbloated" and "individual" coding and styling I startet to use different frameworks for my work. And what can I say? All my work, my "professional" approach in keeping things simple and clean, was pretty much work someone else already did better and in a way which is much more reusable than anything else I created. So I asked myself: Why reinvent the wheel again and again?


Completely my work
I really like the idea of a responsive SMF theme. :) Do you use a grid system for it?
Antes on April 03, 2014, 05:32:26 AM said
No, I didn't consider using grid system, we want to keep it simple - I don't want to turn SMF's CSS into Bootstrap like framework. That can only be happening if we decide to build a core (like smCore) for our eco-system.
Antechinus on April 03, 2014, 03:48:55 PM said
Clean isn't only small code. It's also should be readable and reusable within and outside of the scope it was created for.

Where did I say it shouldn't be? Why would I want code to be clean, if not to make it readable and useable? I'm all in favour of heavily commenting CSS, and minifying it before it's sent to the browser.

Why frameworks suck
Tekkla on April 03, 2014, 08:02:24 PM said
Why frameworks suck
Ehm.

a) Outdated in case of Bootstrap.
b) Nothing special. Simple and common guidelines for using HTML5 + CSS3 in combination with JS.
c) Most "do nots" are done in SMF.
d) Using a framework does not mean to use all of it.

Let us stop this discussion here. For me it's a little bit like running in circles. :)

I'm all in favour of heavily commenting CSS, and minifying it before it's sent to the browser.

Commenting, minifying (combining) and proper caching. Jupp. I'm with you.
Antechinus on April 03, 2014, 11:11:29 PM said
Hopefuly most of the do nots wont be in 2.1. :D I'm well aware that 1.1.x and 2.0.x are far from perfect.

But yeah, I'm happy to stop now. A lot of this comes down to personal preference anyway.
rower on April 05, 2014, 02:44:07 PM said
Users need flat theme build only for CSS. In mobile device im using tapatalk...
Antes on April 05, 2014, 02:51:05 PM said
Users need flat theme build only for CSS. In mobile device im using tapatalk...

I think you mean *with*, yea Curve2 doesn't have images for bar places etc... Its mostly done with CSS. About flat theme we discussed it (inside) and we're keeping Curve2 as it is :) with curves :D
Petter B on April 09, 2014, 01:55:22 AM said
I am very happy SMF finally will get a responsive theme, it´s the way to go!  :)

As I understand this will only affect the Curve2-theme and not add any kind of responsiveness to all the old and custom built themes out there.
Do you think we are better of:
1. Customizing Curve2 to look like our old themes
or
2. Adding the responsive css parts from Curve2 to our theme?

If 2, it would be great if someone made a manual on how implement the changes. Well, the very best would be a mod that made the changes to our custom theme, but I guess that would not be possible...
Antes on April 09, 2014, 02:02:59 AM said
I am very happy SMF finally will get a responsive theme, it´s the way to go!  :)

As I understand this will only affect the Curve2-theme and not add any kind of responsiveness to all the old and custom built themes out there.
Do you think we are better of:
1. Customizing Curve2 to look like our old themes
or
2. Adding the responsive css parts from Curve2 to our theme?

If 2, it would be great if someone made a manual on how implement the changes. Well, the very best would be a mod that made the changes to our custom theme, but I guess that would not be possible...


We had some structure changes (yet some more will be done) in Curve2, so I think some parts will apply to old themes but in general it probably look bad. You can grab my work here : https://github.com/Antes/kittenground/blob/responsive_paws/Themes/default/css/index.responsive.css
Kryzen on April 09, 2014, 11:43:21 AM said
Nice work, it looks great. :)
Sunburned Goose on April 10, 2014, 01:37:09 PM said
I've been looking at a Bootstrap 3.0 implementation for a while that leaves many of the features intact.  The problems for me are tables.  This page uses BS3 w/ a fluid grid & breakpoints.

Here's some screens where I did some reflecting on the header.  Here it is on the desktop, tablet, and phone.

http://forum.tiedtheleader.com/?theme=43







Good luck with your work.  SMF needs this capability by default.
[yub] Lazo on April 10, 2014, 04:56:38 PM said
Glad to see this, keep the good work up. Can't wait for the first stable version of 2.1!  :)
Antes on April 10, 2014, 05:11:53 PM said
I like teasing more and more :P so here is the new board-index (Captured via Samsung Galaxy SIII)
live627 on April 10, 2014, 08:49:31 PM said
I like teasing more and more :P so here is the new board-index (Captured via Samsung Galaxy SIII)
Gradient is cut off.
margarett on April 10, 2014, 09:00:23 PM said
I think that's just the number of colors of the image (if we're talking about the same thing :P )
Bloc on April 11, 2014, 02:03:33 AM said
I like teasing more and more :P so here is the new board-index (Captured via Samsung Galaxy SIII)
What happens in that small space when a board has one 50.000+ posts...? And why keep the linebreak in "last post"? Would seem better to keep that entire line in one sentence.
Antes on April 11, 2014, 03:35:13 AM said
Gradient is cut off.

hu? (read this without drinking my first coffee)

What happens in that small space when a board has one 50.000+ posts...? And why keep the linebreak in "last post"? Would seem better to keep that entire line in one sentence.
that probably break the layout especially when a board has 1.000.000 posts in it. I'm trying to show everything on acceptable layout, still in long term things will change - its from code, I'll change it just thinking what to do :)
Antechinus on April 11, 2014, 02:40:53 PM said
I like teasing more and more :P so here is the new board-index (Captured via Samsung Galaxy SIII)

Suggestion: ditch the topic and post counts on mobile. Personally, I've even ditched them on desktop sometimes, and nobody complains about it. If you want to keep them with a compact layout, you can always use the title attribute on the board link.

Would also suggest truncating the board description to one line of text (overflow ellipsis) or even having no board description. The standard interface includes a lot of stuff that is basically just there to stop large screens looking empty. It's not actually necessary.
Bloc on April 11, 2014, 03:05:38 PM said
Except when you do want to read that topic/post count on the mobile too. The key is layout control - not content control(at least to a lesser degree).
Antechinus on April 11, 2014, 03:34:38 PM said
Which in practice is basically never. I mean seriously, how many times have you actually wanted to know exactly how many topics and posts are in a board? My bet is that 99.9% of the time you don't give a rat's, and even when you do take notice of those stats it's only because they're in your face. If they weren't, you wouldn't miss them.

However:

Quote from: What I just said
If you want to keep them with a compact layout, you can always use the title attribute on the board link.
Dragooon on April 11, 2014, 03:55:57 PM said
If you want to keep them with a compact layout, you can always use the title attribute on the board link.
Pretty sure that'd be useless on a mobile/compact device
Antechinus on April 12, 2014, 05:14:38 PM said
Dunno. Never browse on mobile myself. Have to get someone to try it.
Bobby on April 14, 2014, 11:17:25 AM said
Hi all,
The SMF 2.1 default theme (Curve2) isn't responsive when I resize/stretch my computer browser! It's just responsive on the mobile device, isn't it?  So is it a "fully responsive" theme? :-)
Ricky. on April 18, 2014, 03:01:35 AM said
Why frameworks suck

Loved that, I used to think that I am alone who think all that is crap most of the time.. ;)
Dragooon on April 18, 2014, 06:21:59 AM said
Clean isn't only small code. It's also should be readable and reusable within and outside of the scope it was created for.

Where did I say it shouldn't be? Why would I want code to be clean, if not to make it readable and useable? I'm all in favour of heavily commenting CSS, and minifying it before it's sent to the browser.

Why frameworks suck
Ehm...to be fair that site is using reveal-js, which is a framework for HTML5 presentations...
live627 on April 19, 2014, 04:16:13 AM said
the irony.....
DeroZ on April 20, 2014, 05:50:09 PM said
where can i see a demo?

Antes on April 20, 2014, 05:56:52 PM said
where can i see a demo?



I can't promise to keep this place up-to-date (because I'm working on different things), but you can get some idea here :)
DeroZ on April 20, 2014, 06:04:51 PM said
ok, np  :)



radu81 on May 15, 2014, 08:35:17 AM said
nice work!
Stüldt Håjt on May 15, 2014, 11:55:06 AM said
Google has some good resources about responsive design.

https://developers.google.com/web/fundamentals/
http://www.google.com/think/multiscreen/
Akyhne on May 16, 2014, 05:47:13 PM said
Trying to guess how people wants to experience a website this way, isn't one I like. And honestly, I don't see the point.
Tablets and phones are getting higher and higher resolutions, therefore responsive themes becomes less and less a great idea.

Maybe a few years back...!
Bloc on May 16, 2014, 06:45:19 PM said
Trying to guess how people wants to experience a website this way, isn't one I like. And honestly, I don't see the point.
Tablets and phones are getting higher and higher resolutions, therefore responsive themes becomes less and less a great idea.

Maybe a few years back...!
I disagree. Viewing a desktop-made theme on 720x1280/1280x720 phone is still worse with things like dropdown, multicolumns/tables and small(ish) links. It just don't work on a 5 inches device compared to a (for example) 24 inches one. You need bigger hit areas for clumsy fingers, no hovering schemes to show a menu, less columns that don't look cramped and so on.

One can argue about how it should actually look designwise..but theres no doubt a separation must be made.
Antes on May 17, 2014, 04:32:15 AM said
As long as the screen sizes stays same, higher resolution doesn't fix the problem for view-point. I'm using my 4'' Lumia (800x480) to real time testing, I also used Galaxy S3/S4, all the phones benefits the changes done via responsive CSS.
Bloc on May 17, 2014, 06:34:05 AM said
Not sure if I understood your correctly, Antes :) ..but just shrinking down a webpage meant for 24'' 1280x720 will of course "fit" on a 1280x720 phone..its just that the pixels are so dense you can't see properly.  And at my age I need them to be a bit bigger lol.

Responsive can change that by adding buttons that are larger for example, on phones. If, as I've learned, you also detect the medium though css, you can make big(ish) linked buttons on 1280px phone - but regular links on 1280px monitors. Its then a combination: both medium and resolution have to be taken into account to make it optimal on every medium.

What really would be helpful, its that a screen also reported its physical size to the webpage somehow(maybe it does already?)..then you could design for 1080p on any physical size...
Dragooon on May 17, 2014, 06:36:16 AM said
Quote
What really would be helpful, its that a screen also reported its physical size to the webpage somehow(maybe it does already?)..then you could design for 1080p on any physical size...
That's what he was saying, it already does that and it's designed in such a way that the screen's physical size is taken into account and not the pixel resolution
Antes on May 17, 2014, 06:42:59 AM said
That's why we are using;
Code: [Select]
<meta name="viewport" content="width=device-width, initial-scale=1" />
This read may be helpful to define it:
http://blog.javierusobiaga.com/stop-using-the-viewport-tag-until-you-know-ho
http://webdesign.tutsplus.com/articles/quick-tip-dont-forget-the-viewport-meta-tag--webdesign-5972
Bloc on May 17, 2014, 06:55:44 AM said
But then its even more important to separate the two, instead of just adding the view-port meta tag. The articles you linked to basically says avoid using it.

I think I have to experience this for myself, figure out what works best. There are clearly a lot of confusion as to what is optimal. :D From a designer point of view(and user) I foremost want my design to look great and be equally readable on every medium. That means using methods that allow me to do that, and not just leave it up to the medium at hand.
Antes on May 17, 2014, 07:04:14 AM said
If you are going to separate things go for mobile (jQMobile or etc...), if you don't want to create another (child) theme then go for responsive.
Bloc on May 17, 2014, 07:13:29 AM said
Yup, responsive is the way to go..but I need also to have a way to say: hey, this is 1280 and I can have 3 columns here, but on phones(since they are smaller) i just want 2 columns since the text will be more cramped here(when the text have the approx same physical size as the monitor).

Do you see the problem? :) A lot of other things are solved fine by RD, but avoiding one-column-fits-all-design I need that kind of control to make best use of widescreens as well as mobile phones, especially when they both have high resolutions.
Dragooon on May 17, 2014, 07:17:31 AM said
Yup, responsive is the way to go..but I need also to have a way to say: hey, this is 1280 and I can have 3 columns here, but on phones(since they are smaller) i just want 2 columns since the text will be more cramped here(when the text have the approx same physical size as the monitor).

Do you see the problem? :) A lot of other things are solved fine by RD, but avoiding one-column-fits-all-design I need that kind of control to make best use of widescreens as well as mobile phones, especially when they both have high resolutions.
Uhm, that's what we've been saying. You CAN do that via responsive design. Just see getbootstrap.com on your desktop and then a 1080p phone
Bloc on May 17, 2014, 07:29:33 AM said
well, ok, but I don't want a bootstrap thingie to be smacked into a theme - I want to learn what it does instead. But I'll check it out.

I guess my argument was more with this:
Trying to guess how people wants to experience a website this way, isn't one I like. And honestly, I don't see the point.
Tablets and phones are getting higher and higher resolutions, therefore responsive themes becomes less and less a great idea.

Maybe a few years back...!
.than anything else. So we are possibly promoting the same thing here.
Antes on May 17, 2014, 07:51:24 AM said
https://github.com/Antes/kittenground/blob/responsive_paws/Themes/default/css/index.responsive.css this may help :)
Dragooon on May 17, 2014, 07:59:09 AM said
Quote
well, ok, but I don't want a bootstrap thingie to be smacked into a theme - I want to learn what it does instead. But I'll check it out.
We're not using Bootstrap, but the fundamentals remain the same. All the things you're saying are already possible and being done
Bloc on May 17, 2014, 08:34:25 AM said
After some searching it seems my best option is to use a script like device.js , then use that in combo with media queries. Theres no CSS-only detection of physical size yet, at least not fully supported.
Quote
well, ok, but I don't want a bootstrap thingie to be smacked into a theme - I want to learn what it does instead. But I'll check it out.
We're not using Bootstrap, but the fundamentals remain the same. All the things you're saying are already possible and being done
I KNOW its been used partly in SMF, I have looked at the code many times. You'll have to excuse me for not trusting that everything SMF does is "correct". Every time I look at the size of default theme's stylesheet(2.0 or 2.1) I am reminded that some things you just have to work out for yourself.
Dragooon on May 17, 2014, 08:38:09 AM said
Quote
After some searching it seems my best option is to use a script like device.js , then use that in combo with media queries. Theres no CSS-only detection of physical size yet, at least not fully supported.
Define fully supported? I'm fairly sure device-width works on all major platforms
Antes on May 17, 2014, 10:38:49 AM said
I agree, we still have lot to do on Curve2 - even we can consider splitting the css into board.css / topic.css (but that's not relevant to this topic maybe we can discuss under new one).

But I think responsive styling will cover the all smartphones with 480p+
macjive01 on May 19, 2014, 11:10:51 AM said
Please when is this going to be ready ?
Antes on May 19, 2014, 11:30:34 AM said
Please when is this going to be ready ?

This will be inside of SMF2.1, not as a separate pack/mod/theme.
radu81 on May 19, 2014, 11:58:51 AM said
This will be inside of SMF2.1, not as a separate pack/mod/theme.

That's a great news and an important feature for SMF.  8) Thank you Antes!
Akyhne on May 23, 2014, 12:43:30 AM said
Trying to guess how people wants to experience a website this way, isn't one I like. And honestly, I don't see the point.
Tablets and phones are getting higher and higher resolutions, therefore responsive themes becomes less and less a great idea.

Maybe a few years back...!
I disagree. Viewing a desktop-made theme on 720x1280/1280x720 phone is still worse with things like dropdown, multicolumns/tables and small(ish) links. It just don't work on a 5 inches device compared to a (for example) 24 inches one. You need bigger hit areas for clumsy fingers, no hovering schemes to show a menu, less columns that don't look cramped and so on.

One can argue about how it should actually look designwise..but theres no doubt a separation must be made.
We actually don't disagree. You are exactly pointing out my concerns. You can buy 5" smartphones with high resolution, hence a responsive theme will never Work as intended on a phone like that. You really can't browse a forum in high res., without having to zoom in and out all the time. Therefore - to me - device detection is a much better solution than responsive themes.
Tekkla on May 23, 2014, 05:02:23 AM said
Therefore - to me - device detection is a much better solution than responsive themes.

RWD is not only making content sizeable and floatable in relation of the users device. It's about rethinking how to display the content. Best solution seems to me the mobile first approach. Following this, you do not need a special device detection.

For me, most important on RWD was to realize what's necessary and what's not. Do I need this button, link, information or is it crap? And what is important for me, the customer, the user and what is not? Do I really need to offer a total different user experience on different devices and screens?

And finally RWD is about realizing that the same content can be represented in different ways on different devices. No more one monolithic photoshop design converted to html and css.

I think this responsive Curve theme is a good start. Better is always possible, so let's wait and see what @Antes is planning for the future.
Dragooon on May 23, 2014, 05:49:43 AM said
Trying to guess how people wants to experience a website this way, isn't one I like. And honestly, I don't see the point.
Tablets and phones are getting higher and higher resolutions, therefore responsive themes becomes less and less a great idea.

Maybe a few years back...!
I disagree. Viewing a desktop-made theme on 720x1280/1280x720 phone is still worse with things like dropdown, multicolumns/tables and small(ish) links. It just don't work on a 5 inches device compared to a (for example) 24 inches one. You need bigger hit areas for clumsy fingers, no hovering schemes to show a menu, less columns that don't look cramped and so on.

One can argue about how it should actually look designwise..but theres no doubt a separation must be made.
We actually don't disagree. You are exactly pointing out my concerns. You can buy 5" smartphones with high resolution, hence a responsive theme will never Work as intended on a phone like that. You really can't browse a forum in high res., without having to zoom in and out all the time. Therefore - to me - device detection is a much better solution than responsive themes.
Please go read on how responsive theme and resolution detection actually works and CSS3 features such as device-width and pixel-ratio. Device's physical resolution and pixel density does not make a difference. A properly coded responsive theme will look the same on a high-res 5" and a low-res 5".
Tekkla on May 23, 2014, 06:56:15 AM said
Please go read on how responsive theme and resolution detection actually works and CSS3 features such as device-width and pixel-ratio. Device's physical resolution and pixel density does not make a difference. A properly coded responsive theme will look the same on a high-res 5" and a low-res 5".

In addition to this http://stackoverflow.com/questions/8785643/what-exactly-is-device-pixel-ratio
Scripty on May 23, 2014, 10:36:10 AM said
To have less working on SMF and making it more responsive, we could use bootstrap.
It saves a lot of time aswell as work.
Arantor on May 23, 2014, 10:37:42 AM said
Not trying to integrate it into SMF it doesn't.
Bloc on May 23, 2014, 01:49:51 PM said
Trying to guess how people wants to experience a website this way, isn't one I like. And honestly, I don't see the point.
Tablets and phones are getting higher and higher resolutions, therefore responsive themes becomes less and less a great idea.

Maybe a few years back...!
I disagree. Viewing a desktop-made theme on 720x1280/1280x720 phone is still worse with things like dropdown, multicolumns/tables and small(ish) links. It just don't work on a 5 inches device compared to a (for example) 24 inches one. You need bigger hit areas for clumsy fingers, no hovering schemes to show a menu, less columns that don't look cramped and so on.

One can argue about how it should actually look designwise..but theres no doubt a separation must be made.
We actually don't disagree. You are exactly pointing out my concerns. You can buy 5" smartphones with high resolution, hence a responsive theme will never Work as intended on a phone like that. You really can't browse a forum in high res., without having to zoom in and out all the time. Therefore - to me - device detection is a much better solution than responsive themes.

Well, as already pointed out a highres 5" and lowres 5" should look just the same(because the physical size is the same, though the quality will be different - better for high-res of course) - but in order to accomplish that you have to stop the stylesheet for switching to 20" optimised styles even if the resolution is the same as the 20" screen.

Ergo: responsive design works just fine, but it only makes sense to marry it with device detection. I don't know about you guys, but I rather NOT prefer mobile-first designs because it severely hinders the design possibilites on desktop screens. Not using all that wonderful screen estate just because it should also work on a smartphone is crazy.

On the other hand: yes, its def. needed to re-think and simplify the smartphone layout/styles - but desktops should not suffer because of it.
live627 on May 23, 2014, 01:58:46 PM said
Quote
I don't know about you guys, but I rather NOT prefer mobile-first designs because it severely hinders the design possibilites on desktop screens. Not using all that wonderful screen estate just because it should also work on a smartphone is crazy.
qft
Dragooon on May 23, 2014, 02:04:26 PM said
Quote
Well, as already pointed out a highres 5" and lowres 5" should look just the same(because the physical size is the same, though the quality will be different - better for high-res of course) - but in order to accomplish that you have to stop the stylesheet for switching to 20" optimised styles even if the resolution is the same as the 20" screen.
Please please actually try a responsive design and read up on them before throwing your claims that the responsive design will switch to the 20" optimised style even if the device is 5". That's complete and utter nonsense, you can very well make the 5" high res device return the value as if it's a low res standard 5" device which is actually the backbone of proper responsive design.

Also, there's a difference between mobile-first and responsive designs. I don't know anyone said anything about mobile-first designs here. SMF 2.1 is not having the mobile design first and then being blown up to support desktops, it's the other way around
live627 on May 23, 2014, 02:40:05 PM said
Someone mentioned bootstap
Dragooon on May 23, 2014, 02:41:54 PM said
Someone mentioned bootstap
Bootstrap itself is mobile-first but you can still create desktop-first interfaces with it, and we're not going to use Bootstrap, that'll be a lot of work on an already delayed 2.1
Akyhne on May 23, 2014, 02:42:21 PM said
Ergo: responsive design works just fine, but it only makes sense to marry it with device detection. I don't know about you guys, but I rather NOT prefer mobile-first designs because it severely hinders the design possibilites on desktop screens. Not using all that wonderful screen estate just because it should also work on a smartphone is crazy.

On the other hand: yes, its def. needed to re-think and simplify the smartphone layout/styles - but desktops should not suffer because of it.
Exactly my point!

Quote
Well, as already pointed out a highres 5" and lowres 5" should look just the same(because the physical size is the same, though the quality will be different - better for high-res of course) - but in order to accomplish that you have to stop the stylesheet for switching to 20" optimised styles even if the resolution is the same as the 20" screen.
Please please actually try a responsive design and read up on them before throwing your claims that the responsive design will switch to the 20" optimised style even if the device is 5". That's complete and utter nonsense, you can very well make the 5" high res device return the value as if it's a low res standard 5" device which is actually the backbone of proper responsive design.

Also, there's a difference between mobile-first and responsive designs. I don't know anyone said anything about mobile-first designs here. SMF 2.1 is not having the mobile design first and then being blown up to support desktops, it's the other way around
So You want to limit how a theme will Work on a 27" screen, just to make it Work the same way on a 5"?!
Arantor on May 23, 2014, 02:42:38 PM said
Has anyone here other than me actually attempted to integrate Bootstrap into 2.1's theme? Slapping Bootstrap in doesn't magically make it responsive. You still have to rewrite the theme to play with Bootstrap in the first place.
Dragooon on May 23, 2014, 02:45:27 PM said
Has anyone here other than me actually attempted to integrate Bootstrap into 2.1's theme? Slapping Bootstrap in doesn't magically make it responsive. You still have to rewrite the theme to play with Bootstrap in the first place.
I have, 0/10, would not recommend.

So You want to limit how a theme will Work on a 27" screen, just to make it Work the same way on a 5"?!
Nope.
Arantor on May 23, 2014, 02:47:56 PM said
Yeah, I came to much the same conclusion but I'm not enough of a themer to do a fat lot else and don't like the jQuery Mobile route much either.
Dragooon on May 23, 2014, 02:51:29 PM said
Yeah, I came to much the same conclusion but I'm not enough of a themer to do a fat lot else and don't like the jQuery Mobile route much either.
Bootstrap is nice if you're starting from ground as it already handles a lot of things for you and has a defined structure, but in SMF's case it'll require re-doing a lot of templates to properly fit bootstrap which is more work than creating your own responsive stylesheet.
[yub] Lazo on May 23, 2014, 05:03:53 PM said
Bootstrap is nice if you're starting from ground as it already handles a lot of things for you and has a defined structure, but in SMF's case it'll require re-doing a lot of templates to properly fit bootstrap which is more work than creating your own responsive stylesheet.
YUP! I fully agree. I also tryed it out, it's just to much work, and it still is not what you would call a good solution(for SMF).
Bloc on May 23, 2014, 05:05:17 PM said
Quote
Well, as already pointed out a highres 5" and lowres 5" should look just the same(because the physical size is the same, though the quality will be different - better for high-res of course) - but in order to accomplish that you have to stop the stylesheet for switching to 20" optimised styles even if the resolution is the same as the 20" screen.
Please please actually try a responsive design and read up on them before throwing your claims that the responsive design will switch to the 20" optimised style even if the device is 5". That's complete and utter nonsense, you can very well make the 5" high res device return the value as if it's a low res standard 5" device which is actually the backbone of proper responsive design.

Also, there's a difference between mobile-first and responsive designs. I don't know anyone said anything about mobile-first designs here. SMF 2.1 is not having the mobile design first and then being blown up to support desktops, it's the other way around
Then please explain. If I use ONLY media queries that search for certain widths..how can it filter out that its still a 5" device even if the width is above 1200px? By using other media query keywords to learn that?  Which ones? And how to combine those? I don't care about auto-zooming or what else mobile browsers do of tricks to make it look better, my simple need is a way to make responsive design look the way I intend to on ALL devices - not what the browser decides is the best. Thats not good design, I  might as well use Tapatalk then.

I am not "throwing out" stuff btw, I am voicing MY concerns and needs. If its possible, great, fine, super. But so far I haven't seen a good solution to it, so stop saying its possible and rather enlighten us ( or me it seems :P )


..I am not even sure what I am debating this still lol, since I suspect we have similar goals. I should stop, as of right now.
Dragooon on May 23, 2014, 05:12:04 PM said
Quote
Then please explain. If I use ONLY media queries that search for certain widths..how can it filter out that its still a 5" device even if the width is above 1200px? By using other media query keywords to learn that?  Which ones? And how to combine those? I don't care about auto-zooming or what else mobile browsers do of tricks to make it look better, my simple need is a way to make responsive design look the way I intend to on ALL devices - not what the browser decides is the best. Thats not good design, I  might as well use Tapatalk then.
Use device-width. Seriously. That's it, use device-width.
Code: [Select]
@media (max-device-width: 320px) {
}

The above will apply even if your device has 1120 x 640 resolution (a la retina iPhone), because the browser downscales the device-width to the relevant old-fashioned width to suite the actual needs. It is not a trick, it's a proper documented css3 feature. If you want a live example, pick up a phone and go to http://getbootstrap.com.
Dragooon on May 23, 2014, 05:18:48 PM said
Bootstrap is nice if you're starting from ground as it already handles a lot of things for you and has a defined structure, but in SMF's case it'll require re-doing a lot of templates to properly fit bootstrap which is more work than creating your own responsive stylesheet.
YUP! I fully agree. I also tryed it out, it's just to much work, and it still is not what you would call a good solution(for SMF).
It's a wonderful solution if someone has the patience to rewrite all the templates from scratch, but I don't think anyone does.
Tekkla on May 23, 2014, 05:19:42 PM said
Has anyone here other than me actually attempted to integrate Bootstrap into 2.1's theme? Slapping Bootstrap in doesn't magically make it responsive.
Not only tried. With the current state of Antes theme it works quite well. There are some points where Curve and Bootstrap do not live in good harmony but it wouldn't be a big deal to change this.

Of course, as discussed a few weeks ago, including BS bloats the forums css without profit for the forum itself. Maybe it would be a good idea to make Curve RWD theme a little bit more compatible to Bootstrap so modder can use it without theme glitches if they want.
Arantor on May 23, 2014, 05:22:09 PM said
Well... it's not beyond the bounds of feasibility, but I have better things to be doing than completing such a rewrite (since I started)
Tekkla on May 23, 2014, 05:31:37 PM said
Well... it's not beyond the bounds of feasibility, but I have better things to be doing than completing such a rewrite (since I started)
Coexistance in harmony would be a better solution. There are only a few things to change in Curve to reach this. A complete rewrite is like pain in the ass.
Arantor on May 23, 2014, 05:33:40 PM said
That's because you have to do a complete rewrite to ACTUALLY make it work properly, otherwise smashing tables and stuff into Bootstrap is a total waste of time and energy.
Antes on May 23, 2014, 05:37:02 PM said
There is a difference between adapting and rewriting. Yes we can use bootstrap 3.x on SMF2.2 (for example) with small patches on it, but will it look good? I don't think so - that's the point Arantor showing. If you want to use that type of things you need to do complete rewrite to theme. Otherwise you end up patching it like a rewrite (on long run).
Tekkla on May 23, 2014, 05:47:46 PM said
Have you ever tried to include Bootstrap after index.responsive.css?
Dragooon on May 23, 2014, 05:48:19 PM said
Have you ever tried to include Bootstrap after index.responsive.css?
What purpose would that serve?
Arantor on May 23, 2014, 05:49:22 PM said
Mass style breakage and no responsive benefits whatsoever?
Dragooon on May 23, 2014, 05:58:58 PM said
Mass style breakage and no responsive benefits whatsoever?
So, lots of fun? :P
Arantor on May 23, 2014, 06:01:09 PM said
If, however, you add it FIRST, things are decidedly less broken. Still very broken but it doesn't hurt nearly so much to try to fix. At least, that was what I found.
Tekkla on May 23, 2014, 06:13:54 PM said
No mass style breakage. You can see some differences in padding and margins. And you can see differences in how SMF and BS are using html elements. Mostly in heading usage.

http://tekkla.de/pics/with_bootstrap.jpg
http://tekkla.de/pics/without_bootstrap.jpg


It's only the boardindex, but the rest of the forum isn't much more broken than this.




Arantor on May 23, 2014, 06:16:53 PM said
Which 2.1 alpha is this based on? Is that current, or is that - say - from 3 months ago when I forked and started doing an integration (knowing full well that there's been a ton of work rewriting the templates since then)
Antes on May 23, 2014, 06:29:27 PM said
Have you ever tried to include Bootstrap after index.responsive.css?
Nope

Have you ever tried to include Bootstrap after index.responsive.css?
What purpose would that serve?
Nothing :D

Mass style breakage and no responsive benefits whatsoever?
lol :P

No mass style breakage. You can see some differences in padding and margins. And you can see differences in how SMF and BS are using html elements. Mostly in heading usage.

http://tekkla.de/pics/with_bootstrap.jpg
http://tekkla.de/pics/without_bootstrap.jpg


It's only the boardindex, but the rest of the forum isn't much more broken than this.

Because bootstrap only changed the general elements such as h3 / img etc... that picture (with bootstrap) 95% or even more only using index.css
Bloc on May 23, 2014, 09:06:47 PM said
Quote
Then please explain. If I use ONLY media queries that search for certain widths..how can it filter out that its still a 5" device even if the width is above 1200px? By using other media query keywords to learn that?  Which ones? And how to combine those? I don't care about auto-zooming or what else mobile browsers do of tricks to make it look better, my simple need is a way to make responsive design look the way I intend to on ALL devices - not what the browser decides is the best. Thats not good design, I  might as well use Tapatalk then.
Use device-width. Seriously. That's it, use device-width.
Code: [Select]
@media (max-device-width: 320px) {
}

The above will apply even if your device has 1120 x 640 resolution (a la retina iPhone), because the browser downscales the device-width to the relevant old-fashioned width to suite the actual needs. It is not a trick, it's a proper documented css3 feature. If you want a live example, pick up a phone and go to http://getbootstrap.com.

Ok, I finally got some eye-opening moments(or rather googling lol) here and realizing what device-width is really about. I stand corrected, this is what I should use.
Akyhne on May 24, 2014, 01:45:25 AM said
Quote
Then please explain. If I use ONLY media queries that search for certain widths..how can it filter out that its still a 5" device even if the width is above 1200px? By using other media query keywords to learn that?  Which ones? And how to combine those? I don't care about auto-zooming or what else mobile browsers do of tricks to make it look better, my simple need is a way to make responsive design look the way I intend to on ALL devices - not what the browser decides is the best. Thats not good design, I  might as well use Tapatalk then.
Use device-width. Seriously. That's it, use device-width.
Code: [Select]
@media (max-device-width: 320px) {
}

The above will apply even if your device has 1120 x 640 resolution (a la retina iPhone), because the browser downscales the device-width to the relevant old-fashioned width to suite the actual needs. It is not a trick, it's a proper documented css3 feature. If you want a live example, pick up a phone and go to http://getbootstrap.com.
But if you're on a phone with HD res., you will not benefit from that.
Tekkla on May 24, 2014, 03:10:58 AM said
Have you ever tried to include Bootstrap after index.responsive.css?
Nope

Have you ever tried to include Bootstrap after index.responsive.css?
What purpose would that serve?
Nothing :D

Mass style breakage and no responsive benefits whatsoever?
lol :P

No mass style breakage. You can see some differences in padding and margins. And you can see differences in how SMF and BS are using html elements. Mostly in heading usage.

http://tekkla.de/pics/with_bootstrap.jpg
http://tekkla.de/pics/without_bootstrap.jpg


It's only the boardindex, but the rest of the forum isn't much more broken than this.

Because bootstrap only changed the general elements such as h3 / img etc... that picture (with bootstrap) 95% or even more only using index.css

That is my point. To make it clear: Neither do I prefer a Bootstrap based theme nor do I want to replace the style SMF is theming the forum. For me it's all about extending, getting more opportunities. When I need to use BS with SMF, it would be great to use it without harming the forum display. This is for what I argue. Nothing else.
Antes on May 24, 2014, 03:39:18 AM said
@Tekkla I used Boostrap 2.3.x & 3.x (https://github.com/ProjectBFG/Simple-Discussions very old project), as well as MetroUI (http://metroui.org.ua/) (https://github.com/ProjectBFG/ModernUI4SMF very old project as well but concept). :P

It was pain really you can ask my project partner too @Yağız... here.
Bloc on May 24, 2014, 03:59:26 AM said
Quote
Then please explain. If I use ONLY media queries that search for certain widths..how can it filter out that its still a 5" device even if the width is above 1200px? By using other media query keywords to learn that?  Which ones? And how to combine those? I don't care about auto-zooming or what else mobile browsers do of tricks to make it look better, my simple need is a way to make responsive design look the way I intend to on ALL devices - not what the browser decides is the best. Thats not good design, I  might as well use Tapatalk then.
Use device-width. Seriously. That's it, use device-width.
Code: [Select]
@media (max-device-width: 320px) {
}

The above will apply even if your device has 1120 x 640 resolution (a la retina iPhone), because the browser downscales the device-width to the relevant old-fashioned width to suite the actual needs. It is not a trick, it's a proper documented css3 feature. If you want a live example, pick up a phone and go to http://getbootstrap.com.
But if you're on a phone with HD res., you will not benefit from that.
AFAICS the resollution is still there, 1080p if you ahve that, but the CSS media query can trigger on the device-width - meaning you can combinate width and device-width to target both low-res and high-res and they both both hit only mobiles.

Found a page with numbers that (for me) made it more clear:
http://screensiz.es/phone

Notice how device-width on phones go up to only 400 even if their resolution is high. THAT is what I was seeking,but stubbornly didn't acknowledge.
Dragooon on May 24, 2014, 05:20:18 AM said
Quote
Then please explain. If I use ONLY media queries that search for certain widths..how can it filter out that its still a 5" device even if the width is above 1200px? By using other media query keywords to learn that?  Which ones? And how to combine those? I don't care about auto-zooming or what else mobile browsers do of tricks to make it look better, my simple need is a way to make responsive design look the way I intend to on ALL devices - not what the browser decides is the best. Thats not good design, I  might as well use Tapatalk then.
Use device-width. Seriously. That's it, use device-width.
Code: [Select]
@media (max-device-width: 320px) {
}

The above will apply even if your device has 1120 x 640 resolution (a la retina iPhone), because the browser downscales the device-width to the relevant old-fashioned width to suite the actual needs. It is not a trick, it's a proper documented css3 feature. If you want a live example, pick up a phone and go to http://getbootstrap.com.
But if you're on a phone with HD res., you will not benefit from that.
AFAICS the resollution is still there, 1080p if you ahve that, but the CSS media query can trigger on the device-width - meaning you can combinate width and device-width to target both low-res and high-res and they both both hit only mobiles.

Found a page with numbers that (for me) made it more clear:
http://screensiz.es/phone

Notice how device-width on phones go up to only 400 even if their resolution is high. THAT is what I was seeking,but stubbornly didn't acknowledge.
Exactly