Denis

Homesite 5.2 ? Ça sort d'ou ça ? Je croyais qu'Homesite était passé de la version 5.0 à la 5.5 (ou Homesite+) d'un coup...

Absolument, mais comme nous vivons dans un monde imparfait, il convient d'opter pour la solution la moins imparfaite du lot. Ceci dit, je pourrais me tromper, mais cette propositionest le fruit de mes réflexions sur le sujet. :yuk: Et comment déterminer la hauteur exacte d'une image en pixel en em ?

pile Jamais. Honnêtement, je n'y vois strictement aucun intérêt. Pas plus que mes logs ou mes statistiques d'ailleurs. Ben voilà. Il me semblait aussi que j'avais été clair.

Ce que je dis simplement, c'est : si tu peux tout coder en strict, fais-le et essaie de suivre ces règles là au mieux de tes capacités... au pire tu obtiendras quelques erreurs, toutes reliées à l'utilisation de l'attribut target. Quand tu seras prêt, tu balances en doctype transtionnel et bingo, pas d'erreurs, avec un code qui respecte autrement le doctype strict. Et le jour ou tu parviendras à convaincre qui que ce soit que les nouvelles fenêtres, c'Est mal et que tout ce qui les sépare du strict c'est cet attribut, ils voudonrt peut-être passer de l'autre côté.

Malgré tous les commentaires fort instructifs et pertinents, je crois que le tout se résume à une chose... strict ou transitionnel, l'un est aussi valable que l'autre... et ce, autant en HTML qu'en XHTML. Pourquoi se poser des questions ? L'attribut target est incontournable ? Transitionnel, c'est tout. Cela n'empêche aucunement le concepteur de coder comme s'il faisait du strict et de se permettre uniquement une entorse en utilisant l'attribut target... au coût de la mention Strict, qui semble si chère aux yeux de tous ceux qui se mettent à coder selon les normes.

Je me range du côté de Steph également, que je salur au passage. Puisque par défaut, les configurations de Jaws ne prennent pas en compte le title pour aucun élément HTML sauf les frames, il vaut mieux conserver des libellés significatifs, quitte à changer l'organisation des hyperliens comme il l'a proposé. Par contre, il existe une manière facile de contourner positivement ce "problème". Plutôt que d'utiliser un lien texte, tu pourrais créer une image (ex. : pour lire la suite) et mettre l'équivalent textuel de ton title dans un alt... à ce moment, Jaws et les autres synthétiseurs vocaux le liraient parfaitement. Le mauvais côté de cette technique par contre, c'est évidemment qu'en mode de grossissement du texte, les images elles, demeurent petites et peuvent occasionner des difficultés de lecture pour certains utilisateurs... Comme quoi qU'il n'y a pas de solutions miracles...

Toi, moi et bien d'autres sommes passés par le même chemin... pour finir par revenir sagement au XHTML 1.0 strict. Je crois bien que même ici sur le Hub, de telles réflexions sont bien archivées, dissimulées maintenant sous des mois et des mois de poussière de discussions. Pour la forme (et parce que je n'ai pas envie de faire la recherche dans ce qui me semble beaucoup trop de sujets), je reposte ici le bout de code que j'utilise pour passer le bon mime type aux navigateurs et qui ressemblent un peu à celuique tu nous a présenté. Par ma part, je le dois à Vincent Robert (http://genezys.net/) et Hadrien Nilsson (http://www.psydk.org/), qui passent parfois par ici mais que je n'ai pas le bonheur de croiser souvent : //Indique un Mime type correct si le client accepte du vrai xhtml if( stristr($HTTP_SERVER_VARS["HTTP_ACCEPT"], "application/xhtml+xml") ) { header("Content-type: application/xhtml+xml"); echo "<?xml version='1.0' encoding='iso-8859-1'?>\n"; } else{ header("Content-type: text/html; charset=iso-8859-1"); } ?>

Ah, ça par contre, c'est une toute autre chose. Du coup, j'en vois toute la pertinence. Dans la mesure où les gens comprennent la valeur ajoutée de ce que tu leur proposes, il y a de bones chances qu'un faible pourcentage la téléchargera. Par contre, l'autre mise en garde demeure : même si le tout peut être optimisé avec cette police, il importe de t'assurer que tout est nickel pour la majorité qui elle, ne prendra quand même pas la peine de le faire. En fait, un simple compteur sur le téléchargement du fichier pourrait faire l'affaire et t'indiquer concrètement si oui, les gens la téléchargent... par contre, sur la manière d'implanter ce fameux compteur, faut demander à quelqu'un d'autre... moi mon rôle pour ce genre de trucs, c'est l'idéation, pas la conception! C'est toujours un plaisir de les offrir quand elles sont aussi bien reçues.

Oui, absolument, si tu tiens à respecter les normes. Cependant, considérant ta question (et avec tout le respect que je te dois), je te propose de ne pas t'y arrêter tout de suite, car le type d'information que cela sous-entend est probablement trop avancé pour le moment. Il faudrait commencer par les bases pas tout de suite parler de subtilités techniques. Encore là, c'est une quesiton de travailler ou non en harmonie avec la norme HTML. La méthode que je te propose est conforme à la norme édictée par le W3C alors que la méthode qui t'est générée est, au mieux, conforme aux visées propriétaires de Macromedia et, au pire, incapable de fonctionner de manière interopérable d'un navigateur à l'autre... Puis-je humblement te proposer quelques lectures pour commencer à creuser ces questions ? Sans ces bases, aucunes des explications que je pourrais te donner ne feront sens. Débute par parcourir tout openweb, mais si tu ne devais que lire un seul article, parcours celui-ci : http://www.openweb.eu.org/articles/pourquoi_standards/ Ensuite, pour bien enfoncer le clou, je te proposerais celui-là : http://www.cybercodeur.net/weblog/presenta...dwws/index.html Une fois ces éléments couverts, je pourrai mieux répondre à tes questions.. mais tu pourras probablement y répondre toi-même, ce qui est encore mieux, non ? Bonne lecture, tu verras, c'est passionnant !

C'est un gros minimum... car les intros en Flash n'amènent généralement rien à l'utilisateur, qui s'empresse de les sauter au plus vite. Et qu'est-ce qu'une intro Flash, sinon l'envie d'en mettre plein la vue ? Au moins si la dévelopeur concède le cookie pour ne pas avoir à la vivre à chaque fois, il me semble que la propension narcissique est un peu amoindrie...

Tout à fait... ne conserver que les images significatives dans le code et reléguer tout le reste dans la CSS serait une bonne pratique à instaurer. ouais! +1 J'ignore si tu tiendras un log sur le téléchargement, mais je serais bien curieux de savoir le pourcentage de gens qui prendront la peine de télécharger une police JUSTE pour consulter ton site comme toi tu le vois... Au minimum tu te dois de t'assurer qu'avec des polices plus répandues, le tout demeure parfaitement nickel.

MDR ! Le moins que l'on puisse dire les mecs, c'est que vous savez vraiment accueillir un nouveau ! Bienvenue parmi nous CarGoZ, tu verras, nous sommes, malgré les apparences, très accueillants et gentils ici.

Vraisemblablement : http://www.dhammadana.org/polices.htm Pour l'accessibilité, ça me semble quand même pas mal. Peut-être un petit lien d'échappement en haut de fichier pour passer par-dessus les très longs menus ?

Les deux framesets que tu présentes sot différents l'un de l'autre... et ne présentent pas la même réalité. Pourquoi faire un frameset à deux cadres si tu n'en utilises qu'un seul ? Aucun intérêt, du moins, à première vue. Par contre, si tu as besoin de deux cadres, voici comment le faire de manière conforme et accessible : <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"> <head> <meta http-equiv="Content-Type" content="text/HTML; charset=iso-8859-1" /> <title>Votre titre</title> </head> <frameset rows="100,*"> <noframes> <body>Contenu pour les navigateurs ne supportant pas les cadres</body> </noframes> <frame src="entete.htm" name="entete" title="Zone d'entete" /> <frame src="contenu.htm" name="contenu" title="Zone de contenu" /> </frameset> </html> Et tout le reste (frameborder, framespacing, etc.), hop, dans la CSS

Oh, erreur ! Je réalise que c'est tout le contraire... la méthode de Dudu était la propriétaire, pas la conforme... Qu'à cela ne tienne, l'information dispensée par Loïc sur XHTML.net est bel et bien la bonne.

Cette page, je crois, vous permettra de comprendre pourquoi IE fait des siennes : http://www.xhtml.net/xhtmlcss/favicon En gros, il existe deux méthodes pour intégrer un favicon, la méthode standard et la méthode propriétaire. Comme Dudu a été assez gentil pour nous présenter la méthode conforme et que MSIE est assez égal à lui-même pour ne comprendre que la méthode propriétaire, il est normal que de bien coder le favicon ne marche pas avec IE.

Amen. Et oui, certains ne voudront jamais rien entendre du gros bon sens. Au final, si le client insiste pour investir son argent dans un puit sans fond, se fermer des portes et limiter son public, tant pis pour lui.

Pourquoi ne pas se limiter à considérer la chose uniquement en terme de valeur ajoutée du format pour le site Web ? Si Flash apporte quelque chose de plus, sans pour autant diminuer l'accessibilté du site, pourquoi ne pas le considérer ? Ce ne devrait pas être un conflit entre les uns et les autres, mais bien une prise de position, basée sur la pertinence de l'outil pour un besoin précis.

On peut voir un peu de code ?

Il y a de ces sites qu'on oublie, et qu'on aurait avantage à se tatouer dans le front. Dès que j'ai terminé de me taper sur les doigts, je le fais remonter dans ma (trop profonde) liste de favoris et je ferai quelques tests pour voir. Merci Sibelius, toujours aussi efficace.

Il y a un bout de la motivation initiale qui m'échappe... Pourquoi voilour chercher une solution paliative pour les lens d'évitement ? Est-ce pour éviter d'avoir à les rendre visible, tout en haut dans les pages ? Nonobstant la discussion actuelle, quelle est ta motivation initiale t'amenant à te questionner là-dessus ?

Tiens, tiens, c'est un truc auquel je n'ai jamais pensé ça, et que je n'ai d'ailleurs jamais remarqué sur aucun site Web... il y a des gens qui utilisent vraiment cette extension ? C'est pertinent ? En quel cas ? Lorsqu'on sert le XHTML comme du application/xhtml+xml ?

<link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" /> En déposant l'image à la racine de ton site et en utilisant la syntaxe proposée par Dudu, tu devrais la voir apparaître (quelques virils crtl+f5 auront raison d'une cache récalcitrantes).

Non, non. non, pas du tout Voici un bilet rédigé par Roger Johansson sur VoiceOver : http://www.456bereastreet.com/archive/2005...ing_on_the_mac/ Ça semble vraiment très bien !

Et bien, on dirait que personne n'a eu l'occasion de tester. Faudra réellement le mettre en branle, ce fameux club des oubliés Dudu (et Arlette)... les fans du Mac n'ont pas l'air très nombreux sur le Hub.