Covertprestige.info (site perso) : avis et bêta-test

Bonjour à tous,

J'ai récemment fait une petite refonte de mon site sur
[lien supprimé car mort + domaine squatté]
C'est un simple blog Dotclear, avec quelques pages statiques (plugin Related, pour ceux que ça intéresse).

J'ai fait cette refonte, légère, pour refléter un recentrage de la ligne éditoriale. L'interface du site n'est pas très représentative du sujet, elle est trop neutre pour ça, mais ça ne me gêne pas. Je ferai peut-être un thème complètement différent une prochaine fois.

J'aurais besoin d'un coup de main pour bêta-tester cette template. En particulier, j'ai noté des petits problèmes avec Internet Explorer 6, liés il me semble au menu flottant (menu du blog et liens). Lors d'un premier test, j'avais des problèmes importants liés au fait que le bloc qui englobe à la fois ce menu et la zone principale de contenu était en overflow: auto; (pour venir englober le flottant, justement). Bugs bien sympathiques avec IE. J'ai donc dû me rabattre sur un méchant spacer pour que forcer la prise en compte du flottant sans utiliser la propriété overflow. Maintenant que j'y pense, il faudrait que je teste avec la valeur hidden…

En plus de cela, j'ai repéré un problème de latence (environ une seconde dans les cas les plus extrêmes) pour la réactivité des liens du menu ainsi que pour les liens de la zone de contenu qui se trouvent en face du flottant. J'ai bataillé avec ce bug pendant une heure, avant de laisser tomber. Puis, en re-testant, le bug était pour ainsi dire invisible (du moins beaucoup moins flagrant). Je suis perplexe. J'ai peut-être oublié un changement de dernière minute qui s'est avéré significatif !

Bref, il y a de l'overflow, un peu de HasLayout, un flottant… plein de choses pour s'amuser. Donc si vous re-constatez ce bug, ou si vous en voyez un autre, faites moi signe !

Sinon, j'ai cru voir un bug avec d'anciennes versions de Gecko (Firefox 1.0, Epiphany, etc.). Une histoire de trait bleu qui apparaît tout en haut de la page. Si vous avez des infos…


PS : le gros bug constaté avec IE lorsque le bloc conteneur est en overflow: auto; m'a fait penser pendant un temps au Peekaboo Bug… Mais il me semble que ça n'était pas le cas (en tout cas, aucune des solutions proposées ne semblait marcher).
Le bug du temps de latence lors du survol des liens était particulièrement visible sur les pages où le menu dépassait la hauteur du contenu.
Modifié par fvsch (10 Dec 2018 - 15:07)

knarf a écrit :
Il existe un petit problème que l'on retrouve souvent au niveau des liens d'évitements.

Contenu:
Si on navigue au clavier on reviens su le premier lien de la page et non pas le premier lien du contenu.

Recherche:
le lien n'arrive pas à la recherche.

J'avoue ne pas être un expert de la question. Je viens de faire un test avec Lynx, et les liens d'évitement marchent bien. Le lien « contenu » amène bien au premier lien de la zone de contenu (en mode liste de billets, ça sera le titre du premier billet de la liste). Le lien « recherche » amène bien au formulaire de recherche.

Par contre, si je passe en navigation clavier avec Firefox, les liens marchent correctement, mais le lien vers le formulaire de recherche ne donne pas le focus à l'input text.

Si je me souviens bien de ma template, il me semble que l'élément ayant pour identifiant « recherche » est le h2 qui précède le formulaire. Tu penses qu'en le plaçant sur le form ou sur l'input, je peux avoir le focus sur le champ de saisie ?

Salut mpop,

<troll>Ba oui mais si tu utilise un vrai navigateur c'est pas du jeu </troll>

IE ce qu'il lui faut c'est une ancre une vraie, enfin même pas parce que si on ne mets pas un href="" à cette ancre il en veux pas.

En plus comme c'est une ancre, utilisation de name qui valide en xhtml mais déprécié.

Mais là ou IE est très fort c'est que tes autres liens ils les accepte il n' ya s que contenu qui foire

Voilà une discussion qui parle et des ancres et du couple recherche/focus.

Position formulaire de recherche + ancre/focus

Jpv parle de ne pas utiliser l'id d'un bloc mais une ancre, donc des fois je sais plus trop quoi penser.

-Il faut pas utiliser de bloc avec une id
-Mais name est déprécié pour l'élément a
-IE prends les id comme il le sent et à tendance à ne pas pas les accepter sur des blocs si une vraie ancre avec name et href="" n'est pas utilisée.
Modifié par knarf (29 May 2006 - 07:10)

Ah oui d'accord. Faut que je jette un œil à tout ça.

À la rigueur, si c'est juste IE, ça ne me gêne pas trop. Par contre, qu'en est-il des lecteurs d'écran ? Il me semble qu'un certain nombre d'entre eux utilise IE à la base. Ont-ils leur propre gestion des liens internes, ou bien retrouve-t-on les mêmes bugs ?

Bugs constatés (et plus ou moins corrigés)
Le menu « Repères », positionné en absolu et avec des puces en images, pose problème avec certains navigateurs :

– Internet Explorer 6 : les puces sont cachées lorsqu'elles sortent du périmètre du div conteneur (positionné en absolu). Solution : l'ajout d'un padding-left au div conteneur évite que les puces sortent du conteneur (elles flottent sur la zone du padding).
– Konqueror et Safari : les puces sont alignées sur une ligne verticale à gauche, alors que le texte est aligné à droite. Bug ou choix d'implémentation différent ? Après tout, cette conception peut se défendre (les li prennent tous la même largeur, et la puce vient se placer à l'extérieur). Solution : pas toucher (c'est un peu moins esthétique, mais ya pas mort d'homme).
– IE Mac : si on ne lui fixe pas de largeur, le bloc conteneur prend 100% de la largeur disponible, bien qu'il soit en absolu. Du coup, les puces viennent se placer tout à gauche. Solution : pas de solution spécifique. Pour la peine, j'ai fixé la largeur du conteneur à 10em, ce qui me donne un décalage entre les puces et le texte relativement important. Bah… je m'attendais à pire comme bug avec IE Mac, donc ça va.

Sur les liens d'accessibilité
En suivant les indications dans le sujet indiqué par knarf, j'ai modifié mon code pour rajouter des ancres (liens avec href vide, id et name). Par contre, j'ai du mal à tester la navigation au clavier. Avec Firefox sur Mac, je n'ai pas trouvé comment naviguer de lien en lien. Avec Safari j'y arrive, mais les liens vers les différentes zones me renvoient parfois au début de la page. Hmm, tout ça me dépasse. J'espère qu'avec un lecteur d'écran ça ira mieux. Avec Lynx, pas de problème.

Juste une chose : j'ai fait le lien suivant pour le lien rapide vers le formulaire de recherche :

<a href="#a-recherche"
onclick="document.getElementById('q').focus();return false"
title="Aller au formulaire de recherche">recherche</a>

Le lien pointe vers une ancre située avant le label, et le javascript donne le focus au champ de saisie (input). L'idéal serait que les deux soient activés, que le navigateur décale la page jusqu'au formulaire de recherche (ancre), et donne le focus à l'input. Bien entendu, seul le javascript est actif (et si javascript est désactivé, on garde un lien normal vers l'ancre). Quelqu'un aurait une idée pour obtenir ce double comportement ?

Pour le bug de la lenteur des liens : oubliez ça, après test sur environnement windows (Win 98 et Win XP), je n'ai pas pu le reproduire. C'était sans doute dû à Linux+Wine+IE6.

contenu interressant niveau design peut faire mieux mais c'est suffisant comme ça