Atelier Opquast V2 - Fermé

Flux de commentaires

Contributeur Commentaire
Matthieu Blondel 22 September 2011 14:33 Une couleur d'arrière-plan est définie pour chaque zone de texte
Libellé actuel : [Une couleur d'arrière-plan est définie pour chaque zone de texte] L'objectif actuel : [Permettre de conserver des textes lisibles même lorsque les styles CSS sont désactivés.] En lisant l'intitulé actuel, j'ai cru que la BP préconisait de définir une couleur d'arrière plan par exemple "à chaque balise p". En lisant l'objectif, j'ai un peu mieux cerné le problème (enfin... je crois !). Par contre : définir un background même avec les styles CSS désactivé ? pas en html quand même ;-) Je propose : Libellé : [Tous les textes ont une couleur les différenciant du fond sur lequel ils sont affichés.] Objectif : [Permettre de conserver des textes lisibles, sans chevauchement de textes et sans contraste trop faible]
Verschelde Florent 22 September 2011 14:33 Si le site propose un moteur de recherche thématique, un plugin de recherche est disponible
Autres essais: {{Pour chaque moteur de recherche destiné à un usage régulier, le site propose un plugin de recherche pour le navigateur}} {{Lorsqu’un moteur de recherche est le principal moyen d’accès un contenu, le site propose le plugin de recherche correspondant}}
Elie Sloïm 22 September 2011 14:33 Éviter l'utilisation de la propriété CSS "expression".
Dans tes 200 BP de performance client, combien sont elles vérifiables ? Combien sont exclues car ce sont des conseils (optimisez, minimisez, diminuez). A mon avis, il y en a peu qui sont aussi claires que celles-du dessus.
Laurent Denis 22 September 2011 14:33 Keyboard navigation happens in an foreseeable order
Oubli: toute l'astuce est de ne pas imposer l'ordre de tabulation entre les blocs, bien-sûr.
Claire Bizingre 22 September 2011 14:33 Internal and external hyperlinks are differentiated
J'ai lu une discussion à ce sujet sur le forum d'Alsacreations.
Verschelde Florent 22 September 2011 14:33 Si le site propose un moteur de recherche thématique, un plugin de recherche est disponible
Le souci serait de distinguer, dans l'intitulé, les cas où un tel plugin serait pertinent ou pas? Une solution simple mais peut-être trop restrictive: {{Lorsque la fonctionnalité principale du site est la recherche dans un index, un plugin de recherche est disponible}} En gros: si je fais un moteur de recherche (de pages web, de MP3, d'informations sur les communes, de disparus de la première guerre mondiale…), je propose un plugin de recherche. On peut rajouter «dans le code source des pages». Une solution moins restrictive: {{Les moteurs de recherche qui font partie des fonctionnalités essentielles du site sont utilisables via un plugin de recherche pour le navigateur}} Qu'en penses-tu?
Verschelde Florent 22 September 2011 14:33 Lorsque le site invite à utiliser un agent utilisateur spécifique, il identifie cette invitation comme une publicité
D'après discussion précédente, BP à classer dans les Refus. Allez, seulement 32 refus pour l'instant, c'est pas bon ça. :)
Verschelde Florent 22 September 2011 14:33 Éviter l'utilisation de la propriété CSS "expression".
Risques à utiliser cette propriété: - Légère perte de performance. - Donne l'illusion de faire du CSS en copiant-collant un «fix» pour IE6 ou 7 lu dans un article daté, alors qu'il s'agit de JavaScript embarqué, non disponible si JS désactivé. - Code que le codeur CSS ne comprend pas (mais bon, ça c'est le cas d'un peu tout ;)). Donc surtout le problème de perf, pas énorme à ma connaissance. Avantages à ne pas l'utiliser: éviter le problème de perf. Et oui, la performance c'est beaucoup de petites choses. Mais si on met toutes les petites choses en question dans Opquast, on se retrouve avec 200 BP de performances client. N'y a-t-il pas un arbitrage à faire sur quelles «petites choses» sont retenues ou pas?
Claire Bizingre 22 September 2011 14:33 Les styles et contenus dédiés aux terminaux mobiles permettent un rendu sans double scroll
SI l'on reprend les bonnes pratiques du W3C en matière de Web mobile, il est recommandé "d'utiliser, si possible, une alternative à la présentation tabulaire" : http://www.w3.org/TR/mobile-bp/#TABLES_ALTERNATIVES. Le nouvel énoncé proposé est bien : "les styles et contenus dédiés aux terminaux mobiles permettent un rendu sans double scroll"
Laurent Denis 22 September 2011 14:33 Navigation blocks of the same nature are in a consistent place on every page
Tant que, par exemple, des boîtes de navigation contextuelle peuvent raisonnablement se promener là où elles sont pertinentes, pas d'objection.
Laurent Denis 22 September 2011 14:33 Une couleur d'arrière-plan est définie pour chaque zone de texte
Non, il s'agit bien de définir background-color à chaque fois que color est définie. En effet, si une couleur d'arrière-plan n'est pas définie, on peut avoir la situation suivante : * le bloc a un arrière-plan transparent (valeur par défaut de background-color) * par transparence, la couleur de texte est bien quand même "associée" à une couleur d'arrière-plan: celle de l'élément parent, ou de l'élément sur lequel est positionnée la zone de texte. * mais en cas d'agrandissement de la taille du texte, la zone de texte s'agrandit et une partie du texte se retrouve sur un autre arrière-plan, où il n'est plus lisible. Donc, définie et non associée, je pense...
Claire Bizingre 22 September 2011 14:33 Internal and external hyperlinks are differentiated
C'est vrai que lorsqu'on navigue sur un site qui indique les liens externes par un pictogramme de type flèche montante vers la droite, tout de suite on sait que l'on va quitter le site si on clique sur le lien. Avec une image en background en CSS, ça se fait bien. On rajoute la mention lien externe dans le title du lien et/ou directement dans l'intitulé du lien comme on peut le faire pour le changement de langue ([en]) : "projet opquast [externe]" ou "projet opquast (lien externe)". Si on utilise un CMS, il faut qu'il offre la possibilité de différencier les liens externes des liens internes et générer ainsi un code différent. SI on passe par CSS (propriété content) pour compléter l'intitulé du lien, nous invalidons le test [Présentation)1 du RGAA, n'est-ce pas ? Plus un problème de compatibilité avec certains navigateurs.
Laurent Denis 22 September 2011 14:33 Navigation blocks are in a consistent place in the source code of all pages
Pour la seconde question, le positionnements des blocs de navigation par rapport aux blocs de contenu : la seule raison de recommander l'un ou l'autre des ordres menu/contenu ou contenu/menu serait une BP visant spécifiquement les contenus destinés aux mobiles. Selon les termes des Web Mobiles Best Practices (http://www.w3.org/TR/mobile-bp/#cm) : "Ensure that material that is central to the meaning of the page precedes material that is not." Ce qui ne signifie pas qu'un des deux ordres ci-dessus doivent être systématiquement adopté : l'ordre pertinent dépend de ce qui retenu comme "primary content of the page".
Elie Sloïm 22 September 2011 14:33 Si le site propose un moteur de recherche thématique, un plugin de recherche est disponible
Salut Florent, Nous sommes en train de l'examiner. Elle est utile, vérifiable, intéressante et pas mal formulée, mais on ne sait pas définir dans quels cas elle est pertinente. Est-ce que tu aurais des arguments pour qu'elle bascule en candidate et non en recommandation.
Verschelde Florent 22 September 2011 14:33 Le poids des pages est compris entre 50 ko et 100 ko pour les terminaux mobiles
Problématique des terminaux mobiles: si je suis en Wifi sur mon smartphone, ça ne me gêne pas que des contenus lourds soient chargés si ces contenus sont intéressants. Je charge à avoir une expérience proche du desktop, avec éventuellement une mise en page sans colonnes et des médias adaptés au terminal (images pas trop larges). Si je suis sur une connection 3G avec un forfait data illimité, ça ne m'engoisse pas plus que ça les pages de 500ko. Si je suis en edge avec un forfait data qui coute la peau des fesses, effectivement je préfère des pages aussi légères que possible et, si besoin, une censure des contenus trop volumineux (parce que ça revient à ça, hein, des pages toutes légères sur l'ensemble d'un site!). Partant, le site il doit faire quoi? Faire du dépouillé tout léger, et frustrer les utilisateurs de terminaux mobiles qui ont de bonnes conditions d'accès? L'inverse (et donc frustration inverse)? Ah oui: et tout site web sur la planète qui veut suivre Opquast V2 niveau 1 doit faire de la détection de terminaux mobiles? Et les terminaux mobiles qui ont des écrans en 800x480, ça compte aussi? Et puis, et puis… Je vote pour la poubelle.
Verschelde Florent 22 September 2011 14:33 Chaque page possède un titre différent
Il y a une plus-value pour l'utilisateur lors de l'utilisation d'un moteur de recherche (externe mais surtout interne). Cela évite d'avoir des résultats en apparence identique mais donnant accès à des contenus différents.
Elie Sloïm 22 September 2011 14:33 Le design général du site est en cohérence avec son objectif.
Ben là, c'est difficile de la refuser comme recommandation. C'est plutôt pertinent, bien qu'invérifiable. Au moins, ça amène à se poser la question, et c'est d'ailleurs une bonne question. Je pense donc qu'on pourrait la garder. Elle ne fait aucun mal, elle peut même faire du bien. Par ailleurs, je pense qu'on a encore dans les recommandations des pratiques vraiment bidons, c'est à dire : 1 qu'on est même pas sûr qu'on peut les conseiller, 2 que même la reformulation ne nous serait d'aucun secours. En cherchant bien on doit pouvoir en trouver pas mal. Jette au œil aux recommandations, prépare au moins 120 planches, et je t'accompagne au cimetière. D'humeur guillerette, en plus.
Elie Sloïm 22 September 2011 14:33 Éviter l'utilisation de la propriété CSS "expression".
Ah, j'oubliais, il faut une nouvelle reformulation. {La propriété CSS "expression" n'est pas utilisée} Là, ça me semble assez clair
Martin SUPIOT 22 September 2011 14:33 Le code source des pages contient des liens relatifs vers l'auteur, les droits de reproduction, l'accueil et le plan du site
Effectivement, la valeur ajoutée n'est pas pour tout le monde, néanmoins, je la trouve plutôt intéressante.
Claire Bizingre 22 September 2011 14:33 Le poids des pages est compris entre 50 ko et 100 ko pour les terminaux mobiles
Pas de frustration, pas de censure pour ceux qui ont une bonne connexion mais plutôt penser à ceux qui n'ont pas de haut débit (la couverture 3G n'est pas généralisée) et qui souhaitent surfer avec leur téléphone. Penser aussi à ceux qui n'ont pas un super forfait. Si les concepteurs font attention au poids des pages Web, ils vont satisfaire le plus grand nombre. La limite indiquée dans l'énoncé peut paraître excessive. Peut-être ne pas indiquer de limite mais recommander de minimiser le plus possible le poids des pages et tester le temps de chargement sur des mobiles ou des émulateurs en cours de développement. SI l'on consulte les bonnes pratiques du W3C en matière de web mobile, il est conseillé "d'éviter les images volumineuses ou en haute résolution sauf si des informations critiques seraient perdues sinon". Les images participent grandement à l'alourdissement des pages. Par ailleurs, Il est peut-être plus judicieux de prévoir une version spécifique du site pour mobile, de choisir le contenu à afficher et supprimer par exemple les publicités et autres effets. L'énoncé pourrait être : "Le poids des pages doit être le plus léger possible pour les terminaux mobiles" Un contenu léger n'est pas synonyme de contenu appauvri.
Elie Sloïm 22 September 2011 14:33 Navigation blocks of the same nature are in a consistent place on every page
Ne faudrait-il pas mieux dire : {Les blocs de navigation de même nature sont affichés au même emplacement sur toutes les pages}
Laurent Denis 22 September 2011 14:33 Keyboard navigation happens in an foreseeable order
Hum... Toutes les questions de pertinence ne relèvent pas de la subjectivité. Moyens de contrôle : * s'assurer que la tabulation commence par le premier lien ou contrôle affiché dans l'ordre de lecture naturel de la page (ordre de lecture naturel = lecture humaine, en français de gauche à droite et du bas vers le haut) * s'assurer que la tabulation s'effectue dans cet ordre au sein de chaque bloc de navigation, formulaire, bloc de contenu et objet; * s'assurer que la tabulation entre les différents blocs de navigation, de contenu, formulaires et objets se fait dans un ordre cohérent sur les différentes pages du site
Laurent Denis 22 September 2011 14:33 Une couleur d'arrière-plan est définie pour chaque zone de texte
Il serait en fait préférable de revenir à la formulation initiale de la BP: {Une couleur d'arrière-plan est définie pour chaque couleur de texte} En effet: * cela évite d'avoir à définir une notion de "zone de texte" * cela correspond précisément le besoin : définir la couleur de background pour chaque couleur de texte * cela correspond directement aux moyen de vérification (avertissements du valaidateur CSS)
Elie Sloïm 22 September 2011 14:33 Une couleur d'arrière-plan est définie pour chaque zone de texte
je ne comprends pas très bien. Ne doit-on pas dire : {Une couleur d'arrière-plan est associée à chaque couleur de texte} ?
Elie Sloïm 22 September 2011 14:33 Une couleur d'arrière-plan est définie pour chaque zone de texte
OK pour définie je continue : cette couleur doit être : 1 différente de la couleur du texte 2 avoir une différence de contraste suffisante Si la solution technique consiste à vérifier tout ça, ça donne : {Une couleur d'arrière-plan est définie pour assurer la lisibilité de chaque zone de texte}
Laurent Denis 22 September 2011 14:33 Une couleur d'arrière-plan est définie pour chaque zone de texte
Il y a déjà CD-189 {Les contenus sont présentés avec un contraste suffisant par rapport à leur arrière-plan}
Boujo Serge 22 September 2011 14:33 Navigation blocks are in a consistent place in the source code of all pages
Les emplacements relatifs des blocs de navigation les uns par rapport aux autres sont cohérents dans le code source de toutes les pages. ou Les emplacements relatifs des blocs de navigation les uns par rapport aux autres sont cohérents dans le code source de toutes les pages ; leur position dans le code source reflètera leur organisation dans la page visible par l'utilisateur. --- J'alourdis la formulation parce que je pense que c'est le prix à payer pour évacuer les incertitudes. --- Parler des positionnements des blocs de navigation par rapport aux blocs de contenu serait : - redondant ? - pousser le bouchon trop loin ?
Laurent Denis 22 September 2011 14:33 Navigation blocks are in a consistent place in the source code of all pages
La précision apportée par la seconde proposition de reformulation ("leur position dans le code source reflètera leur organisation dans la page visible par l'utilisateur.") est couverte en partie par la BP CD-134 "La navigation au clavier s'effectue dans un ordre prévisible.sur l'ordre de tabulation". Typiquement, une navigation en fin de code source propulsée via CSS en tête de page (exemple Wikipédia) est invalidée par BP CD-134. Mais si tabindex est bien exploité, BP CD-134 est validé. La position du menu dans le code source par rapport à l'affichage reste-elle alors un problème ?
Elie Sloïm 22 September 2011 14:33 Calls to external scripts are put after the content
Tu as des exemples de cas où ce n'est pas possible et/ou intéressant? Sinon, ils vont aller dans les solutions de mise en oeuvre.
Nicolas Hoizey 22 September 2011 14:33 Calls to external scripts are put after the content
Je ne retrouve pas d'exemple concrès, mais cette recommandation assez courante a ses détracteurs : http://developer.yahoo.net/blog/archives/2007/07/high_performanc_5.html Je ne serais pas fâché si la formulation initiale est conservée, pas de soucis... ;-)
Verschelde Florent 22 September 2011 14:33 Words do not bear any internal space or markup
Laurent évoquait une utilisation abusive de SUP et SUB, lorsque des caractères Unicode sont disponibles. Peut-on avoir des exemples? Est-ce que <abbr title="numéro">n<sup>o</sup></abbr> est concerné, par exemple?
Verschelde Florent 22 September 2011 14:33 L'interlettrage n'est réalisé que via les styles CSS
Il y avait proposition de regrouper cette BP avec la BP 334 («Les mots ne comportent pas de balisage interne»), vu qu'il s'agit d'interdire des pratiques proches (mise en forme typographique au burin) qui posent un même problème. Ce n'est pas souhaitable et il vaut mieux traiter chaque cas séparément?
Verschelde Florent 22 September 2011 14:33 Le design général du site est en cohérence avec son objectif.
Comme BP, c'est impossible car non vérifiable. Comme recommandation, c'est excessivement vague. Je prépare six planches.
Verschelde Florent 22 September 2011 14:33 Si des images sont générées dynamiquement et réutilisée ultérieurement, préférer créer et utiliser le fichier pour les fois suivantes
Idem. De plus la valeur ajoutée pour le visiteur est faible. Au mieux, c'est pour gagner deux secondes sur le temps de chargement d'une page lorsque l'utilisateur demande un traitement. La vraie valeur ajoutée concerne plutôt les admins serveur, vu qu'il s'agit d'éviter une charge serveur inutile.
Verschelde Florent 22 September 2011 14:33 Le nombre d'éléments présents dans le DOM est inférieur à 1500.
Mes commentaires et questions: 1. La limite de 1500 semble trop basse pour certains usages légitimes (longue liste d'éléments, où chaque item comporte plusieurs éléments). 2. Les limites chiffrées, c'est toujours casse-gueule même si parfois ça marche. Là, je suis pas sûr que ça marche. 3. Quels sont les outils qui permettent de vérifier cette recommandation? Quelle est leur complexité? 4. N'est-ce pas une recommandation d'optimisation des performances client un peu trop pointue pour le scope d'Opquast?
Elie Sloïm 22 September 2011 14:33 Lorsque le site invite à utiliser un agent utilisateur spécifique, il identifie cette invitation comme une publicité
Ouais, c'est vrai que bon : Morte, donc.
Verschelde Florent 22 September 2011 14:33 Éviter l'utilisation de la propriété CSS "expression".
Pour rappel, les expressions CSS (mécanisme propriétaire) ne sont pas supportées dans IE8, comme annoncé ici: http://blogs.msdn.com/ie/archive/2008/10/16/ending-expressions.aspx Je suis ok pour interdire le recours à la propriété expression. Pour les cas d'usage existants, la solution technique privilégiée devrait de toute façon être le recours à JavaScript, avec un script en bonne et due forme (ce qui laisse plus de latitude pour faire les choses bien…). Et comme c'est vérifiable facilement, ça peut faire une BP plutôt qu'une recommandation. Par contre, je me demande si ce n'est pas trop un micro-détail pour une inclusion dans Opquast?
Elie Sloïm 22 September 2011 14:33 Éviter l'utilisation de la propriété CSS "expression".
"je me demande si ce n'est pas trop un micro-détail pour une inclusion dans Opquast?" Quels sont les risques à utiliser cette propriété ? Quels sont les avantages à ne pas l'utiliser ? Je crois que c'est pour la performance, et donc, oui, direction les candidates, car la perf, c'est beaucoup de "petites choses".
Martin SUPIOT 22 September 2011 14:33 The site provides users with a way to know about new contents and services
Tout à fait d'accord. Ca va dans le bon sens. Est ce qu'il ne faut pas aussi préciser sur le site quel est moyen de se tenir à jour ?
Martin SUPIOT 22 September 2011 14:33 Les styles et contenus dédiés aux terminaux mobiles permettent un rendu sans double scroll
Je suis bien d'accord sur l'idée de na pas faire de double scroll ! La formulation me semble meilleure.
Martin SUPIOT 22 September 2011 14:33 The current step in a process is indicated
Très bien aussi !
Nicolas LE GALL 22 September 2011 14:33 Le nombre d'éléments présents dans le DOM est inférieur à 1500.
Mes « réponses » : 1. C'est toujours le problème des limites, suivant les contextes c'est trop, parfois c'est pas assez… Je ne saurai absolument pas quoi fixer comme limite. Cette BP est basée sur une règle de Yahoo : http://developer.yahoo.com/performance/rules.html#min_dom, j'imagine qu'ils ont essayé de faire une moyenne (notamment avec les terminaux mobiles qui sont limités en mémoire). 2. Je suis assez d'accord, mais je pense que cette BP peut être un bon moyen pour se forcer à optimiser son code HTML. Ça t'es déjà arrivé de te dire de faire moins de markup pour des raisons de performance :) ? 3. Dans une console (Firebug, Dragonfly, etc.) : document.getElementsByTagName('*').length ça ne me semble pas trop PITA. 4. Je ne saurai répondre. Il me semble qu'Opquast va faire une liste spéciale performance (qui, vraisemblablement, sera surtout des recommandations :) ).
Elie Sloïm 22 September 2011 14:33 Keyboard navigation happens in an foreseeable order
Pour moi, elle est importante, mais éminemment subjective. Si on trouve des moyens de contrôle solides, je dis oui, sinon, recommandation.
Elie Sloïm 22 September 2011 14:33 La possibilité d'envoyer un formulaire à l'aide de la touche entrée n'est pas altérée.
Je n'en suis pas vraiment fan non plus. A mon humble avis, elle va sauter.
Elie Sloïm 22 September 2011 14:33 The server sends a personalised 403 Not allowed error page
Il me semble que cette bonne pratique n'est pas toujours nécessaire. Certains sites peuvent décider de ne pas interdire de répertoire. Dans ce cas, il vaudrait mieux reformuler de la façon suivante : {Si la consultation du contenu d'un ou plusieurs répertoires est interdit, le serveur envoie une page d'interdiction 403 personnalisée.}
Elie Sloïm 22 September 2011 14:33 Le site ne change pas la page d'accueil par défaut de l'utilisateur sans son consentement.
Cas rare, valeur ajoutée limitée selon moi, à dégager en recommandation. Non?
Matthieu Blondel 22 September 2011 14:33 Real dimensions of images are indicated in the source code
Libellé discuté : [Les dimensions réelles des images sont indiquées dans le code source] Pas de mise en oeuvre, pas d'objectif pour l'instant. En tant que développeur je ne vois que des inconvénients à faire cela : - A chaque modification de la taille d'une image, il faut retoucher le html. - ... A moins de le faire par le script, ce qui génèrera des accès disque pour chaque balise image, ou des accès en base de données. - Si on "oublie" de retoucher le html, alors l'image sera déformée. (Ca sent le vécu...:-) ) Quels sont les avantages / public concernés par cette BP ?
Martin SUPIOT 22 September 2011 14:33 Real dimensions of images are indicated in the source code
Le navigateur peut commencer à exécuter le rendu plus tôt si il connait la taille de l'image. Il n'est pas obligé de la calculer. Cela augmente la vitesse d'affichage ressentie par l'utilisateur
Laurent Denis 22 September 2011 14:33 Real dimensions of images are indicated in the source code
Voir http://www.w3.org/TR/mobile-bp/#ImageSize (c'est une BP du Web mobile)
Elie Sloïm 22 September 2011 14:33 Si le site propose un moteur de recherche thématique, un plugin de recherche est disponible
{Les sites dont le moteur de recherche est un moyen principal ou obligatoire d’accès aux contenus proposent un plugin de recherche} Voilà ce que je ferais, en niveau 3, c'est un pari sur une techno, j'aime bien, maintenant, j'ai besoin du regard de Fabrice. Dans le cas contraire, elle ira dans les recommandations (dont le nombre va considérablement diminuer). Merci Florent