Ni l'un, ni l'autre. C'est un choix (mais je me suis pas vraiment posé la question). En général, quand je fais appel au panneau smiley (sur la v3 du moins), c'est pour insérer plusieurs smiley "spéciaux", donc j'aime bien que ça reste ouvert pendant ce temps... Cela dit, dépendant de vos retours, je peux ajouter de quoi fermer le panel automatiquement


Anca> Pour la version mobile, normalement la navbar n'est plus activable en "hover" mais uniquement en "click" comme dans le Bootstrap de base. Ca signifie qu'il ne faudra plus "appuyer" deux fois sur un menu pour le déployer (je suppose que tu avais remarqué ce petit "bug" ?). Je regarde actuellement pour faire en sorte de déplacer le minichat quand les colonnes "s'empilent". Pour l'instant, le minichat est juste caché, pour éviter d'avoir à scroller 500 pixels avant d'atteindre le début de la page. Dans l'idée, ce serait de le déplacer en fin de page, afin qu'il reste accessible mais sans gêner la navigation sur mobile...

[Edité : Bon, à priori, pas vraiment moyen de faire une media-query ou un check-state avec Bootstrap sans ajouter une librairie supplémentaire. J'ai donc modifié 2-3 trucs : en version mobile, le contenu du minichat est caché, et un bouton supplémentaire permettant d'afficher le minichat s'ajoute... Ainsi, le minichat est accessible, mais ne prend pas trop de place sur l'écran par défaut].

Allez, hop, et t'as même un petit nuage de mots-clés pour l'occasion

Bug :
clic sur "voir les nouveaux messages" alors qu'il y en a 21, ça m'emmene sur lexpage.net/board/thread…

(notez le /2/) Alors que dans le comportement spécial du forum de LA lexpage, les messages 10,20,30,... sont présents deux fois. Pour voir le nouveau message 21 en ayant vu le 20 en dernier, il faudrai que je sois sur la page /3/#new .

Le minichat en responsive : une solution méga simple serai d'insérer le chat dans son ordre normal d'affichage, donc à la fin. Actuellement, tu insère en premier dans le dom ta col de droite et tu la push en float right. Si tu inverse ton ordre d'affichage, pas besoin de bricoler ensuite pour la version responsive.
Sinon, en JS (mais c'est crade car pas lié à tes mediaqueries CSS), tu peux faire un truc du genre :

var tailleecran = $(window).width();
if (tailleecran < 480) { 
    // prendre le bloc DOM minichat et le déplacer sur un autre nœud
    $('#minichat').insertAfter('#finContent');
 }

Par contre, si tu fais ça, faut aussi prévoir le retour à une taille écran supérieure (passage du mode portrait au paysage), donc c'est un peu crade, mais si vraiment tu veux le faire ici, voilà !

Tchouclic sur "voir les nouveaux messages" alors qu'il y en a 21, ça m'emmene sur lexpage.net/board/thread…

A noter que le lien sur lequel on clique n'est pas la même adresse que celle qui s'affiche dans la barre. Il y a une redirection afin de "calculer" la page à afficher. Il y avait deux bugs :
- Le premier est que je calcule la position du message demandé. Sauf que le message demandé est le dernier message lu et non pas le premier message non-lu. C'est donc corrigé et cela devrait t'amener sur la page du premier message non-lu.
- Le deuxième n'est pas un bug, mais si on demande à afficher les nouveaux messages, et que le premier nouveau message est en fin de page, et qu'il y a des nouveaux messages sur la page suivante, il va automatiquement rediriger vers la page suivante, et donc le premier nouveau message sera affiché dans "Reprise de la page précédente".

TchouLe minichat en responsive : une solution méga simple serai d'insérer le chat dans son ordre normal d'affichage, donc à la fin. Actuellement, tu insère en premier dans le dom ta col de droite et tu la push en float right. Si tu inverse ton ordre d'affichage, pas besoin de bricoler ensuite pour la version responsive.

J'ai peut-être mal compris, mais je ne pense pas pouvoir faire cela, car le minichat se trouve dans la "sidebar" qui contient également des liens de navigation au sein de certaines sections, et j'aimerai que ces liens de navigation soient affichés juste après le menu sur les appareils mobiles. C'est pour cette raison que je place la sidebar avant dans le code et que je fais un push-right.

TchouSinon, en JS (mais c'est crade car pas lié à tes mediaqueries CSS), tu peux faire un truc du genre :

var tailleecran = $(window).width();
if (tailleecran < 480) { 
    // prendre le bloc DOM minichat et le déplacer sur un autre nœud
    $('#minichat').insertAfter('#finContent');
 }

J'ai testé cela hier, mais malheureusement, $(window).width(); ne tient pas compte de la barre de scrolling de la même façon que le CSS. Je n'ai pas trouvé de mécanisme élégant permettant de détecter quand le responsive met Lexpage en une seule colonne (il y a des astuces et des librairies externes, mais je trouve cela soit lourd, soit inélégant, soit je n'ai pas envie d'ajouter une librairie pour ça). Actuellement, la solution me "plait" : à savoir le minichat est toujours présent, mais réduit.

GuybrushJ'ai peut-être mal compris, mais je ne pense pas pouvoir faire cela, car le minichat se trouve dans la "sidebar" qui contient également des liens de navigation au sein de certaines sections, et j'aimerai que ces liens de navigation soient affichés juste après le menu sur les appareils mobiles. C'est pour cette raison que je place la sidebar avant dans le code et que je fais un push-right.

Le soucis, c'est que les liens de navigation contextuels dont tu me parle ... bah pour le moment ils sont redondants avec ton menu de navigation principal : dans le forum on a :

    Nouvelle discussion

    Discussions actives
    Discussions suivies
    Liste des discussions

    Flux RSS

    Nouveau message
    Marquer non-lue

Flux RSS est peu pertinent pour une navigation mobile (arrêtez moi si j'me trompe), les 3 premiers sont déjà présents dans ton menu, reste les deux derniers.

Dans les billets même remarque, tu as les 4 premiers redondants avec ta navigation primaire, le flux RSS, et une info présente nulle part ailleurs, un bloc de sélection par date (qu'il est important de garder)

Il faut vraiment penser mobile, et pousser vers le haut les éléments importants. Et sucrer le redondant ou l'accessoire. La question est : quand trucmuche sur son applsung Galacphone 28S affiche une page, quelle est l'information centrale de cette page. Le contenu, ou un menu contextuel qui bouffe la moitié supérieure de l'écran ? Ce qui est redondant peut être caché : les éléments redondants dont je te parle sont utiles dans un contexte desktop, ne le sont pas en smartphone, tu peux les cacher sans vergogne. Le minichat doit il être caché par défaut sur un smartphone ? Il est un élément important du site, c'est dommage de le cacher, même à moitié. Doit-il être en haut de la page sur toute page. Là je ne pense pas.

Les outils de développement de FF sont ton ami : shift+f2 et "resize toggle" (ou dans le menu, ça s'appele vue adaptative), et regarde en 360*640 une page, par exemple lexpage.net/posts/archiv… : le contenu n'est pas visible sans jouer de l’ascenseur, et encore on est en début d'année et il n'y a que 2 mois d'archives.

Bug graphique mineur : ajouter un espace après le content du .fa-arrow-left:before (ou une marge, un espace dans ton html, enfin, éviter de coller la flèche au texte) pour ton menu de navigation bas sur cette page-là.

Tchoules éléments redondants dont je te parle sont utiles dans un contexte desktop, ne le sont pas en smartphone, tu peux les cacher sans vergogne. Le minichat doit il être caché par défaut sur un smartphone ? Il est un élément important du site, c'est dommage de le cacher, même à moitié. Doit-il être en haut de la page sur toute page. Là je ne pense pas.

Comme tu l'indiques, ils ne sont pas tous redondants, d'où l'intérêt de garder ce "sous-menu". Ok, sur mobile, c'est moins pertinent d'avoir accès aux deux. Mais ces liens sont contextuels, ils dépendent de la section actuellement affichée, et ne nécessitent pas, pour être utilisés, de naviguer dans les menus (sur mobile, il est nécessaire de cliquer, par exemple, sur "billets", puis sur "liste des billets", alors qu'un simple click sur "liste des billets" dans la barre "latérale" suffit autrement).

L'exemple du RSS est discutable : sur mobile, je préfère de loin avoir accès au RSS facilement, même si cela ne se fait qu'une seule fois, le temps de l'ajouter dans le lecteur...

TchouLes outils de développement de FF sont ton ami : shift+f2 et "resize toggle" (ou dans le menu, ça s'appele vue adaptative), et regarde en 360*640 une page, par exemple lexpage.net/posts/archiv… : le contenu n'est pas visible sans jouer de l’ascenseur, et encore on est en début d'année et il n'y a que 2 mois d'archives.

Ce sont des archives, il me semble que l'utilisateur peut raisonnablement s'attendre à ce que la page débute par ce type d'options. Le contenu en tant que tel dépend à juste titre de la sélection effectuée à cet endroit (sauf le cas "par défaut"). Sur la page de consultation d'un billet (probablement l'action la plus courante dans cette section), il n'est pas nécessaire de scroller pour entamer la lecture.

TchouBug graphique mineur : ajouter un espace après le content du .fa-arrow-left:before (ou une marge, un espace dans ton html, enfin, éviter de coller la flèche au texte) pour ton menu de navigation bas sur cette page-là.

Corrigé, merci !

Améliorations CSS forum responsive (pour faire flotter le texte et pas avoir une col hyper étirée avec du vide à gauche dans les longs posts) :

@media screen and (max-width: 480px) {
.board-message-side {
margin-right: 10px;
}

.board-message-content {
padding-left: 10px;
margin-left: 0;
}
}

Notez que je n'ai plus trop l'habitude du CSS classique, je peux avoir inséré de la syntaxe compass dedans, si je me suis planté, milles excuses ! :)

J'ai pris 480 "comme ça", avec l'habitude de mon propre framework CSS homemade (inspiré de bootstrap, de foundation, de skeleton). Vérifie que ça soit cohérent avec les valeurs de bootstrap.

edit :

Ce sont des archives

Oui, mais j'y arrive via "billet > liste des billets". Je m'attends à voir les billets directement. Je vois une tonne de trucs pour affiner ma recherche, HÉ MAIS MEC JE VEUX VOIR LES VIDÉOS DÉCONNE MOUAH !

Pour le flux RSS : merci, je ne savais pas que ça avait une fonction dans un contexte de mobilité, je ne savais pas qu'il y avait des lecteurs mobile. Merci de l'info. Cela étant, je reste persuadé que cette info a sa place dans un footer, pas dans un header (et je suis fan du RSS pourtant, mais c'est un truc qui sert une fois dans la vie d'un site par utilisateur).

TchouNotez que je n'ai plus trop l'habitude du CSS classique, je peux avoir inséré de la syntaxe compass dedans, si je me suis planté, milles excuses ! :)

Le mec, il se la pète.

Bah quand t'as goûté aux joies des préprocesseurs CSS (avec l'investissement en temps de formation dedans œuf corse), revenir au bon vieux CSS tu peux te planter. J'me la pête pas, au contraire j'annonce que je risque de me planter ! :D

C'est pour, entre autres, ça que je n'aime pas les pré-processeurs.
En revanche, j'aime beaucoup les post-processeurs

Ah, première fois que j’entends parler de post-processors. Concept intéressant. C'est vrai que grunt, yeoman et autres logiciels"hype" ont pas mal révolutionné la fin du workflow récemment (en permettant un watch qui lance concaténation, minification, et en fait tout ce que tu veux).

Après, le soucis c'est que tu n'as plus l'avantage d'un langage de programmation comme peut l'être sass. Exit les boucles, exit les calculs de couleurs, exit tout ce qui en fait le sel. La concaténation, la minification, le calcul de toutes les syntaxes, ça peut se faire en post-prod, pas les calculs générant des class ou une palette de couleur.

C'est hallucinant comme j'ai l'impression qu'il y a eu une accélération impressionnante du nombre et de la qualité des outils de webdev en 5 ans. Faudrai presque révolutionner son workflow toutes les années si on suivait la mode "webdev" ! :)