Chasse aux bogues du nouveau style Wikini
Si vous souhaitez nous aider à améliorer le nouveau style Wikini, vous pouvez nous faire part de vos suggestions et découvertes de bogues sur cette page. N'hésitez pas notamment à vérifier la validité XHtml du code et sa conformité accessibilité (avec les outils web en ligne !). Bien sûr il faut pour cela tester la version CVS...
Bugs connus
Nous effacerons au fur et à mesure cette liste, une version CVS n'étant jamais figée.
Version CVS du 2007-01-27
- Opera 9.02 affiche des barres de défilement au lieu ne rien faire lorsque le texte "Vous êtes..." dans le menu "Contribuer" est court (il doit déborder sur la page au survol de la souris s'il est trop long)
- problèmes de marges + les liens longs débordent dans la page des références à une page
- Je le place ici car il fait suite aux modifications pour le nouveau style:
- Notice: Undefined index: show_comments in /var/www/wikinicvs/wikini/actions/footer.php on line 59
- pour le reproduire je me place sur une page interdite en lecture (tout en étant déconnecté) et j'efface les cookies (pour perdre mon identifiant de session) -- DidierLoiseau
Spécial IE (y a-t-il vraiment qq chose de conforme ? ;-) )
- IE7 (argh il faut que je cherche sa version) : problème actuellement sans solution du menu qui ne s'étend pas jusqu'en bas... (j'en ai fait des commentaires sur mon blog... ;-) -- JmPhilippe )
- dans certains cas, la marge négative des titres coupe le texte (cf. http://stephane.aulery.free.fr/wikini/wakka.php?wiki=NouveauStyleProblemeMargeNegative )
- placement foireux des liens dans l'action 'trail' (IE6 au moins)
- zone de texte de nouveau commentaire mal placée (IE6 au moins)
- les champs dans le formulaire connexion utilisateur sont mal placés (IE6 au moins)
Suggestions
Merci de consulter au préalable la section suivante
Ce ne sont pas des bogues !. Voir aussi la dernière section Passer en largeur variable.
- Je trouve que le fond ligné horizontalement n'est pas l'idéal pour le scrolling: quand on fait défilé la page cela provoque un effet de clignotement assez désagréable... Ça n'était pas dans les maquettes ça, si ? -- DidierLoiseau
- Non on avait un fond violet uni, en fait je voulais mettre un fond rayé plus doux mais je n'ai pas pris le temps de creuser. -- JmPhilippe
- que faire avec les titres de page qui débordent de la boîte du titre de page ? (du fait du NomWiki de la page) Diminuer la police ?
- A priori, difficile de savoir si ça va déborder, donc quand diminuer la police ? Par contre une autre solution pourrait consister à découper le titre de la page au niveau des majuscules (insertion d'espaces côté php) et à recoller les morceaux en CSS (espace inter-mots nul), comme l'avait proposé CharlesNepote je ne sais plus où... Quand le titre devient trop long, il passerait donc sur deux lignes (ou plus) -- DidierLoiseau
- C'était la réponse que j'attendais ;-) ! Il faudra alors réutiliser cette fonction ailleurs, l'ActionTrail par exemple. -- JmPhilippe
- Oui. Le mieux serait de définir quelque part une fonction utilitaire qui pourrait être appelée de partout. Cette technique présente également un effet de bord assez avantageux qui est que les moteurs de recherche pourront "voir" les mots qui composent les titres. Cela devient par contre un inconvénient si le titre est mal coupé... (WikiNi serait un des premiers mots affectés...) -- DidierLoiseau
- mentionner les (futures) pages d'aide dans les interfaces de connexion et préférences utilisateur
- il faudrait que les actions "recentchanges" et "recentcomments" (et leur dérivés "recently") aient un rendu plus adapté lorsque l'espace disponible se réduit:
- plus petite marge pour les li
- meilleur agencement des informations affichées ? On pourrait essayer de faire quelque chose qui passe sur deux lignes ou plus sans devenir trop incohérent (actuellement tout saute un peu ce qui faire que d'une ligne à l'autre les mêmes informations ne sont pas au même endroit...), mais comment ?
- j'ai un peu modifié le rendu de ces actions, avis à la population ! -- JmPhilippe
- suppression d'informations inutiles ? (ex.: date à la seconde près, "historique" alors que "hist." suffirait sans doute, les pointillés pourraient sans doute être gérés en CSS)
- les liens ont une couleur un peu trop pâle
- pour ce qui est du "?" ajouté à côté des liens, il ne me semble pas nécessaire de l'imposer dans le code, cela pourrait être ajouté dans le CSS à partir du moment où ce type de lien dispose d'une classe particulière, non ? (par contre évidemment le pb c'est IE de nouveau...) -- DidierLoiseau
- On peut simplement modifier la couleur et mettre une bulle d'aide, le ? sera pour les bons navigateurs ;-) -- JmPhilippe
- Il faudrait un lien vers la visualisation de la page en mode "normal" (/show) lorsqu'on est dans un autre handler, permettant ainsi d'y retourner facilement (même lorsqu'on vient d'ailleurs). Le mieux à mon avis est que le titre de la page soit ce lien. -- DidierLoiseau
- Je ne fait pas le lien entre le LABEL et le INPUT quand ils sont imbriqués, il lui faut impérativement un attribut for...
Ce ne sont pas des bogues !
- les boutons sauver, prévisualiser et annuler sont en bas à gauche de la fenêtre, pourquoi pas au milieu ou à droite ? Parce que si la page déborde de la fenêtre, il y a alors plus de chances pour qu'on ne voit pas tous les boutons.
- Simple réflexion: en position:fixed, c'est par rapport à la fenêtre elle-même qu'on positionne la boite, donc comment cela pourrait-il encore déborder, même en le plaçant au milieu ou à droite ? Je trouve que la solution actuelle ne donne pas vraiment bien vu que les boutons viennent couvrir la zone de menu... -- DidierLoiseau
- C'est bizarre, visiblement dans Firefox 1.5 c'est par rapport à la page en largeur et à la fenêtre en hauteur ! -- JmPhilippe
Passer en largeur variable
Je trouve que dans l'état actuel des choses le style ne s'adapte pas assez (voire pas du tout) aux dimensions du navigateur:
- en 800x600, la page déborde un rien
- en 1024x768, ça passe bien
- en 1280x1024, cela laisse beaucoup d'espace inutilisé sur les côtés et le texte me paraît un peu étroit (écran 17pouces)
- J'ai essayé quelques modifications pour voir ce que ça donne, ça a l'air bien sauf que le menu devient trop large en 1280x1024:
- Dans div#container, définir width: 80%;
- Dans div#page, définir width: 68%;
- Dans div#menu, définir width: 28%;
- Dans div#menu div#search form, définir width: auto; et margin-right: 20px
- Je n'ai pas committé ces changements dans l'attente de votre avis... Au fait en faisant quelques essais j'ai remarqué (sans chercher de solution à ce problème) qu'avec certains paramètres, lorsque le texte passait sous le menu, tout le menu sautait ! N'y aurait-il pas moyen de faire que ce soit le texte qui s'adapte ?
- Le mieux serait d'avoir une capture d'écran parce que j'ai un peu de mal à voir de quoi il s'agit... Pour l'adaptation à la largeur, c'est une question de goûts. On peut très bien imaginer un style supplémentaire (default-fixed) qui ne ferait quasiment qu'appeler les styles de default (ou l'inverse d'ailleurs avec un default-stretch). -- JmPhilippe
- J'ai envoyé une capture d'écran ici (j'ai simplement mis width: 75% pour le div#page - évidemment c'est une valeur volontairement exagérée, mais dès qu'on touche un peu on arrive vite à ce genre de chose il me semble...). Vraiment une question de goût l'adaptation à la largeur ? En principe on ne redimensionne pas souvent, donc l'important c'est que ce soit agréable (ou du moins utilisable) quelles que soient les dimensions (au delà de 800px de large tout de même...), non ? Par contre je ne suis pas pour la définition de deux styles distincts... -- DidierLoiseau
- Ça c'est certainement parce qu'il y a une largeur fixée en em dans le menu, ce qui empêche le redimensionnement en % -- JmPhilippe
- Oui. En fait le problème se pose si par exemple je définis un min-width pour le menu mais que je mets le menu et le texte avec un dimensionnement en %: lorsque la page devient trop étroite, le texte se retrouve derrière le menu et tout saute... -- DidierLoiseau
- Je suis finalement parvenu à faire ce que je voulais, je donne le patch en bas de page: en fait je joue sur le min-width de la page pour imposer que, en basse résolution, la largeur soit de 740px, faisant ainsi pratiquement disparaître les bords. En haute résolution, même si le menu paraît un peu large au premier abord, je pense que ça n'en est pas moins agréable... À noter que ce patch intègre aussi un correctif pour le #footer qui débordait sur la droite en basse résolution, et qui posait un problème de centrage des liens de validation (ce correctif se base évidemment sur les largeurs en pourcentages). -- DidierLoiseau
- Autre solution: fixer la taille du menu et imposer une marge au texte, mais ça risque de ne pas donner bien en 800x600 (je ne suis pas arrivé à le faire). Idéalement il faudrait que le menu ait une largeur minimale et une largeur maximale et qu'entre les deux il s'adapte, et le texte aussi... -- DidierLoiseau
- Oui ça mérite réflexion car il faudrait un menu de largeur fixe et un contenu de largeur variable en fait. -- JmPhilippe
- On ne sait pas faire cela avec les marges ? Ou alors autre possibilité: positionner le menu en float: left avec la page qui vient autour, non ? -- DidierLoiseau
- C'est compliqué car le style actuel supporte le redimensionnement des polices dans une certaine mesure pour l'accessibilité grâce à des largeurs en em. Passer en % rend plus délicat le redimensionnement des polices. Ensuite le menu arrive après le texte dans le Html, toujours pour raison d'accessibilité. On ne peut donc pas le placer à gauche du texte par un float, c'est le contraire qui se passe, le texte est flottant à droite. -- JmPhilippe
- Pour le dimensionnement en %: à première vue c'est ce qu'ils font sur OpenWeb?? non ? Par contre leur design tient mieux le choc avec grande police/faible résolution que le mien. Le problème du mien c'est sans doute d'avoir défini les min-width en em, ce qui n'est certainement pas un bon choix... -- DidierLoiseau
- En tout cas MediaWiki? est dans la même situation, j'ai jeté un œil rapidement ce matin. L'astuce consiterait à allier un width: 100% pour div#page à une marge négative en em faisant de la place au menu... -- JmPhilippe
- Ah mais oui, excellent comme solution ! Plus aucun risque à ce moment là. La seule chose qu'on perd c'est que le menu ne se dimensionne plus selon la largeur de la fenêtre mais ce n'est pas vraiment grave... (sauf peut-être en basse résolution) -- DidierLoiseau
Mon patch pour des dimensions en pourcentages:
- tu as testé sur quels navigateurs ? -- JmPhilippe
- Uniquement sous Firefox 2.0 pour l'instant... Je n'ai pas l'impression que mon code utilise des choses trop complexes, si ce n'est min-width qui n'est certainement pas supporté par IE... -- DidierLoiseau
Index: main.css
===================================================================
RCS file: /cvs/wikini/wikini/themes/default/main.css,v
retrieving revision 1.11
diff -r1.11 main.css
97c97,98
< width: 58em; /* change width and margin: auto to % for a liquid design (adaptive width) */
---
> width: 80%; /* change width and margin: auto to % for a liquid design (adaptive width) */
> min-width: 740px;
106c107
< width: 39.5em; /* use % for a liquid design */
---
> width: 68%; /* use % for a liquid design */
112c113,114
< width: 19em; /* use % for a liquid design */
---
> min-width: 15em;
> width: 28%; /* use % for a liquid design */
123c125
< width: 58em; /* div#container width */
---
> width: 100%; /* div#container width */
256c258
< width: 12em;
---
> width: auto;
258a261
> margin-right: 20px;
451c454,455
< margin: 0 0 0 16.25em; /* div#menu width - some margin */
---
> margin: 0 0 0 28%; /* div#menu width - some margin */
> width: 72%;