Xavier

Euh... il faudrait peut-être définir l'encodage que tu utilises Il n'est défini nulle part, ni dans les entêtes HTTP ni ailleurs. En plus l'encodage que tu utilises sur cette page n'est pas de l'utf-8 ! C'est pour ça que le validateur bloque. Ce sont des caractères windows-1252 je pense. Donc forcément ils ne peuvent pas être interprétés comme caractères utf-8 Ce ne sont en tous cas pas les entités qui provoquent ce message d'erreur. La page ne devient pas par magie utf-8 juste parce que tu le penses très fort Allez, un peu de lecture : http://french.joelonsoftware.com/Articles/Unicode.html Tu dois Définir l'encodage utilisé de préférence dans les entêtes HTTP (pas dans le <meta> Encoder tes pages en conséquence Et tout ira mieux.

Non, ce n'est pas normal ! En théorie un <br /> devrait être interprété comme ça : (saut de ligne) /> Eh oui, c'est un "bug" des navigateurs qui permets de faire passer du XHTML comme du HTML. C'est une des raisons de ne pas faire de XHTML envoyé en html indiquées dans l'article que j'avais mentionné : http://hixie.ch/advocacy/xhtml Mais il y en a de nombreuses autres (commentaires etc.) Alors baser l'affichage correct de ses pages sur une erreur d'implémentation du SGML par les navigateurs... très peu pour moi

Non c'est parfaitement compatible. Il doit y avoir un autre problème. On peut avoir un exemple ?

Rhooo, Dudu, qu'est-ce que je réponds moi maintenant ? Tu m'as piqué toute ma réponse. Bon, il me reste encore une carte, une seule : Sending XHTML as text/html Considered Harmful. Eh oui, faire du XHTML et le traiter en text/html c'est rien d'autre que de proposer un tag-soup plein de /> aux navigateurs, qui ne vont rien faire d'autre que de corriger ça vite fait Il suffit de réenregistrer une telle page depuis le navigateur pour s'en rendre compte, tous les <br /> sont devenus de <br> prouvant que le navigateur vous a pris pour un gros naze qui ne sait pas coder Sauf que le XHTML 2.0 n'est Pas près de sortir (il est au stade de Working draft, pas de recommandation finale avant de très nombreuses années Encore moins près d'être implémenté dans les navigateurs (pour peu je prendrais presque les paris qu'il ne sera pas utilisable avant 10-15 ans). On a donc largement le temps de voir venir. Par contre ce qui va venir plus vite c'est le HTML 5.0 tel que proposé par le WHATWG, avec ses WebApps, ses WebForms et ses WebControls. C'est un HTML "+". Pour info le WhatWG regroupe la majorité des fabricants de navigateurs. (en fait probablement tous sauf Microsoft). Le but est de proposer quelque chose d'utilisable, et ce rapidement, sans attendre que le XHTML 2.0, donc d'ici quelques années, et pas décennies. Le dernier document de travail est sorti pas plus tard qu'aujourd'hui. Ça avance donc vite. Je ne sais pas s'ils prévoient une version XHTML, pas sûr du tout. Donc le XHTML, je ne sais franchement pas trop (à part pour le SVG et MathML...).

Oui, à vrai dire il n'y a à ma connaissance guère que Gecko (Mozilla, Firefox et cie), KHTML (Konqueror et Safari) et Presto (Opera) qui le supportent, et probablement quelques autres browsers exotiques. IE ne connait pas (et demande de télécharger), et de nombreux autres navigateurs non plus (vieux ou pas). Bref, le HTML c'est très bien. Strict bien évidemment (c'est-à-dire avec séparation contenu/mise en forme).

Tu peux très bien les laisser, ce n'est pas incompatible. Sinon, tu ouvres le texte dans un navigateur et tu fais un copier-coller

Il n'y a aucune raison de faire du XML. Et en tous cas pas juste pour "être à la mode" Le XML c'est symplement une syntaxe. Elle est à la base de nombreuses syntaxes (SVG, XForms, RDF et bien sur XHTML) mais en soi elle ne veut rien dire. Fais un site en XML, tu aura quelque chose qui ne veut rien dire et que les navigateurs ne pourront pas interpréter (vu que ça ne veut rien dire). Bien sur tu peux te créer ton propre langage XML, qui lui aurait un sens. Mais de là à ce que les navigateurs le comprennent, je crois que tu peux dormir tranquille Bref, reste en HTML, c'est le plus adapté à l'heure actuelle. Le Xhtml est encore trop mal supporté. Si vraiment tu veux te mettre au XML pour faire hype, utilise-le comme base de données (c'est à ça qu'il sert en fait, décrire des données).

Et si tu mettais un text-decoration:underline au lieu de rajouter une bordure ? Parce que la bordure va forcément agrandir le bloc... et il me semble qu'un underline non. Juste un truc. Le border-bottom, tu l'appliques sur le a (en :hover). Le border: none; tu l'appliques sur le img... donc le a va garder son border-bottom de toutes façons

Merci En fait il semblerait que ce soit corrigé dans les toutes dernières versions de Konqueror... me reste donc plus qu'à trouver un utilisateur d'une version de développement de Safari pour savoir si la correction y a été appliquée aussi (parce que je ne doute pas qu'il aime les feedbacks, mais je doute qu'il apprécie à ce point les feedbacks sur des choses qu'il a déjà corrigées ) Bon, si c'est corrigé, et comme le problème est somme toutes excessivement peu gênant (c'est juste que ça m'a sauté aux yeux), je ne vais pas tenter de correction !

Non non pas du tout ! Comme je le disais, tout ça est stocké dans le profil.C'est peut-être un concept totalement étranger pour les habitués de Windows et des programmes qui stockent tout dans leur dossier s'installation (empêchant du même coup toute utilisation multi-utilisateur), mais la majorité des logiciels libres (mais de loins pas que) stockent toutes ces données dans le répertoire utilisateur. Il faut dire que sous tous les OS Unix-like les programmes n'ont pas accès à leur répertoire d'installation (du moins en mode utilisateur normal), ce qui est une exclusivité windowsienne totalement stupide et source de tous les virus, et donc ils sont obligés d'utiliser ce répertoire, pas le choix. Sous Windows il s'agit d'un sous-répertoire de documents and settings que Windows, pour une obscure raison, s'obstine à cacher pour compliquer la vie des utilisateurs. Sous les autres OS je crois que c'est nettement plus simple (car le système ne cherche rien à cacher). Bien entendu ce répertoire utilisateur n'est aucunement touché par la désinstallation. Donc tout est conservé ! Et bien des ennuis sont évités. Tu peux désinstaller sans soucis, je crois que la case "supprimer les données utilisateur" a carrément été supprimée il y a un bon moment en raison des soucis que ça a pu causer, donc tu n'as plus aucun risque

Note que même si ce n'est plus officiellement conseillé, il est toujours officieusement conseillé de désinstaller la version précédente avant d'installer la nouvelle... (le profil avec toutes les données personnelles est bien entendu conservé). C'est la cause de nombreux problèmes (pas toujours compréhensibles d'ailleurs).

Tu peux essayer de passer les images png à la moulinette de PNG Optimizer, on obtient souvent de bons résultats (je ne connais pas la qualité de compression de GD...). N'oublie pas que le PNG n'est pas vraiment destiné aux images de type photos. Il est même complètement nul pour ça (il n'est d'ailleurs pas prévu pour). Normalement pour des photos, une compression jpeg à 85-90 donne d'assez bons résultats au niveau taille sans pour autant que la perte de qualité soit trop importante... tout dépend de la qualité que tu veux en fait

Normalement tu dois réfléchir à ça avant de coder. Afin justement de coder comme il faut en respectant les règles que tu t'es données. Si ton code respecte strictement la séparation entre le contenu et la mise en forme, tu peux utiliser un doctype strict ou un doctype transitionnel. Sinon, si ton code HTML contient des éléments de mise en forme, alors tu dois utiliser le doctype transitionnel. À moins que tu n'utilises les frames, auquel cas il te faut un doctype frameset C'est pour ça qu'il faut choisir avant, se fixer des objectifs, et s'y tenir

Bon, j'ai poussé un peu l'investigation. Pour Opera, c'est tout simplement qu'il ne supporte pas les sélecteurs CSS3 et ignore la règle. Comportement exemplaire donc. J'ai mis en place un petit test minimal : http://home.etu.unige.ch/~robin0/tests/essai.html Deux listes, avec un :after. Sur les deux, j'applique l'image. Sur la deuxième, je réécris la règle pour faire afficher l'id en premier. Je suis en train de faire des captures mais ça ne fonctionne pas super bien (je ne comprends pas pourquoi j'ai des erreurs 403 forbidden ) Bref, si un utilisateur de Safari ou de Konqueror pouvait tester pour voir si l'image est après ou avant le terme "second", ce serait sympa. (elle doit donc bien sur être après). Si elle est avant c'est qu'il y a un bug dans KHTML (du style qu'il ajouterait simplement la règle au lieu de la remplacer, mais c'est tellement gros que ça me paraît impossible ) Edit : voici la capture de Konqueror : http://browsershots.org/job/379527/ Effectivement, l'image est avant Il faudra qu'on m'explique ça...

Bonjour, Mon site : http://home.etu.unige.ch/~robin0/ Dans le menu à droite, en bas, j'ai un lien "Contact". Il est stylé avec les règles CSS suivantes : #contenu a[href^="mailto:"]:after, #plan a[href^="mailto:"]:after, #contenu a[href$="contact.html"]:after, #plan a[href$="contact.html"]:after { content: "\00A0" url("tbird.png"); } #contenu a[href^="mailto:"][accesskey]:after, #plan a[href^="mailto:"][accesskey]:after, #contenu a[href$="contact.html"][accesskey]:after, #plan a[href$="contact.html"][accesskey]:after { content: "\00A0\0028" attr(accesskey) "\0029\00A0" url("tbird.png"); } Bon, les sélecteurs sont un peu complexes. En gros : les liens "mailto" et les liens pointant vers la page "contact.html" en :after ont une image pour les différencier Si il y a une accesskey il est placé entre parenthèses juste avant. Je pensais que tout allait bien, à part Opera 8.5 qui ne semble pas vouloir de l'image. Rien de bien méchant même si ça ne semble pas correspondre avec le css browser support. Mais voilà que je me dis que je vais utiliser un site de captures. Le résultat : http://browsershots.org/website/376076/ Et là je constate avec effarement que dans Konqueror et Safari l'image est avant l'accesskey Quelqu'un qui a un de ces deux navigateurs pourrait confirmer ? Et pourrait m'expliquer pourquoi ??? C'est un bug connu ? Il y a moyen de le contourner ? Merci de votre aide

Je ne sais pas si c'est beaucoup plus "propre" de se faire enchaîner des <label> et des <input>. Pour peu qu'un navigateur texte ne gère pas les labels (ce dont je suspecte Lynx), il n'y a aucun moyen de savoir quel input se rapporte à quel label. C'est potentiellement un problème Difficile à dire, ayant l'extension Stylesheet Chooser Plus sous Firefox il a mémorisé le style utilisé. Donc je ne peux pas trop dire. Mais ailleurs ça passe bien

Pas le moindre texte alternatif sur les images... ton site n'a aucun contenu Pense un minimum à l'accessibilité

Bizarre... Bon, déjà, fait attention, en 800x600 ton site ne passe pas du tout du tout. C'est le problème des positions fixes. Essaye au moins de faire en sorte que ça ne soit pas trop gênant. Sinon j'aime beaucoup le application/xhtml+xml Pour en revenir au problème, ça ne passe effectivement pas à la ligne chez moi non plus (Firefox 1.0.7 sous windows). Tout est sur la même ligne. Mais... si je lance EditCSS d'un coup hop ! ça passe à la ligne En fait ça viens des "titles" que tu as défini. Dans Firefox, fais Affichage > Style de la page > ... En fait tu dois toutes leur donner le même titre. Là tu as défini plusieurs styles différents, un peu comme si tu avais des "alternate stylesheet"s. Sauf qu'elles ne sont pas en alternate, ce n'est pas le but. Mais le navigateur ne sait pas trop comment traiter ça, il voit des feuilles de style pour plusieurs styles différents. Donc mets-leur tous le même title (ou alors aucun title si tu ne veux pas de feuille alternative)

Il me semble que dans le cas du tutoriel d'alsacréations, le javascript et utilisé aussi pour cacher les éléments. Donc sans javascript, on ne peut pas les faire apparaître, mais c'est pas grave vu qu'ils sont déjà affichés (Il faut quand-même toujours vérifier avec javascript désactivé que ça passe bien...)

Attention, les acceskeys se définissent directement dans la page HTML, pas dans la CSS <a href="lelien.html" hreflang="..." accesskey="3">le lien</a> Ce que tu peux faire dans la CSS c'est afficher l'accesskey que tu as défini en html (pour que tes visiteurs sachent qu'ils peuvent utiliser les accesskey). Mais en aucun cas le définir. Exemple : a[accesskey]:after { content: "(" attr(accesskey) ")"; }

Dans ce cas c'était plus en raison de la guerre IE/Netscape, chacun ayant sa solution propriétaire et non standardisée...

Si tu avais vraiment voulu avoir une impression au pixel près, tu aurais fait un PDF ;-) L'impression de pages web est vraiment très, très, très aléatoire, probablement encore plus que celle des documents word (c'est déjà pas peu dire). Firefox a de gros soucis avec l'impression, mais ce n'est probablement pas le seul. Si le but est d'imprimer, alors propose un pdf, c'est beaucoup plus sûr

C'était ça ?

C'est hautement hypothétique, mais ne faudrait-il pas passer la propriété table layout à true ? Je dois avouer ne jamais avoir essayé, d'où le "hautement hypothétique"

Merci Ce n'est donc clairement pas désintéressé (mais plutôt ambitieux, j'espère qu'ils y arriveront) !