Hi there, I’ve been on stable, now on the latest esr , and it appears that there is no longer an explicitly switchable mobile/desktop layout? I no longer see the toggle in the bottom left corner of the sidebar, and ?mobile_view=1 / ?mobile_view=0 no longer has any effect. It now transitions from desktop mode with the sidebar and the hamburger menu on the left to the mobile layout with no sidebar and the menu on the right by just horizontally resizing the desktop browser window. So is it now just based on the browser width? Previously it allowed for using the simplified mobile layout on a wider tablet screen if desired, or alternatively it allowed for the desktop mode (with more details in the topic list for example) to be used on a smaller phone or a narrow browser window for those users that preferred it.
That’s correct - we’ve been moving to simplifying our layouts to be properly responsive as it’s a more widely accepted design standard to use a width-responsive breakpoint. We’ve also found it simpler to maintain, and a width-based layout also plays well with other external design elements, such as when integrating shared banners across a main site + forum.
One of the downsides of this approach is you can’t run device specific logic in an initialiser.
A classic example is setting a different homepage for mobile vs desktop - you can’t do this now.
Imho this is going to require a much more dynamic approach to how templates are made.
Thanks for the reply. In principle that makes sense, but in practice that is a bit of a problem for more advanced/frequent users. As I mentioned, there is much less information visible in the topic list when in the reduced layout mode, especially compared to the desktop layout of something like Sam's Simple Theme, so some preferred to explicitly force the desktop layout, and it even still adapted correctly to make it fit horizontally without overflowing.
There are limits to doing this that we’ve removed with new methods — determining capabilities on init is fairly inflexible, if something changes we’d have to reload the whole page.
This is useful because devices are less predictable now: phones can unfold into tablets, laptops can convert into tablets, you can plug in a keyboard and mouse to so many things…
It feels different if you’re used to the old way, but anything you were doing in an initializer is likely still possible and more responsive to changing capabilities.
You can, now it’s more granular and you conditionally show/hide content within the same template rather than swapping out the whole thing. For example, we have a viewport object in our capabilities service now…
In a template…
{{#if this.capabilities.viewport.lg}}
Content for large screens
{{/if}}
{{#if this.capabilities.viewport.sm}}
Content for very small screens
{{/if}}
or in JS…
get myContent() {
if (this.capabilities.viewport.sm) {
return "short content";
} else {
return "the very very long content"
}
}
and then in CSS you can align with the same breakpoints like…
@use "lib/viewport";
.my-element {
font-size: 1em;
@include viewport.until(sm) {
font-size: 2em;
}
}
Sure, I’m aware of these replacements.
I’m looking forward to seeing patterns like this more fundamentally used though.
Like if my homepage is Categories on Desktop I get to see a Topic List.
A Topic List should also arguably show on Mobile too … currently you lose the Topic List element.
This is why the Force Mobile Homepage TC existed …
I hope I’m making sense …
Yeah makes sense, I think we will gradually make supporting changes like that… it’s just tricky when we’ve built so much using the old ways and have to support them in a way that doesn’t immediately break customization.
Unfortunately I need to carry on a bit more with this topic due to the users that really dislike the simplified mobile layout. This especially appears to be the case with tablet users in a vertical orientation.
So I guess I’m still a bit confused about exactly what changed, was the 
/ 
toggle just removed from the sidebar? Can that same JS method still be invoked with a custom script or something? Or is there some change to the desktop layout code that will make it no longer adapt responsively to narrower browser widths?
It looks like the browser’s “Desktop site” toggle (tested in Chrome and Firefox on an Android tablet) does force the old layout that used to correspond to Discourse’s own / toggle, and it still adapts responsively without overflowing. But the text seems to be much smaller than I remember it.
I also know how to select for certain width breakpoints i.e. @media screen and (max-width: 1000px) {… but I’m not sure if anything could be done there with CSS overrides?
I agree with this, I’ve never really liked the mobile layout on my phone, it feels a lot more restricting and everything is way too big unless my zoom is like halved. I’ve always used the desktop layout here until I literally couldn’t.
I understand the simplicity to maintain one layout and not worry about swapping but the choice is nice sometimes..
No, it’s not just removed from the sidebar. We have removed the underlying structure to toggle.
Does that mean that Force Mobile Homepage should be tagged as broken?
I’ve marked it broken.
For this reason:
So to force it to not revert to the simplified mobile layout with normal tablet vertical widths could I use something like this in the CSS? @media screen and (max-width: 700px) {…
Or is the “Desktop site” toggle in the mobile browser the only option to recommend to users?
Can they test using the “Request Desktop” together with increasing the font size in https://meta.discourse.org/my/preferences/interface ?
Hi, thanks for the reply.
One user tried the “Desktop site” toggle in the browser but reported that it made no difference. On my tablet it does change to the full-information desktop layout, but even at “Largest” the text is barely big enough, and it’s not ideal to set it in the user preferences because it makes the text way too big on other devices such as a PC that use the same account.
I guess “normal” is your current default. Have you tried selecting something else?
Oh, duh. 
Thanks, that helps a bit I guess.
I honestly don’t remember how font size scaling worked in the old explicit desktop mode on a smaller vertical screen, but I seem to remember them being bigger overall. Might have to add some CSS overrides for the “Largest” setting…