When wide tables exist, in the desktop theme there is a horizontal scroll bar that hints the visitor we can scroll left and right. However in the Mobile theme there is no such scroll bar and the wide table view is really not intuitive, with visitors not being aware that the table is wider than their screen width. Could we add a scroll bar for mobile as well?
Discussion about this matter (however regarding only Desktop theme) occurred bere
What do you think @awesomerobot?
This is a good example of where the auto-hidden scrollbars on mobile/touch browsers aren’t great…
Discourse only officially supports Chrome & Safari on mobile, which means we can style our own scrollbar using CSS like ::-webkit-scrollbar (support). Mobile Firefox users would see no change.
I think what I would prefer to do, which would support all mobile browsers, is to add a fade to the right of the table once it gets wider than the content of the post. Then at least there’s a hint to see more even if there’s no explicit scrollbar.
The problem with that is that currently we overflow: hidden anything within .cooked as a bit of a safety so post content can’t break the page layout… so we can’t style overflowed content when there’s no visible overflow.
We might not need to overflow: hidden post content anymore? I’ll take a closer look and see if it’s sane to remove it, and if not I can add a visible scrollbar for webkit on mobile.
If it works but the scroll bar is hidden, that’s good enough for now – I don’t want to turn this into a ton of work. You have a solution @Mr.X_Mr.X
Yes, it’s low priority… but somewhat related to what I was already considering to fix Letters getting cut off to the leftmost in posts
J’apprécie vraiment l’idée de l’effet de fondu, aussi bien sur ordinateur que sur mobile. Y a-t-il eu des changements depuis qui rendraient cela plus facilement réalisable maintenant ?
Est-ce un changement facile @awesomerobot ? Je le soutiens.
En y repensant, l’effet de fondu n’est probablement pas une bonne option ici… cela impliquerait d’ajouter un conteneur avec un arrière-plan en dégradé, ce qui ne fonctionnerait pas bien sur un arrière-plan qui n’est pas d’une couleur unie. Nous utilisons une indication de fondu similaire dans certains autres endroits, mais ce sont généralement des zones moins susceptibles d’avoir un arrière-plan personnalisé (inscription, barre de navigation d’administration).
Je pense qu’il vaudrait mieux forcer l’apparition d’une barre de défilement lorsqu’elle est nécessaire. Pour autant que je sache, le seul inconvénient de cette approche est que la barre de défilement personnalisée ne correspondrait pas aux barres de défilement natives de votre système d’exploitation.
Cela semble être un meilleur compromis que de ne donner aucune indication que le tableau défile horizontalement.
Agh, encore une fois déjoué. iOS 13 a cassé la possibilité d’afficher toujours la barre de défilement… donc cette idée ne fonctionnera pas pour tous les navigateurs comme je l’espérais.
Le remplacement CSS précédent pour forcer l’apparition des barres de défilement sur iOS nécessitait l’utilisation de -webkit-overflow-scrolling: auto;, mais iOS 13 définit -webkit-overflow-scrolling: touch; partout par défaut et ils semblent avoir entièrement déprécié -webkit-overflow-scrolling dans iOS.
Maintenant, sous iOS 15, en route vers iOS 16, les tables larges dans Discourse ne semblent pas s’en mieux sortir sur mobile.
Pour information, la deuxième table dans ce post sur un bug de table extensible est un exemple de table qui échoue sur mobile (et sur desktop) par manque de défilement horizontal.
