LaurentDenis

Ta feuille de style est apparemment générée par un éditeur wysiwyg, FrontPage peut-être ? En tout cas, sa syntaxe est incorrecte, et les navigateurs conformes comme FireFox, Opera... ignorent les règles CSS qui comportent des erreurs. C'est apparemment le cas pour celles concernant tes liens. Avant tout, il faut corriger dans le HTML les noms de classe du type <A class="1"> en donnant à la classe un nom commençant par un lettre: <a class="liens1"> par exemple. Et corriger symétriquement dans la feuille de style les: A.1 {COLOR: #000000; TEXT-DECORATION: underline} en : a.liens1 {color: #000000; text-decoration: underline;} Au passage, le HTML et les CSS s'écrivent en minuscules. Ceci fait, on y verra déjà plus clair pour chercher un éventuel autre bug

Jan, ce que Denis voulait dire, c'est que javascript doit être utilisé avec discernement. Tu résumes d'ailleurs toi-même la règle de base : limiter javascript à des fonctions qui ne sont pas essentielles à l'accès au contenu du site (et proposer une alternative sans javascript si la fonction javascript est vitale). C'est sans doute la raison essentielle du succès original de javascript : compenser (plus ou moins bien) l'absence de traitement côté serveur pour ceux qui n'y ont pas accès (L'autre raison étant de pouvoir obtenir des effets dynamiques sans renvoi de la page au serveur). Mais ne dispense pas d'un traitement côté serveur des données qui seront envoyées sans pré-vérification, lorsque javascript n'est pas supporté ou activé chez le client

Je commence par ta dernière question : tout d'abord, une visite du classique css Zen Garden: The Beauty in CSS Design devrait te donner une idée de ce que permet CSS en matière de design orienté "graphique", sans tableau ni texte mis en image. texte en image et CSS Tu verras que de nombreux effets graphiques sur le texte ne sont pas obtenus avec du texte mis en image, mais avec une combinaison de styles CSS sur du texte HTML, d'images d'arrière-plan... L'un des atouts de CSS est là : pouvoir styler du texte HTML sans retirer ce texte du contenu (en transformant en image). Certes, CSS2 ne permet pas actuellement de faire tout ce qui est possible avec du texte en image, mais il représente déjà un net progrès. Il faut savoir que le texte mis en image pose de sérieux problèmes d'accessibilité quand il est mal utilisé et limite la possibilité d'exploitation du site par des traducteurs automatiques, des moteurs de recherche... Par exemple, Les Outils linguistiques de Google ne traduisent : - ni évidemment un texte en image (puisqu'ils ne peuvent pas le lire); - ni même l'équivalent textuel de l'image donné par son attribut alt (qu'ils devraient pourtant savoir lire et traduire, comme le fait d'ailleurs Babel Fish). Bref, CSS permet de limiter la quantité de texte mis en image, ce qui améliore considérablement l'interopérabilité et l'audience du site... Un site sans texte ? Je t'avoue que j'ai du mal à imaginer un site totalement sans texte Il serait intéressant de poursuivre à partir d'un exemple concret illustrant ce que tu as à l'esprit. l'agencement des images On remplace le positionnement à l'aide de tableaux par le positionnement CSS (là encore, les feuilles de styles de css Zen Garden: The Beauty in CSS Design te donneront d'abondants exemples). Le positionnement n'est pas la partie la plus facile de CSS, d'autant plus qu'on s'y heurte souvent à des erreurs d'implémentation du côté de certains navigateurs, qu'il faut contourner. Je te conseillerais plutôt d'aborder CSS avec les effets graphiques sur le texte (couleurs, arrière-plans, bordures, polices...et texte en image bien utilisé ) pour te familiariser avec cette technique, avant d'aborder le positionnement. Tu trouveras des tutoriels CSS complets chez : - AlsaCréations; - OpenWeb (dont le site tousse un peu ce matin, mais ce sera réparé dans la journée).

Je l'aurais cru également, mais voici une statistique qui m'a surpris : -RSS0.91 : environ 25% -RSS1.0 : environ 50% -RSS2: environ 25% Le tout sur un panel d'environ 50 000 fils...

OpenOffice (logiciel libre opensource) gère l'export au format pdf (sans aucune limitation de nombre de documents ou autres) http://fr.openoffice.org/

Sans trahir le secret professionnel ( ), qu'entends-tu par "mieux construit", ou a contrario, ces "façons à faire fuir tous les robots" dont tu parlais plus haut ? Disons, le B.A.- Ba ? Liens sur la question ? Pour donner le contexte de ma question : dans un monde utopique, futuriste et improbable où toute page produite exploiterait pleinement les possibilités que laisse entrevoir le Web sémantique, et où les moteurs de recherche feraient de même, le travail des référenceurs serait certainement très différent d'aujourd'hui. Mais aujourd'hui, et dans le monde réel, j'aimerais pouvoir comparer : - ce que les référenceurs considèrent comme de bonnes pratiques de conception (domaine que je découvre ici), - les exigences de conception du Web sémantique (terrain plus familier ).

Bienvenue sur le Hub ! Voilà des principes sur lesquels il y a en effet beaucoup à réfléchir, et où on retrouve le problème de l'accessibilité du Web, mais dans le versant utilisateur. En tant qu'enseignant, j'ai eu à faire découvrir à des enfants handicapés visuels les outils d'aides (lecteurs d'écrans, loupes...), le maniements des navigateurs et des applications... avec toujours ce problème que : - le Web est potentiellement une ressource fantastique pour eux, - mais que son apprentissage est passablement ingrat, et long, - et qu'il faut assumer l'imperfection des outils et des sites. A bientôt sur le Hub sur ce sujet ou sur d'autres !

Oups ! Je m'y prendrais à deux fois pour lire, la prochaine fois

Tu trouveras une liste de moteurs de wiki (et de l'aide) ici : http://www.wikini.net/wakka.php?wiki=Charl...illeSurInternet Ma préférence personnelle (pour ce que ça vaut ) va justement à Wikini (logiciel libre sous licence BSD, PHP et MySQL requis) Voir également Crao Wiki, où tu trouveras également de l'aide sur le sujet.

Un effet de zoom sur une image au passage de la souris ? On peut le faire en CSS sans aucun javascript, à partir des techniques exposées dans Les Portes Coulissantes de CSS - Chapitre II. Pour ceux qui voudrait la recette clé en main, je suis justement en train de relire un article à paraître prochainement qui détaille cet effet CSS. C'est très simple, en fait. Désolé de vous aguicher, mais ce n'est pas moi qui l'ai écrit, donc je ne peux pas en dire plus pour l'instant. Je reviens vous donner l'url dans quelques jours

C'est intéressant, tes carrés de chocolat, même si c'est un détail. Tout d'abord, à chacun sa réaction subjective : pour ma part, je les trouve rigolos au début, mais ils m'agacent très vite car ils gènent la lecture. Heureusement, ils ne sont apparemment pas implémentés sur les autres pages du site. C'est un bon point, ça. Ensuite, on est tout à fait dans le bon usage du javascript : des fonctions qui ne sont pas essentielles à la navigation dans le site et à la consultation de son contenu Cependant, ils ont tendance à se figer sur mon écran en cas de navigation à l'aide de l'historique (Opera 7.50 WinXP). Le script me semble dater un peu et devrait pouvoir être amélioré... Enfin, la seule réponse objective que je vois est celle de la norme d'accessibilité WAI : http://www.la-grange.net/w3c/wcag1/wai-pag...tml#gl-movement Conclusion ? - être conscient que ça provoquera une réaction de rejet chez une partie des utilisateurs; - impérativement limiter ce genre d'effet à un très petit nombre de pages (accueil); - surtout faciliter la désactivation de l'effet : indiquer en pied de page par exemple qu'il suffit de désactiver javascript pour s'en débarasser, ou mieux, ajouter un petit script avec un bouton permettant de supprimer les p'tits carrés de chocolat pour ceux qui ne veulent pas / ne savent pas / ne peuvent pas désactiver javascript... Voir des conseils techniques dans http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/...-avoid-movement

Je ne parlais pas de _AT_font-face (parfaitement valide en CSS2) mais de http://www.truedoc.com/webpages/availpfrs/avail_pfrs.htm et de son : <LINK REL=FONTDEF SRC="http://www.truedoc.com/pfrs/AmeriGarmnd.pfr"> Désolé, mon message n'était pas clair faute d'avoir cité celui auquel je répondais (j'ai rectifié ci-dessus).

Pour vous faire une idée par vous-mêmes et comprendre l'histoire tragi-comique des format RSS: - L'excellent "Cours RSS" de FrançoisHodierne, didactique à souhait. - Du même, les deux premiers volets de l'historique : http://upian.net/znarf/carnet/2004/05/HistoireSyndication1 et http://upian.net/znarf/carnet/2004/05/HistoireSyndication2 Pour ma part, je suis le développement d'Atom qui semble depuis peu comprendre l'intérêt de mettre fin à ces querelles et de devenir un standard réel. Et j'en reste au RSS1.0 qui a l'immense qualité d'être purement RDF et surtout modulaire. Mais à chacun de voir [Edit]J'ajoute deux articles très complets pour découvrir RSS : - 2004, l'année RSS ? - RSS ou la syndication de contenu Et un bon site de veille sur l'actu RSS : Point Blog, rubrique RSS

A propos de la technique indiquée dans http://www.truedoc.com/webpages/availpfrs/avail_pfrs.htm , qui n'a rien à voire avec _AT_font-face : Heu... Disons plutôt un truc d'avant l'avant de ce qu'il y avait avant CSS1. C'est une bricole propriétaire conçue pour IE4 et NS4 ! Je cite le What's new de la chose :

Je n'ai jamais testé, mais je crois me souvenir qu'IE exige en outre un format particulier de polices (embedded open type) : http://www.microsoft.com/typography/web/em...ft3/default.htm http://www.microsoft.com/typography/web/em...ft3/weft04f.htm Peut-être est-ce un peu daté.

Au choix : - La spécification WAI en français, certes un peu aride - Les points essentiels de la WAI en peu de mots : - Un classique initiatique pour apprendre l'accessibilité pas à pas : Plongez dans l'accessibilité, 30 jours pour rendre un site web plus accessible - Plus récent et plus synthétique, le Référentiel accessibilité des services Internet de l’administration française (Sans doute le lien à recommander le plus, actuellement) - Et son complément, La grille de 92 critères AccessiWeb Comme validateur, je te recommande Wave (bien qu'il soit en anglais) dont le système de résultats graphiques est très intuitif. Et quelques Bookmarklets pour valider l'accessibilité...

Tss... Pour la peine, tu nous fera 50 lignes sur "IE et le modèle de boîte" Pour mes précautions oratoires sur l'intégrisme standard : tout le monde ne réagit pas aussi bien que toi à cette idée : - qu'une source HTML est une source, rien de plus, sans considération de présentation (puisque les médias qui n'implémentent pas la surcouche de présentation ont leur propre mode de présentation par défaut, voir les navigateurs textes). Une source par défaut, certes, faute le plus souvent de XML en amont. - que la présentation CSS n'est une surcouche parmi d'autre possibles sur le contenu; Allez, je pousse un peu : le balisage HTML n'est lui-même rien d'autre qu'une surcouche primaire sur le contenu. Mais bon, là, je complique un peu) :concrètement, et pour dire le fond de ma démarche, un document se constuit primairement : 1. hors balisage, crayon-papier. 2. en XML Puis il se déploie : 3. en XHTML ou (X)HTML 4. en RSS ou autre mode RDF (FOAF...) 5. en CSS Je vous avais prévenu : intégriste, le gars

Les règles d'accessibilité (qu'on peut considérer plus généralement comme des règles de bonnes pratiques et d'ergonomie) recommandent que le rendu CSS reflète globalement l'ordre naturel du HTML. Un renversement complet pied/tête dans ce sens risque en effet de donner des résultats illogiques sans les CSS. Allez, un petit rappel : on développe son template HTML hors de tout rendu CSS, n'est-ce pas ? (par exemple, dans un navigateur texte) Et après, on fait sa surcouche CSS... Quoi ? Je me fais taxer d'intégriste, là ? J'ai sans doute loupé quelque-chose, mais je n'ai jamais rencontré de problème de cet ordre : Sibelius, as-tu des infos plus précises sur le sujet ? Quels sont les bugs liés au sélecteur * ? Suis très intéressé. Après un preview rapide sous IE5.5, c'était aussi mon impression

Etape suivante, après le doctype : - mettre toutes les valeurs d'attribut entre guillemets ". - mettre toutes les balises et attributs en minuscules. Exemple : <BODY background=images/menu/fond-0.gif topMargin=0 leftMargin=0> devient : <body background="images/menu/fond-0.gif" topMargin="0" leftMargin="0"> ça supprimera déjà une partie des erreurs de validation induite par la balise body incorrecte. Deux autres suggestions : - pour l'accessibilité, mettre des alt="" à toutes les images décoratives (qui ne portent pas un lien, dont on peut se passer quand on n'a pas un navigateur graphique... Pour les autres, veiller à décrire l'image dans le alt, mais tu sembles l'avoir déjà fait pour tes images-liens. - pour l'ergonomie, supprimer les p'tits carrés de chocolats qui gigotent derrière le curseur de la souris

Faire pivoter les lettres de 90° ? Là... je ne vois qu'un texte mis en image (avec son alt).

Curieux... J'avais rencontré un comportement similaire, à cause d'un flottant flanquant une position absolue. Mais je n'ai pas l'impression que ça se reproduise ici. Empiriquement, le problème semble venir de la syntaxe de tes sélecteurs de classe et d'id : tu utilises des tirets (<p class="post-info">). C'est tout à fait valide (http://www.w3.org/TR/html401/types.html#type-cdata), mais IE ne semble pas apprécier : il m'affiche correctement ta page si je remplace par <p class="postinfo"> (et aussi dans la CSS, bien-sûr). Quelqu'un peut confirmer si c'est bien ça ? D'autant plus curieux que le tiret est recommandé comme substitut de l'underscore, lequel pose, lui, des problèmes avérés dans certaines versions de Netscape... http://www.ericmeyeroncss.com/bonus/render-mode.html Conclusion : faire au plus simple et se limiter aux lettres et aux chiffres pour les noms de class et d'id

Du point de vue standard, <object> remplace <embed>... sauf qu'il est mal supporté... devinez par qui ? Le code source de Yan Hixon pour les objets Flash devrait te donner un modèle de départ (en le simplifiant) : http://ln.hixie.ch/?start=1081798064&count=1 Ah ! Il y a un bel article de fond à écrire sur le sujet Sinon, pour l'accessibilité, AMHA : - si le son véhicule un information (chanson avec texte), l'équivalent textuel doit simplement être accessible à partir de la page. Au plus simple, un lien vers une page texte annexe, à moins que le texte ne soit cité dans la page elle-même... - si le son est juste un "tzoing !"... il ne doit avoir aucun équivalent (tout comme une image décorative a un alt="").

Bien vu, Fight ! En ajoutant la question des contenu de pages équivalents ou non selon la langue, c'est en tout cas ce que, moi aussi, j'ai tiré des docs du W3C.

Bah, on aura appris des choses au moins Au passage, Babel Fish tombe dans le même panneau que Google pour les <span style="display: block";>, mais au moins, il traduit le contenu des attributs alt.

Bah, c'était très théorique, ce message : Le text alt sert à donner l'équivalent textuel d'une image lorsque celui-ci peut être bref (80 caractères environs, plutôt moins, de manière à être correctement rendu dans un media limité en longueur de texte comme les tablettes brailles). ça, ça marche et c'est indispensable. L'attribut longdesc sert à donner l'url d'une description plus longue de l'image, dans une page distincte. Mais il est inutilisable à l'heure actuelle, car trop peu supporté par les divers médias. On a donc bricolé le "lien D" : un lien sous la forme <a href="..." title="Lire la description de cette peinture de Van Gogh">D</a> qui doit être placé dans le contexte de l'image. Sauf que... - la plupart des utilisateurs, comme toi, ignorent le sens de ce "D'" énigmatique; - s'il y a plusieurs images sur la page, on obtient plusieurs liens ayant le même intitulé "D" pour des cibles différentes, ce qui pose d'autres problèmes d'accessibilité... Bilan concret : utilisez alt systématiquement pour donner l'équivalent textuel de votre image, ou l'éliminer avec un alt="" si l'image est purement décorative. Le pas essentiel aura ainsi été franchi