Denis

Hum... comme j'ai l'impression d'avoir été mal compris, je vais tenter de me reprendre... tout en essayant de mettre certaines choses en contexte. Non, je ne crois pas que tu sois une utilisatrice idiote... et je n'ai jamais souhaité l'insinuer pour toi ou personne. C'est bien tout le contraire que je voulais dire lorsque j'ai abordé le sujet... justement, la tendance générale en Web, c'est d'assumer que les utilisateurs sont des débiles profonds qui doivent toujours être pris par la main, qui n'ont aucune initiative et qui sont incapables de comprendre quoi que ce soit s'il n'y a pas une grosse flèche clignotante en néon qui pointe dessus. Demandez-le à n'importe quel designer qui croit que la vision qu'il insuffle à un design devrait être rapportée fidèlement à tous les internautes de la terre... Que tu ne connaisses pas une cetaine fonctionnalité d'un outil que tu utilises quotidiennement ne fais pas de toi une idiote... ça fait simplement de toi quelqu'un qui n'a pas fouillé son outil autant qu'un autre. Un utilisateur a d'ailleurs tous les droits de ne pas utiliser à fond ses outils... Généralement, c'est par la frustration et l'impression d'insatisfaction que de telles découvertes se produisent... à force de souffrir d'une situation, on finit par vouloir la régler. En fait, il ne faut pas mélanger les choses, ce n'est pas le standard qui permette ce contournement. C'est encore une fois l'esprit créatif (pour ne pas dire tordu) du premier qui a songé à une entourloupette pour faire en sorte que le validateur ne puisse détecter l'erreur. C'est la culture du hack à sa plus simple expression. Le standard qui permet l'ouverture d'une nouvelle fenêtre sur un clic, c'est le (x)HTML transitionnel, qui permet l'utilisation du target="blank". Ceux qui persistent à utiliser cette combinaison d'attribut et de valeur devrait s'assumer et s'en tenir au transitionnel et non pas feinter le validateur dans un contexte de DTD strict... car c'est effectivement ce qu'ils exigent, du transitionnel. Mais "malheureusement", comme c'est cool de faire du strict certains personnes préfèrent tordre la règle pour y arriver quand même. Si l'objectif du strict est si important, alors il faut jouer par les règles et accepter tout ce que ça implique. Ça aussi c'est très symptomatique de l'industrie du Web ou l'on considère qu'être créatif, c'est savoir enfreindre les règles, c'est réfléchir en dehors de la boite, le fameux "think outside the box" des américains... enfin, je vous épargne mon opinion sur le sujet, question de ne pas blesser qui que ce soit. Mais pour moi, être créatif, ce n'est pas ça du tout. Je crois qu'en général, les gens ici sont à la fois courtois et respectueux des opinions des autres. C'est d'ailleurs un aspect très important sur lequel nous nous appuyons comme modérateurs. Mais quand on a le courage de ses opinions (surtout lorsqu'elles divergent de la ligne), il faut aussi avoir le courage de les assumer et les défendre quand quelqu'un les remet en question. Comme je disais plus haut, passe en XHTML transitionnel et tu pourras utiliser uatnat de target="blanks" que tu voudras... tout en étant 100% conforme à la norme que tu mets en application. Le fait que ce soit difficile à expliquer à un client n'en fait pas quelque chose de totalement invendable, ça em fait juste quelque chose de difficile à expliquer. Mais avec les bons arguments et une certaine ouverture d'esprit sur une nouvelle façon de voir le Web, c'est tout à fait faisable.

Sans être un expert reconnu mondialement sur la question, je pense que l'utilisabilité, l'ergonomie, l'accessibilité ou le simple gros bon sens, issu de bonnes pratiques ou de recommandations ne devraient jamais prétendre à prendre qui que ce soit en charge, indépendamment du niveau de compétence prescrit ou requis. Au contraire, la force de ces pratiques c'est de justement offrir une certaine assurance que l'expérience de navigation ou d'acculturation au site web pourra être pleinement satisfaisante, voire même recommandable à autrui, et ce, sans le moindre à priori ou sans le moindre critère de débrouillardise. Agir autrement, c'est perpétuer le mythe que l'utilisateur est un idiot qui ne connait rien à rien et qui doit toujours être pris par la main pour quoi que ce soit. C'était une pensée condescendante très répandue par le passé qui heureusement, tend à disparaître de nos jours au profit d'une ouverture d'esprit de la part des créatifs et autres professionnels du domaine. Offrir la chance à l'utilisateur de faire preuve d'initiative, dans un contexte clair et déterminé permet justement de transcender ce mythe, tout en accordant à l'utilisateur la chance de progresser dans sa prise de conscience de ses propres compétences (et limites, par la même occasion). C'est lui ouvrir toutes grandes les portes, lui laisser des choix, lui donner le droit de prendre des décisions, même si celles-ci ne sont pas toujours souhaitables... En un mot, c'est le laisser apprendre, parfois à ses dépends, pour en faire un meilleur internaute par la suite, quelqu'un qui sera de plus en plus apte à faire des choix éclairés. Bref, c'est remplir notre rôle de professionnels qui en partie, consiste à éduquer nos clients pour en faire des consommateurs plus avisés... pas seulement à leur enfoncer nos sites Web dans la gorge.

Sans compter que de plus en plus d'utilisateurs sont conscients du pouvoir de choix dont ils disposent et sont de moins en moins enclins à accepter d'être tenus captifs sur un site Web.

Note à moi-même, ajouter Sylvain Trovalet à la liste des gens qui comprennent le Web...

Considérant la nature du site, je ne crois pas que Gribouille26 puisse se permettre d'utiliser quelque chose de partiellement buggé dans un navigateur aussi minable euh, je veux dire populaire que Internet Explorer. J'ai un cas semblable sur un projet que je fais actuellement et la seule manière 'efficace' de m'en tirer - c'est-à-dire tirant suffisamment les compromis - était effectivement de passer mon <h3> (parce que dans mon cas, il s'agissait uniquement de h3) en mode inline plutôt que de la laisser en mode block. Dans mon cas, le design voulait qu'ue ligne au dessus du <h3> se poursuive à l'infini, mais qu'un background sous le <h3> se limite au texte... il a donc fallu que je mette mon <h3> dans un div pour a bordure du haut, pour ensuite passer le display: inline sur le <h3> avec les propriétés de background appropriées. En espérant que cette tranche de vie puisse aider un peu...

Il y aurait des questions beaucoup plus fondamentales à se poser avant... comme pourquoi certains agents utilisateurs accusent des trous de sécurité terribles, ou encore, sont incapables de permettre la navigation par onglets ou de bloquer les pop-ups sans surcouche ou barre d'outils supplémentaires, mais enfin... Je crois bien que tout est une question de répartition de responsabilité entre un manque d'intérêts de la part des équipes de développement de navigateurs à finalement implémenter les CSS aural et un manque de support technologique de la part du matériel informatique qui accueillerait ces informations (encore là, relié directement aux équipes développant des outils). Si on est capable d'aller sur la Lune et d'envoyer des petits robots sur Mars, on devrait être capable d'appliquer des règles CSS à travers un synthétiseur vocal ou une ligne téléphonique...

Je dois quand même signaler que je n'y suis pour rien et que c'est Bleizig, dans toute la splendeur de son génie, qui a tout fait.

Honnêtement, je ne sais pas car je n'ai jamais fait l'effort d'analyser la situation à fond. Tout ce que j'ai observé jusqu'à présent, c'est que parfois, le validateur W3C proclame une page comme étant confirme alors que le validateur du WDG relève des erreurs... qui peuvent être corrigées pour obtenir une confirmation de validation dans cet outil, sans impacter négativement le validateur W3C. Rien de scientifique, mais je promets d'y porter plus attention la prochaine fois pour aller chercher une réponse plus fouillée.

Je peux revenir, le temps d'un commentaire ? "Le seul bloggueur à diffuser sur un média purement vocal..." je dois avouer que d'un point de vue purement égocentrique, j'aime bien comment ça sonne.

Tant qu'à la faire navigable uniquement avec la langue, autant la rendre accessible en goût-o-rama... OK, vous fâchez pas, je sors --------> []

En effet, c'est également une préoccupation à ne pas perdre de vue : sans souris, sans javascript, sans yeux, sans mains... les possibilités sont hautement complexes... et c'est ce qui rend le tout si excitant.

Très bonne idée, c'est vrai que c'Est aussi simple que ça. De mémoire je ne m'en souviens plus, je vérifierai avec elle pour voir si c'est le cas (actuellement, comme son site force du winwows-1252 dans les meta, il n'y a aucun overide). Tout à fait. Sans vouloir lui faire de pub, le validateur du WDG a le mérite de vérifier plus d'une page à la fois (jusqu'à 50) et s'avère parfois moins permissif que celui du W3C. Par contre, par réflexe, c'est tout de même avec le validateur du W3C que je travaille le plus souvent.

Mais puisque je vous dit que la même page sur mon serveur validait !

Ben, disons qu'il n'y a pas eu de mal, mais on s'est payé une joyeuse partie de perte de temps, gracieuseté de l'ami Bill...

Il y a TOUJOURS autre chose à mettre dans un <div> !

Dans les exemples présentés plus haut, on parle de pseudo-liens en javascript qui n'ont pas d'équivalence dans le href pour revenir dans l'historique, on parle de pop ups qui s'ouvrent, etc... En intégrant ces divers liens dans un noscript, au moins l'utilisateur aurait un peu de contexte et pourrait utiliser ces fonctionnalités quand même, dans une version purement HTML... Mais évidemment, si d'emblée ces liens étaient présentés en HTML dur et que les popups étaient oubliées pour de simple liens dans une autre page, la question d'un noscript ne se poserait pas...

C'est exactement ce que j'entends par reprendre... les ré-écrire moi-même directement dans l'éditeur HTML pour les remplacer. Nope... justement je suis absolument catégorique, ils avaient tous été corrigés parce qu'en testant la même page sur mon propre serveur, la validation se faisait automatiquement. C'Est ce qui m'a permis d'éliminer le doute sur le fichier pour ramener les accusations sur le serveur directement.

Justement, ce windows-1252... peut-on le considérer comme l'équivalent propriétaire de l'iso-8859-1 ? Tout ceci rejoint furieusement mes questionnements de ce post qui ne semble pas trouver trop de réponses : http://www.webmaster-hub.com/index.php?showtopic=6326

Je suis pas sûr d'avoir tout pigé dans ta question, parce qu'il y a un joyeux bordel d'information là-dedans Par contre, tu trouveras une piste de réponse à ta question ici, si tu cherches effectivement à faire une mise en page en trois colonnes... joues avec ce code et tranquillement les choses s'éclairciront : http://glish.com/css/7.asp Un bon conseil : si tu souhaites passer des mises en page en tableaux aux mises en pages par css, la première chose à faire, c'est d'arrêter de penser traditionnellement, comme nous avons tous appris à le faire. Ne penses plus en terme de contenus imbriqués les uns dans les autres, mais plutôt en terme de morceaux de code indépendants, que tu disposes dans ta page selon un ensemble de règles CSS. Bonne chance !

Bienvenue dans le cl'Hub ! J'espère que tu continueras à apprécier ce forum, il est bourré de gens hyper sympas.

Dans un tel cas, autant supprimer carrément le div id principal...

Oui peut-être, mais le fait d'utiliser un noscript en fin de fichier permettrait tout de même à l'utilisateur de savoir à quoi servent tous ces bouts de javascript dont il ne peut bénéficier, lui permettrait également d'apprendre s'il lui est possible d'utiliser le site quand même dans son état et surtout de se voir offrir une alternative à tous les cas de figure...

En fait, c'est un petit peu plus critique que cela... le simple fait d'avoir un code HTML valide garanti déjà d'un minimum d'accessibilité enviable (texte alternatifs aux images, structure de code bien formée permettant aux technologies d'assistance de s'y retrouver, etc.) Par contre, la validité du code ne garanti en rien que ce potentiel d'accessibilité sera eficace exploité (les alts des images pourraient ne pas être significatifs, le code html, bien que bien formé, pourrait reposer sur n'importe quoi, etc.) La conformité du code est effectivement la base, mais comme dans tout édifice, cette base se doit d'être solide si on veut pouvoir construire dessus à long terme. Et je me permettrai d'ajouter une excellente ressource, du moins celle qui m'a permise personnellement de me faire les dents en accessibilité : http://www.la-grange.net/accessibilite/ Que l'on peut aussi retrouver en version originale anglaise au http://diveintoaccessibility.org/

En fait, c'est que justement, si tu importes ton texte de word par exemple, tes guillemets et autres petits caractères comme les points de suspension seront encodés dans un format qui n'est pas de l'iso-8859-1 (que tu utilises dans tes documents Web). Sans en comprendre beaucoup plus sur la question, j'en sais suffisamment pour pouvour t'expliquer que c'est la raison pour laquelle tu dois les reprendre pour faire plaisir au validateur... qui ne les reconnaît pas pour ce qu'ils sont. Maintenant, à savoir si tu dois aussi faire ce travail de conversion dans tes métatags, je te dirais simplement que dans la mesure ou tu veux bien faire les choses, pourquoi ne pas les corriger là aussi ? Dieu sait ou cela s'avérera critique pour que tes contenus s'affichent correctement.

Bien dit Laurent. C'est vrai qu'encore une fois, on perd de vue l'objectif de cette grande chasse aux sorcières : faire tout propre,propre, propre...