Composer on mobile thoughts (again)

010101

Current solution (as of May 2022) for those who stumble upon this thread:

/* Mobile Composer Tweak */

@media @phone {
.Composer:not(.minimized) {
      height: 48vh !important;
      bottom: 0 !important;
   }
}

https://discuss.flarum.org/d/27979-composer-on-mobile-thoughts-again/18

Experiment with the vh number. I just discovered that for a new post, due to the title field, 40 is not tall enough. You might prefer 45vh or 48vh. 50vh should work fine. At one point in my testing it seemed borderline too tall… so something like 48vh might work well.

Original post:

Note: In this original post I was more focused on trying to make the composer full height. That's no longer a priority. Instead the current solution (see above) at least ensures that the composer box is visible more often on mobile phones when the user taps "Reply." Without this hack, sometimes (especially with iPhones), the user will tap "Reply" and they won't see the composer box unless they scroll up. Ok, now on to the original post...

In the past I remember posting about the composer on mobile. Some CSS changes were made which did make it better.

But, I also remember asking things like, why not stick it to the bottom versus the top? Or even, why not make the composer full screen on mobile?

The consensus was that it needs to be like it is so you can see behind it (preview reasons).

Maybe on certain phones it works better and is helpful the way it is, but sometimes on iPhone it looks like the following screenshot. My concern isn’t that it is in the middle versus stuck to the top. My concern/question is: What’s the point of seeing behind it? Look at what tiny gaps/spaces there are on an iPhone XR. There’s such little space that I don’t think it helps much for preview purposes. Why not make it full screen? Then you click something to preview?

Of course, it’s not a big deal. I’m also fine with it the way it is. I just don’t quite understand the argument around making sure there’s some space above or below the box. On mobile, with such little real estate, it doesn’t seem all that helpful.

Is it because if you make it 100% full screen you can’t scroll and review other posts? That would be solved with a show/hide/preview icon.

rafaucau

I reported it here: flarum/core2808

Just enough CSS to make it better:

  .Composer:not(.minimized) {
      height: 100% !important;
   }

I don't know about iOS, but on Android then the editor adjusts to the keyboard height

010101

rafaucau It works for iPhone too. I wonder if there are any disadvantages to doing this? Because I’m sure core developers at some point would have thought about making it full screen. Because In my experience with this community the developers think about these types of things in depth. And so, am I breaking something by making it full screen? Hmm.

SychO

The consensus was not that the user had to see behind it, on the contrary, it was that if the user wanted to see the discussion, they could minimize the composer, and so we fixed the composer to the top.

Unfortunately, safari being safari, fixing the composer created major issues on that browser and the composer became unusable, so we made it so that in safari the composer stayed as it was before, absolute, at least then it worked.

010101

SychO Ok, maybe I’ll just try the full screen CSS and see what happens. Because with full screen if you want to see the discussion again, just exit the composer, no? With a combination of default behavior and the drafts extension what’s the issue with full screen and then close if needed?

SychO

010101 what’s the issue with full screen and then close if needed?

Idk, try it and see 🤷‍♂️

010101

SychO

I’ll let everyone know if I ever notice anything negative, but the code provided above works well. If you want to see the discussion you just exit the composer. By default Flarum temporarily saves it locally. I added a media query just in case since it’s only needed on small screens.

/* Composer full height on mobile */

@media (max-width: 767px) {
.Composer:not(.minimized) {
      height: 100% !important;
   }
}

rafaucau

010101 I had forgotten about that. It's even better to use Flarum variables:

@media @phone {
.Composer:not(.minimized) {
      height: 100% !important;
   }
}

😁

SychO

I don't think the !important is necessary, it's good practice to avoid using it as much as possible.

rafaucau

SychO This is necessary if you are overwriting exactly these composer styles

010101

rafaucau Thank you!

And yes, if you are adding this to the custom css box in the admin area, I tested it without !important and it doesn’t work. And so for this particular rule and doing it this way, you need !important.

010101

First issue with this found. If you go to edit a really long post you can’t scroll. Adding overflow scroll doesn’t work. Adding position fixed doesn’t work well either. I’m sure there’s the perfect CSS out there…

Oh, I bet it’s that Safari bottom menu issue… no time to explain if you don’t know what I’m taking about.

010101

Ok. Here is a solution that works well. The idea is to use intrinsic values. https://caniuse.com/intrinsic-width

The reason this works better especially in Safari iOS is because if you go with the standard 100% height option, Safari's bottom nav bar doesn't play nice. But, by using vh with height, and adding 100vh height to the body and composer, along with the stretch rules you see, it basically tells the browser: "Stretch the composer 100% height according to the viewport." -moz-available had to be added due to a Firefox "bug." -webkit-stretch for now has to be there as well due to Chrome. You may read notes like these at the Can I Use site (link below).

/* Composer */

@media @phone {
body {
  min-height: 100vh;
  min-height: stretch;
  min-height: -moz-available;
  min-height: -webkit-stretch;
  min-height: -webkit-fill-available;
  overflow: auto;
}
html {
  height: stretch;
  height: -moz-available;
  height: -webkit-stretch;
  height: -webkit-fill-available;
}

.Composer:not(.minimized) {
 height: 100vh !important;
}
.TextEditor-editorContainer {
overflow-y: scroll;
}
}

This has good browser support. No IE support. But, wasn't it decided pretty much that Flarum wouldn't support IE? Well, to block IE users we can do this. 🙂 And, I'm sure some rarer browsers, like I saw Opera Mini, won't support stretch. I'm not sure what happens in a browser that doesn't support this. If it's completely unusable or what?

P.S. I believe this same technique could be used to help with other issues Safari's bottom nav bar causes. Especially if you add browser sniffing logic. If Safari, add these stretch and vh type rules...

010101

The code I shared above works well but, there is one more issue to tackle. The Safari iOS virtual keyboard. It hides the toolbar of the editor if it is full screen. This would be solved if the toolbar was on top versus on bottom… but I’m not sure if it’s easy with CSS to get it above the textarea.

010101

Well. I’ve decided to abandon full screen. It’s got to be possible somehow. But, it’s just not 100% working in iOS Safari.

Instead, I’m at least doing this for now… I don’t know why, but forcing bottom:0 makes the composer pop up (so far from initial tests) fixed to the top every time in iOS Safari. But, it doesn’t work well for other browsers. And so, I found a CSS hack which will target only Safari.

/* Composer iOS Safari Fix */

@media screen and (min-color-index:0) and(-webkit-min-device-pixel-ratio:0)
{ @media {
@media @phone {
.Composer:not(.minimized) {
 bottom: 0 !important;
}}}}

https://solvit.io/bcf61b6

I’ve always been told that all iOS browsers are basically Safari. Well, that’s definitely not true. I mean, it could be partially true. Not fully. I have three browsers on my iPhone. Each one acts a little differently. I discovered that I needed to make the above rule Safari only because I opened Firefox iOS and the rule caused the composer to be off screen. But again, it does some kind of magic in Safari iOS… 🪄

This GIF shows it working in iOS Safari and then also iOS Firefox. But please trust me, it did not work in iOS Firefox without adding in the above Safari only hack so that Firefox ignores it.

What is this all about again? By default the way the composer opens on mobile Safari isn’t consistent. It sometimes opens in the middle or a little off screen. So far, there’s something about bottom:0 that keeps Safari from being a little naughty browser! 😂 Bad, Safari! AKA, the new IE.

1Dot

010101 Thank you so much for such a great explanation, I have a question like that if you can make some css only for Safari so is it possible to make some css only for Chromium based browsers?

010101

Welp. I'm sitting here once again thinking about this. It depends on the mobile browser, but sometimes it can be a super awful user experience when you tap reply, and you don't see the composer on the screen. Then you have to scroll up to see it.

Most CSS only solutions have negatives as you can see in above posts.

We need a JavaScript guru to either add to core, or create an extension which will detect screen size, then keep the mobile composer full height. And also the JavaScript should detect the mobile virtual keyboard and make sure the keyboard never hides a part of the composer.

🤔

Some interesting virtual keyboard API notes here which could be helpful.

https://web.dev/virtualkeyboard/

Could be browser support issues though with the virtual keyboard API. Sigh.

010101

Sometimes going back to an original idea works decently. I just took one of the original solutions from above, but instead of doing 100% height, I did 40vh (40% viewport height). ~~It seems to work... so far~~... I'd have to have all kinds of different phones to know for sure. Which I obviously don't.

Edit: I’ve switched from using 40vh to 48vh. Extra height is needed especially when starting a new post, due to the title field.

/* Mobile Composer Tweak */

@media @phone {
.Composer:not(.minimized) {
      height: 48vh !important;
      bottom: 0 !important;
   }
}

Why 48? Using 100 makes part of the composer box hidden depending on the virtual keyboard/bottom menu size. 50 was slightly too tall in Safari iOS (but still usable). 48vh should more consistently work regardless of mobile phone screen size and keyboard height.

Some extra reassurance: As you can see the media/phone CSS queries are used so you don't have to worry about this doing something weird on larger screens.

Experiment with the vh number. I just discovered that for a new post, due to the title field, 40 is not tall enough (the height I originally tried). You might prefer 45vh or 48vh. 50vh should work fine. At one point in my testing it seemed borderline too tall… so something like 48vh might work well more consistently.

CyberGene

Flarum on an iPhone is a bit lukewarm experience 😕 This problem with replying and having the composer hidden and having to scroll to find it is a huge let down. Also the infamous problem with the inability to scroll to the last unread post and instead scrolling back to previous posts while loading...

010101

CyberGene

You might try the CSS above. After adding bottom: 0 !important; it feels like it more consistently acts right.

So, height: 48vh !important to help ensure it shows up, then the bottom: 0 !important; just because in my experience it helps make it pop up in the same place more often.