TinyPortal

[@rjen]

It is a known glitch in TP on SMF2.1 when quick moderation is on. I have not been able to find an adequate fix.
I have even asked for tips from the SMF community here on the forum, but got no hints how to fix it.
https://www.simplemachines.org/community/index.php?topic=27642.msg4112522#msg4112522

Perhaps a css expert can suggest how to fix it?

This issue is only there for admins and moderators, since it is caused by the extra fields that show under the topics when users have permissions to move topics..

It is actually this issue with SMF curve which is enlarged by the TinyPortal divs encapsulating the forum content  : https://www.simplemachines.org/community/index.php?topic=581862.0

[Antechinus]

Ok, what size screen are we talking about? I see in the linked topic that 2.1 is only meant to support down to 320px wide (CSS px). The screenshot on page 156 of this thread is 1080 wide, and I have no idea of the DPR of the device it was taken on. So, need more information.

[@rjen]

In my forums it starts to happen at a width of less than 430 px.

My device is an Iphone 11, which has like 390px width..

You cannot view this attachment.

It is caused by the elements in quick_actions...

You cannot view this attachment. 

[Antechinus]

Ok, I'll take a look.

[@rjen]

Appreciated.

if you need it I can give you access to a test forum where the issue can be replicated...

A bit more info: the content of the qaction field determines the min width. In Dutch language the issue is showing on wider screens because the text strings are longer

[Antechinus]

I just installed the latest TP on 2.1 local. All default settings. It's fine at 375 (which is what Firefox responsive mode has as its "IPhone 11 Pro" preset).

ETA: Fine at 360 wide too (Galaxy S10/10+ preset). Now I'm wondering if the issue is an iOS/Safari issue rather than a width issue.

[Antechinus]

Aha. Got it. Webkit issue (colour me surprised ). I can replicate it on Chrome at 360px wide. Digging now...

[Antechinus]

Ok, easy one. Just revert all your display: table/table-row-group/table-caption/etc declarations on the main wrapper divs to a basic display: block; at the width where the issue kicks in.

[@rjen]

Ok, let me check. If I recall that's the heart of the responsive display atm, so that may not be as simple as it sounds...

[Antechinus]

Yes I thought of that after I posted it. But there should be alternatives. One possibility is using flex, if it's stacking order you are concerned about. By the time the problem kicks in you shouldn't need anything fancy. Just a reliable order to stack things vertically.

[@rjen]

Yeah, having a look at it but it is what I thought.

This was built a few years ago not using flex, and the guy who did it moved on. I have been looking into rebuilding it, but the whole tabel/caption/header/footer approach is confusing me every time.

I would be looking at a simple fix for now overriding the behaviour at narrow screens, but even that puzzels me atm. If you have any tips on the how to do that without too much rebuilding of the tp-responsive css file I would really appreciate it...

[Antechinus]

Ok, I'll take a look and see if I can think of anything useful.

[Antechinus]

Ok, have taken a quick look. Obviously by the time you get into all the block arrangement possibilities within panels it's a little complex, but the panels themselves are straightforward.

Turns out he used grid for the blocks-in-grids option anyway (makes sense) so beats me why he didn't also use grid for the main panels. But you don't really even need grid. You can do it with flex.

Code (basics) Select Expand

/* NOTE: Start by getting rid of these paragraphs, preferably from the template! */
/*
<p class="clearthefloat" style="padding:0px;margin:0px;"></p>
*/

/* Main parent div - does not need any CSS. */
.tp_responsive {}

/* Top panel - does not need any CSS. */
#tptopbarHeader {}

/* Main panel. */
#mainContainer {
display: flex;
}

/* 1st-child. */
#tpleftbarContainer {
flex: 0 0 auto;
order: 1;
}

/* 2nd-child. */
#tprightbarContainer {
flex: 0 0 auto;
order: 3;
}

/* 3rd-child. */
#centerContainer {
flex: 1 1 auto;
order: 2;
}

/* Bottom panel - does not need any CSS. */
#tpbottombarHeader {}

@media (min-width: 0px) and (max-width: 900px) {
#mainContainer {
flex-wrap: wrap;
}

/* @900px this goes to the bottom - side by side. */
#tpleftbarContainer {
flex: 0 0 auto;
order: 2;
/* Needs important to override the inline width style. */
width: 50%!important;
}

/* @900px this goes to the bottom - side by side. */
#tprightbarContainer {
flex: 0 0 auto;
order: 3;
/* Needs important to override the inline width style. */
width: 50%!important;
}

/* @900px this goes to the top. */
#centerContainer {
flex: 0 0 auto;
order: 1;
width: 100%;
}
}

@media (min-width: 0px) and (max-width: 500px) {
#mainContainer {
flex-direction: column;
}

/* @500px this goes to the bottom- stacked 1st. */
#tpleftbarContainer {
/* Needs important to override the inline width style. */
width: 100%!important;
}

/* @500px this goes to the bottom - stacked 2nd. */
#tprightbarContainer {
/* Needs important to override the inline width style. */
width: 100%!important;
}
}
That should work. Shouldn't need anything fancier. Mind you it's possible some browser/OS bug might bork it, but in principle that's simple and bulletproof.

Or you can do it with grid with, not much more code, but really grid is only useful for the intermediate stage between 500px and 900px. Outside that range flex is just as effective, and simpler.
ETA: Tested this. Easy. Works in FF and Chrome, right down to 360px wide. I have attached TP CSS files with the bits I commented out. I have not put the new code into those files yet. I just tested it in Stylus.

There is some crud in the files which I suspect is left over from earlier versions.

[@rjen]

Thanks, just got back home, so I can do some testing... will report back...

[@rjen]

NICE!

your .css fixes the issue reported, and solves my issue with the tables.
Will need to do some more testing and clean-up the css files, but I believe this can be part of the next TP version...

Really helpful!

By the way, with this fix I still believe there is a bug in SMF curve2.
https://www.simplemachines.org/community/index.php?topic=581862.0

See example: in Dutch the layout still is broken even @ 390 px wide (in Dutch). I will report that in the other post to the SMF team.

You cannot view this attachment. .

[Antechinus]

Use shorter Dutch words.

[@rjen]

Possible, just not the recommended solution for forum software that is multi language. The strings are in the language files..

[Antechinus]

Yes I know. I was joking.
Although there is always more than one way of phrasing anything in any language. And in the particular situation you'll either need to partially hide long words, or you'll need to break at least one of the inputs to a new line, or use shorter words. Not much else you can do.

[@rjen]

I would suggest that the three fields should not be on one line, but be pushed to separate lines in this case.

And I know it's a small thing only showing up in some cases, but it does show...

[@rjen]

Allright, needed one more addition to take into account the situation where only ONE side panel was showing...

Adding this fixed that too

   /* @900px the sidebars must be pushed to 100% if only one is active */
   .tp_responsive.leftpanelOn  #tpleftbarContainer,   
   .tp_responsive.rightpanelOn #tprightbarContainer {
      width: 100%!important;
   }

By the way, this comment:

/* NOTE: Start by getting rid of these paragraphs, preferably from the template! */
/*
<p class="clearthefloat" style="padding:0px;margin:0px;"></p>
*/

I know we needed these in the past (due to SMF2.0 I think)... I know they are supposedly 'not needed' anymore. Is there a reason these may cause issues? I do not want to risk breaking stuff in SMF2.0 as long as we are still supporting it...