LaurentDenis

Là, j'avoue, je n'ai pas cherché à tester ... je n'ai pas ce genre de vices En fait, le test est tout fait : beaucoup de gens qui veulent utiliser XHTML1.1 ne sont pas au courant de cette question de type mime et servent leurs pages comme du HTML...

Merci pour vos réponses. La machine a longuement séché toute seule.... mais partira aujourd'hui chez le technicien compétent Et je vais décidément passer à une utilisation "nomade" à base de linux knoppix et de clé usb avec sauvegarde quotidienne : si je l'avais fait comme j'en avais l'intention il y a quelques mois, j'aurai tous mes outils dispo sur mon portable de remplacement

Apparement, tu as trouvé la solution pour les p'tits bouts de chocolats ? ce matin, ils suivent obstinément mon curseur dans Opera

Bon, comme je suis apparement un peu pour quelque-chose dans les hésitations de Denis, je résume : - XHTML1.1 apporte la modularité (MathMl par exemple) et l'élément ruby. - Si on a besoin de l'un ( http://golem.ph.utexas.edu/~distler/blog/a...ves/000167.html ) ou de l'autre ( http://glandium.org/ ), XHTML1.1 est inévitable, et les navigateurs qui ne l'implémentent pas doivent recevoir du XHTML1.0. - Sinon, c'est tout simplement un doctype mal choisi Maintenant, il y a une 2e question : quand on fait du XHTML1.0, cela vaut-il la peine de faire de la négociation de contenu pour envoyer du application/xhtml+xml aux navigateurs qui le supportent ? Seules différences concrètes : - les styles et scripts internes ne sont pas traités de la même manière, et posent de fréquents problèmes (voir http://devedge.netscape.com/viewsource/200...l-style-script/ en anglais) - une partie des erreurs de codage apparaîtront immédiatement, puisque les navigateurs comme Opera et les Gecko bloqueront sur celles-ci (A ne faire donc que quand on maîtrise totalement la production de son code); Mais on ne se prive donc pas de grand-chose, Denis, en utilisant text/html au lieu de application/xhtml+xml... Finalement, je crois qu'il faut en retenir que le choix d'un doctype doit être mûrement réfléchi en fonction : - de ses besoins (modularité, évolutivité, mais aussi à l'inverse compatibilité avec des navigateurs anciens...) - de ses limites (maîtrise plus ou moins grande de la production du code, recours par exemple à des outils générant des tags du type <u> ou des attributs name et lang...) Il n'y a pas de doctype préférable dans l'absolu.

Bon, ça n'a rien de bien mystérieux, et Xavier a bien indiqué les solutions Je résume : - le PHP de Stéphane repose sur le test des types mimes que le navigateur déclare accepter (si application/xml+xhtml, alors envoi de xhtml1.1, sinon envoi de xhml1.0). Il ne tient aucun compte de l'identification du navigateur, seulement de la valeur de HTTP_ACCEPT; - IE ne déclare pas accepter du application/xml+xhtml, donc il reçoit du xhtml1.0; - le validateur W3C ne déclare pas accepter du application/xml+xhtml,donc il reçoit lui aussi du xhtml1.0 lorsqu'il valide à partir de l'url; - Opera, Gecko... déclarent accepter du application/xml+xhtml, donc ils reçoivent du xhtml1.1, et lorsqu'on valide depuis le navigateur par envoi du code source, ils lui envoient ce qu'ils ont reçu, c'est à dire du xhtml1.1. Si on pouvait valider depuis IE de la même manière, on validerait du xhtml1.0. Là où le validateur montre ses limites, c'est qu'il se comporte en fait exactement comme les navigateurs : il accepte de traiter du xhtml1.1 sans tenir compte du type mime (si vous envoyez du xhtml1.1 à Gecko et Opera en text/html, ça ne les gênent pas, alors qu'ils devraient refuser).

Merci de ne pas poser de question non documentée : il est alors impossible d'y répondre... Merci également de développer dans le forum les solutions que vous trouvez finalement par vous-mêmes : le principe du forum est d'apporter l'info qui pourra être utile à d'autres.

Si jamais vous aviez fait cette malheureuse expérience, et si vous aviez des conseils avisés : Mon portable a très mal vécu hier soir la rencontre inopinée avec le contenu d'un verre plein de liquide. Après avoir séché, il redémarre, mais : - une partie des touches inaccessibles - disparition des ports com - le lecteur/graveur dvd lit mais ne grave plus. Bien-sûr, je vais le confier à un mécano compétent, mais j'aimerai d'abord vérifier si je ne peux pas m'en sortir moi-même

Je veux bien relire tout ce qu'on veux. Mais franchement, pas avec ce motif en background qui rend le texte illisible...

Cette propriété est mal supportée en général, et pas du tout par IE. Le seul mode fiable actuellement de contrôle de l'impression dans ce cas... c'est un PDF

Ah... Désolé, je burine ça à la main, avec mes propres XSLT, et je n'ai aucune idée de ce qui se propose actuellement sur le marché

un simple témoignage d'utilisateur de batteries en tout genre sur toutes sortes de machines, PC et autres outils : le cycle complet de chargement/déchargement est effectivement, à l'usage, ce qui semble favoriser la plus longue durée de vie des batteries.

Ah, je crois comprendre : tu utilises un service de syndication de contenu (Actifpub ?) pour générer le contenu inséré dans ta page http://www.7-dragons.com/google-news.php, c'est ça ? Si c'est bien le cas, le service en question génère tout simplement du HTML, pas du XHTML (doctype de ta page) : par exemple, il te produit des <br> et non des <br />. Ce n'est pas un problème de validité RSS, mais de validité du HTML produit à partir de ce RSS... Ta page sera peut-être valide sous un doctype HTML4.01 transitional. Sinon, deux possibilités : - écrire ta propre XSLT pour transformer ce fil en XHTML valide, - ou changer de fournisseur de service

Que veux-tu dire ? Un document RSS n'a pas à passer au validateur HTML. En revanche, il existe des validateurs spécifiques aux diverses normes RSS: - http://feedvalidator.org/ - http://www.redland.opensource.ac.uk/rss

A part ce qui précède, non. Si tu veux aller plus loin, cependant : ajoute à toutes les parties sur les balises présentatives (<b>, <center>...) une explication : - comme quoi on obtient le même résultat en CSS, ce qui est recommandé quand on en a la possibilité; - comment l'obtenir exactement (cas par cas : font-weight: bold; pour le <b>, etc)

Plus précisément AdBlock

Bravo ! Et merci C'est en effet un tout autre projet, très intéressant. Il n'y a pas de redondance dans un projet de ce type, AMHA. Et quand bien même, ce ne serait pas une raison de laisser tomber !

Pour FireFox, tu peux au moins t'épargner le téléchargement, avec une simple clé usb. Voir http://standblog.org/blog/2004/07/06/93113...s-the-usb-stick (désolé, c'est en anglais).

Hum... Juste pour signaler que: - les thèmes DotClear peuvent être proposés à Olivier Meunier (le créateur de DotClear), pour être diffusés directement depuis http://www.dotclear.net/themes/ - un wiki (site collaboratif ouvert à tous) a été créé pour écrire la documentation de DotClear : http://dev.dotclear.net/trac/wiki/DotClear/fr/Documentation Ce n'est pas pour brider les initiatives, loin de là ! Juste au cas où un travail concerté t'intéresserait

Hum... Je n'utilise pas, personnellement, les _AT_import dans les CSS (notamment pour des raisons de support à géométrie variable comme ici), mais seulement directement dans un <style> XHTML. ceci pour dire que je ne parle pas d'expérience dans ce cas. Mais lorsque je regarde dans IE5 Win, IE5.5Win et IE6Win le test http://www.w3development.de/css/hide_css_f...rowsers/import/ auquel fait référence http://www.phoenity.com/newtedge/hide_css_ie/, et plus particulièrement : ... eh bien... "This sentence is not blue in IE" Ce que confirme le test rapide effectué sur ta feuille de style ce matin. Moralité 1: quand quelqu'un affirme quelque-chose en se référant à une page de test, toujours tester la page de test. j'aurais été le premier à tomber dans le panneau, cela dit. Non mais, à qui se fier, je vous le demande !!! Moralité 2: la page de test ne couvre pas forcément toutes les possibilités de support. Il faudrait s'assurer qu'il n'y a pas un _AT_import url(...) quelque-chose bien précis qui ne fonctionnerait pas dans IE.

Pour le mot de passe FTP, à tout hasard, un problème idiot qu'on oublie parfois : le respect des majuscules/minuscules Pour http://membres.lycos.fr/espritcool/index.html, un problème important à régler: les liens du menu de navigation du site sont en flash. C'est très joli, certes, mais cela prive une partie de tes visiteurs de tout accès à ces liens : tout le monde n'a pas le plugin flash ou n'a pas la possibilité de l'utiliser...

Comme tu as lancé deux sujets parallèles, autant réserver celui-ci au contenu de tes cours et parler de l'amélioration technique du site dans Aide à l'amélioration d'un webmaster, quelques conseil ca aide.

Heu.... ça n'a peut-être rien de bien compliqué, en fait Xavier, dans http://smilissimo.free.fr/styles/menuvertical.css, tu utilises la règle _AT_import sous la forme: @import url(menuvertical_plan.css) screen,tv,projection; Or IE5, IE5.5 et IE6 Win ne reconnaît pas la règle _AT_import dans une feuille de style lorsque le type de media est précisé. Voir par exemple http://w3development.de/css/hide_css_from_browsers/import/ Il ne reconnaît que: @import url(menuvertical_plan.css); Il devrait normalement ignorer les règles qu'il ne supporte pas... Mais là, apparemment, il tente de traiter l'url et aboutit à un infâme bouillon qui provoque tes erreurs 404.

Non. Très franchement, je ne vois personnellement aucun intérêt à s'engager dans une de ces comparaisons acharnées, micro-fonctionnalité par micro-fonctionnalité. On peut y passer beaucoup de temps... pour un résultat en général nul. Tout au plus découvririons-nous l'un et l'autre une possibilité supplémentaire offerte par l'un ou l'autre navigateurs, mais il y a des moyens bien plus économiques en temps pour se tenir au courant de ce genre de choses Je ne cherche pour ma part à convertir personne à autre chose que de faire son propre choix en connaissance de cause. D'ailleurs, que quelqu'un utilise IE ou NS4 ou les premiers opera qui étaient assez cocasses dans leur genre... c'est très bien, si celui-ci répond à ses besoins et s'il a choisi en fonction des limites et des atouts de son outil. L'intérêt de cette discussion était plutôt de montrer que la pluralité de navigateurs innovants est dans l'intérêt des utilisateurs finaux. D'ailleurs, qui dit pluralité dit aussi émulation, et diffusion des innovations

Nous sommes bien d'accord : - Toutes ces petites manip peuvent être faites de différentes façons, CSS, WebDevelopper... et chaque utilisateur qui en a besoin peut faire son choix d'outil à sa convenance. - Elles ne sont présentes par défaut ni dans FireFox... ni dans Opera (Ce sont des CSS utilisateurs qu'on ajoute tout comme les extensions FireFox). Donc, elles n'encombrent pas ceux qui n'en n'ont pas besoin Bilan : vive la diversité des navigateurs innovants

Les messages ayant dérivé sur la comparaison FireFox/Opera ont été déplacés vers un nouveau fil : Le choix d'un navigateur Web...