LaurentDenis

Tous les caractères quels qu'ils soient sont encodés, quelque-soit leur forme. C'est évident quand ils sont sous forme numérique (& #233;) ou entité caractère (& eacute;). Mais c'est aussi le cas quand on saisit directement la lettre (é). Sous Windows, bon nombre d'éditeurs de texte, à commencer par Word, utilisent pour certains caractères un encodage différent des normes (ISO, UTF-8...) admises sur le Web. Cet encodage s'appelle Windows-1252, et c'est lui qui est responsable des problèmes posés par les guillemets doubles, l'apostrophe Word et autres.

Heu... Il n'y a pas de <noscript> sur un lien du type <a href="" onclick="window.open(this.href, '...'); return false;">...</a>. En l'absence de javascript, l'attribut onclick est ignoré, et le lien est simplement disponible comme un lien classique.

Hum... Diverses propriétés sont inutiles. Pour #topmenu: - clear ne sert à rien puisque cet élément n'est précédé d'aucun flottant - left et top sont inutiles, l'élément étant en flux et non pas positionné. - le list-style-type peut être plus simplement appliqué directement aux <li> Pour #principal: - le float est inutile : cette div sera en flux faute de largeur spécifiée. Ce qui donne plus simplement: body,html { margin: 0; padding: 0; } #topmenu { background-color: #000000; height: 5em; width: 100%; margin: 0; padding: 0; } #topmenu li{ float: left; margin-right: 1em; color: #FFFFFF; list-style-type: none; } #menu { width: 10em; float: left; background-color: #FFFFCC; } #principal { }

Tout le contenu d'un document Web doit respecter l'encodage spécifié pour celui-ci, que ce contenu soit affiché ou non. Dans tous les cas, il est destiné à être exploité par une machine ou une autre, et celle-ci peut "butter" sur un caractère mal encodé. Donc les <title> et autres <meta>, <link>... : - ne doivent pas être copiés-collés directement depuis un logiciel tel que Word qui utilise un encodage incompatible avec le Web - n'ont pas besoin d'être encodés en entités caractères ou numériques pour autant que ton éditeur HTML génère le bon caractère - ne risquent rien à être encodés en entités numériques en cas de doute.

Non, ce n'est pas ça. - le HTML validator ne vérifie que la conformité de ton code HTML avec la grammaire HTML: utilisation de balises prévues par une des normes (X)HTML, syntaxe correcte des balises et de leurs attributs... Bref, c'est l'exact équivalent d'un correcteur orthographique en plus bête (il ne corrige pas mais se contente de signaler la plus grande partie des fautes formelles). - Pour être accessible aux personnes handicapées utilisant ou non des outils spécifiques (lecteurs d'écran, navigateurs textes, plages brailles, loupes....), une page Web doit d'abord être valide HTML, et ensuite et surtout respecter un ensemble de règles spécifiques, normalisées en particulier dans le Guide d'Accessibilité des Contenus Web (WCAG). Tu en trouveras une version plus digeste dans ce référentiel d'accessibilité (Accessiweb). -pour être "ergonomique" (ce qu'on qualifie souvent aussi d'accessible par abus), un site peut se conformer à d'autres règles de "qualités". Celles-ci ne font l'objet d'aucune norme, mais un référentiel Qualité (Opquast) est actuellement en cours d'élaboration.

Dans la mesure où de toute façon, ces navigateurs reçoivent une version HTML complète du contenu, partaitement exploitable bien qu'en deça de leurs capacités, ça n'a en effet aucune importance. L'erreur serait en fait de recourir à un script basé sur l'identification du navigateur plutôt que sur ses capacités déclarées... Heu... En fait, adresser du XHTML1.0 en application/xhtml+xml ou en text/html n'a actuellement aucune importance pour le visiteur quelque-soit le navigateur. C'est juste une satisfaction pour l'auteur

Cet exemple est tout à fait pertinent, au contraire, puisque la technique utilisée est du même acabit (et tout aussi primitive) : un simple display:none CSS sur un pseudo-contenu uniquement destiné à multiplier grossièrement un mot-clé.

Comme tu le dis, cela règle "habituellement" le problème, mais pas toujours. Que veux-tu dire exactement par "reprendre" ? En fait, ces caractères doivent être remplacés par les caractères valides (l'apostrophe biduleuse de Word par un simple ' ...) L'hypothèse qui me semble la plus probable est qu'il subsistait des caractères encodés en windows-1252

Lien à supprimer : il duplique inutilement la fonction d'impression du navigateur. Même chose, duplication inutile de la fonction d'historique du navigateur. L'essentiel est déjà acquis pour l'accessibilité, puisqu'avec ce code, le lien s'ouvre dans la même fenêtre en l'absence de javascript. Mais avec javascript, ta fenêtre n'est pas redimensionnable et l'absence de barre de menu peut gêner des visiteurs. Donc utilise plutôt: <a title="Recherche rapide d'un professionnel" href="../../fiche2.php" onclick="window.open(this.href, 'Recherche professionnel', 'height=500, width=600, top=100, left=100, toolbar=no, menubar=yes, location=no, resizable=yes, scrollbars=no, status=no'); return false;">- rapide </a> D'autre part, "- rapide" n'a aucun sens lorsque le lien est lu hors contexte : il faut rendre cet intitulé plus explicite.

Attention: CSS2 ne se contente pas de compléter et d'étendre CSS1. Elle lui apporte également des corrections. Mieux vaut donc prendre CSS2 comme référence systématique. CSS2.1 n'est certes pas encore une recommandation : elle en est au dernier stade précédant ce statut, avec les plus grandes chances d'aboutir sous sa forme actuelle. Mais elle a un rôle assez particulier, car: - l'errata CSS2 a été interrompu au moment où CSS2.1 a été lancée en tant que document de travail. Différentes erreurs de CSS2 y sont donc corrigées, d'une manière tout à fait pertinente et applicable dès aujourd'hui. Voir l'exemple de la propriété clip. - CSS2.1 a explicitement pour rôle de "faire le tri" dans CSS2 entre ce que la pratique a retenu et ce qui n'a pas été implémenté/utilisé... Là encore, c'est un guide précieux. Donc, CSS2 comme norme, mais CSS2.1 comme "aide" à la lecture de celle-ci.

ça n'était pas un défi, Denis, juste une suggestion Cela dit, tout en vous prévenant que j'écris comme un cochon en PHP et que ce script est à améliorer, voici ce que j'utilise : <?php $accept_xml = !empty($_SERVER['HTTP_ACCEPT']) && strpos($_SERVER['HTTP_ACCEPT'],'application/xhtml+xml') !== false; if ($accept_xml) { header('Content-Type: application/xhtml+xml; charset=ISO-8859-1'); echo '<?xml version="1.0" encoding="ISO-8859-1"?>'."\n"; echo '<?xml-stylesheet type="text/css" href="style.css" ?>'."\n"; } else { header('Content-Type: text/html; charset=ISO-8859-1'); } ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <?php if ($accept_xml) { ?> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"> <head> <link rel="schema.DC" href="http://purl.org/DC/elements/1.0/" /> <meta name="DC.Format" content="application/xhtml+xml; charset=ISO-8859-1" /> <?php } else { ?> <html lang="fr"> <head> <link rel="schema.DC" href="http://purl.org/DC/elements/1.0/" /> <meta name="DC.Format" content="text/html; charset=ISO-8859-1" /> <style type="text/css" media="screen" title="defaut">@import url(style.css);</style> <?php } ?> <title>...</title> </head> etc... La fonction récupérant le type-mime souhaité par le navigateur est un peu différente (empruntée à DotClear), mais le principe est identique. Le schéma Dublin Core est plus une coquetterie qu'autre-chose et devrait être remplacé/complété par une <meta http-equiv="Content-Type" content="..." /> plus classique.

Si tu obtiens ces résultats, ce n'est pas vraiment normal en effet En utilisant tel quel le code que tu cites, j'obtiens au contraire: - un prologue xml et le type mime application/xhtml+xml dans Firefox et Opera - pas de prologue et le type mime text/html dans IE Heureusement, d'ailleurs, puisque ces résultats correspondent aux capacités respectives de ces navigateurs Au passage, le code ci-dessus devrait être complété pour ajouter en particulier : - la DTD XHTML1.0 dans tous les cas - l'élément <html xmlns=&quot;http://www.w3.org/1999/xhtml" xml:lang="fr"> en application/xhtml+xml et un simple <html lang="fr"> en text/html - la CSS par défaut avec <?xml-stylesheet type="text/css" href="..." ?> en application/xhtml+xml et un simple <link rel="..."> en text/html

Et si l'on cessait de prendre la sémantique des éléments HTML pour ce qu'elle n'est pas ? Il ne s'agit pas de dicter des règles pour la satisfaction d'avoir de belles constructions théoriques aux justifications très subjectives. Il s'agit d'apporter une information supplémentaire sur le sens du contenu par le choix d'un balisage approprié. Un balisage qui n'apporte aucune information exploitable n'a aucun intérêt. La question est donc toujours : quelle(s) informations ai-je à ajouter ? Ici, la seule information est que chaque question est associée à une réponse. Le choix de la liste de définition permet d'ajouter cette info, dans la mesure où un <dt> (question) serait implicitement lié aux <dd> qui le suivent. (Au passage, un <div> conteneur et un <hn> pour la question feraient tout aussi bien l'affaire.) Maintenant, le contenu du <dd> n'est qu'un texte comme un autre et peut être structuré : - avec ou sans un <p> unique - avec plusieurs <p> s'il y a plusieurs paragraphes - avec une liste s'il contient une liste d'item : le fait de comporter plusieurs paragraphes n'en fait pas pour autant une liste ! Ou alors, tout devient une liste...

Je suppose que tu avais fait quelque-chose comme: <dl> <dt><p>...Question...</p></dt> <dd><p>...Réponse...</p></dd> </dl> L'erreur fréquente étant que <dd> peut contenir des éléments blocs (<p> par exemple), mais que <dt> ne peut contenir que des éléments en ligne (donc pas de <p>) Le code valide est donc : <dl> <dt>...Question...</dt> <dd><p>...Réponse...</p></dd> </dl>

Il n'y a aucune propriété CSS pour la gestion des tabulations. Pour réduire la taille de celles-ci dans les <pre>, la seule solution est de les remplacer par des séries d'espaces.

Quelqu'un aurait-il le courage de lire les Conditions Générales de Vente (en pdf) pour trouver où est le loup éventuel et prévisible ?

Ce conseil n'est pas valable uniquement pour une page d'accueil, mais pour toute page par défaut d'un répertoire. Lier ton URL à un document précis et à une extension te condamne à y rester : conserver des pages statiques si tu as choisi un index.htm ou .html, PHP si tu as choisi un index.php, etc. Un répertoire te laisse bien plus de facilités pour l'évolution de ton site.

Quelqu'un a qualifié un jour le pdf de "document de verre". C'est à peu cela, pour la plupart de ses utilisateurs : un document figé, inerte, imprimable: on regarde, mais pas touche ! C'est une vision un peu limitée du Web. Surtout que diffuser du pdf n'empêche pas la copie, l'appropriation, etc. par des lecteurs indélicats.

Le résultat est nécessairement un peu "sec", dans la mesure où tu te limites ici au HTML (donc uniquement à la structure du texte) et à une CSS sans élément externe (donc sans image), gérée dans des <style media="..."> du head de tes documents. Sinon, pour ajouter des images... tu as le pdf

Tu as tout compris - les styles "textuels" liés aux couleurs, aux polices... directement dans la CSS en tenant compte d'une table de compatibilité NS4 pour les héritages de style (désolé, je n'en ai pas sous la main). - les styles de positionnement, d'éffet dynamique avec les :hover... etc. dans une seconde feuille appelée par la première par un _AT_import (non lu par les navigateur de génération 4) Mais si un praticien expérimenté de cette technique pouvait se manifester, ce serait bien : pour ma part, je laisse les navigateurs "périmés" faire sans CSS. Et ils font ça très bien tout seuls

Les styles sont parfaitement dissociés du document avec la syntaxe de <style> ci-dessus, dès lors qu'on passe par un _AT_import url dans chaque <style>. On a alors : - un fichier css unique pour chaque media - un <style...> _AT_import... </style> unique par media dans chaque document HTML, tout aussi facile à gérer qu'un <link media="..." > Mais l'intérêt principal du <style> est de masquer CSS aux navigateurs de génération 4 (NS4...) Ceux-ci ignorent de toute façon les <link> avec des medias "print", "handled", "projection", "aural"... Je ne vois donc guère l'intérêt de tout faire passer en <style> ? Ou quelque-chose m'a échappé ? En résumé, une solution simple, classique et un peu brutale : - un <style> pour le media "screen" (ou un media "all") - des <link> pour les autres medias Ou une solution plus attentive aux navigateurs de génération 4 (je l'emprunte à Fabrice Bonny) : - uniquement des <link> - avec des styles minimaux compatibles NS4... dans la CSS "screen" - complété dans celle-ci par un _AT_import url... pour les navigateurs plus récents.

La puce placée dans le contenu : - apparaîtra en double dans un navigateur graphique avec CSS désactivée (page enregistrée sans sa CSS, utilisateur désactivant la CSS parce que celle-ci lui pose un problème...) - apparaîtra également en double du caractère de liste (* souvent) dans un navigateur texte - sera lue "bullet..." ou "boulet..." dans un navigateur vocal (et quelque-chose d'approchant dans un lecteur d'écran). - ne sera pas modifiable facilement en cas de changement du design si cette technique est appliquée à un grand nombre de pages statiques - etc Bref, tous les défauts habituels d'un élément de présentation géré directement dans le HTML, que permet de contourner la propriété CSS "content".

Ce n'est qu'un identifiant comme un autre, propre à ce site qui a doit avoir dans son HTML quelque-chose comme: <a id="a1current"... >...</a> Il s'agit sans doute de gérer la présentation du lien pointant vers la page en cours (lien inutile, donc).

Non, ça ne marche pas : ce n'est pas la propriété list-style-type qui sert à générer une puce (elle ne fait qu'en spécifier le type). Les puces ne peuvent être générées que grâce à la propriété display:list-item. C'est la valeur par défaut pour l'élément <li>. Et en appliquant un display:inline au <li>, on supprime du coup la génération des puces. Bien-sûr, on peut retomber sur ses pattes à partir du display:inline grâce à un simple li:before avec un content: "•". Mais pas dans IE

Là, il faut revoir la notion de site "pro", et ouvrir les yeux des clients. C'est une des plus grosses illusions qui résiste à la pénétration des CSS. Aucun site ne peut avoir le même rendu visuel dans tous les navigateurs, même en se limitant aux navigateurs graphiques récents, et surtout pas, je crois, en osant un pari sur les navigateurs graphiques de demain : l'utilisateur a gagné avec CSS la possibilité d'imposer ses préférences. Dès lors que celles-ci seront plus facilement exprimable grâce à une gestion plus transparente des styles utilisateurs, l'illusion d'un rendu maîtrisé par le concepteur éclatera. Autre raison, immédiate : les coûts respectifs du "rendu identique" et de la "dégradation correcte"... Troisième raison : comment gérez-vous ça quand il faut tenir compte du media handled, par exemple ? N'importe-quel site, surtout "pro", devra, AMHA, en passer par cette notion de "dégradation correcte" (ou "dégradation admissible", ou "Tao" selon un article fameux traduit par pompage.net)