LaurentDenis

Difficile de te répondre pour l'instant, l'url http://www.synaltis.com/ menant à une erreur serveur

je te sais sur la même longueur d'onde, Monique mais une petite polémique permettrait de discuter sur le fond de cette question (pour une fois que je cherche le pseudo-troll, moi...) Cela dit, plus concrètement, la solution <table> a peut-être un aspect à souligner : l'héritage des propriétés CSS dans les tableaux n'est pas l'aspect le plus logique du comportement des navigateurs. A priori, en cas de mauvaise surprise, ce type de solution peut juste nécessiter qu'on soit un peu redondant et très explicite dans sa CSS pour les couleurs, les polices, les tailles de caractères... surtout en mode "Quirks".

Tiens, avant de me faire lyncher (non ? ), j'ai encore le temps de te donner un exemple bien réel (site conforme, standard, accessible et tout, avec un ptit tableau de présentation pour une raison similaire) : http://www.eyrolles.com/

C'est l'éternel problème des hauteurs forcées en CSS: - CSS gère avant tout les hauteurs selon le contenu à afficher (notion de flux); - la propriété CSS min-heigth prévue pour forcer ce type de comportement est trop mal implémentée dans les navigateurs actuels pour être utilisable. Il existe de multiples contournements CSS, plus ou moins abusifs, plus ou moins lourds. Le plus drôle fait adopter à la div concernée le rendu CSS... d'une cellule de tableau (display: table-cell). Allez, je vais le dire avec délice : fais plutôt un tableau de présentation (tableau, ligne et cellule uniques) à la place de cette div. Tu n'entraveras pas l'accessibilité de ta page, et tu utiliseras la solution de présentation la plus directe.

Ce qui est fantastique, en l'occurence, ce sont les Standards Web, c'est à dire la normalisation du javascript (DOM) et des bonnes pratiques en la matière

Allez, j'abonde dans le sens de Paginus : faire le choix, même raisonné, de développer pour un navigateur, c'est faire le pari que vos utilisateurs Internet resteront majoritairement fidèles au navigateur en question, que votre Intranet le conservera, qu'il conservera sa position dominante... C'est juste un pari. Developper selon des standards qui garantissent l'interopérabilité de votre site, c'est éviter ce pari nécessairement hasardeux.

Le but du jeu est justement de mettre à la place d'adresse l'url de la popup (donc en double dans le href et dans le window.open). En effet, par le biais du "return false" : - si le javascript est activé, le onclick renverra un "false", ce qui empêchera justement ce lien direct d'être activé; autrement-dit, la page ne sera pas rechargée. - mais si le javascript n'est pas activé ou n'existe pas, le onclick ne renverra pas "false", auquel cas le lien sera suivi et le popup impossible s'ouvrira dans la même fenêtre comme un lien normal. C'est toute l'astuce de la chose

Après avoir relu http://www.dublincore.org/documents/dcmi-terms/ ... et en l'absence éventuelle d'un vocabulaire normalisé, pourquoi ne pas simplement utiliser le mot-clé "diaporama" ? En effet : Recommended best practice... mais encore faut-il que le vocabulaire normalisé en question existe (sans compter le problème de son internationalisation) Détail amusant, le projet Digital Library Project de l'université de Berkeley a choisi de ne pas utiliser la meta DC.Subject... C'est aussi le cas de Photo RDF, Metadata and Pictures du W3C.

Deux sujets à lire sur le hub : - faire des popup propres et accessibles : http://www.webmaster-hub.com/index.php?sho...indpost&p=35799 - techniques anti-spam : http://www.webmaster-hub.com/index.php?&act=ST&f=54&t=3927 A priori, javascript n'est pas "louche", mais limite simplement les fonctionnalités d'un site. En effet, tout ce qu'il traite échouera : - pour les utilisateurs n'ayant pas de support javascript ou l'ayant désactivé; - ou lorsque le javascript n'est pas standard ou est erroné, ce qui est le cas d'une grande partie des scripts Dans ton cas, tu aurais donc intérêt à : - changer le script des popups pour un script compatible avec les navigateurs sans javascript (ce qu'on appelle un script non obstructif); - y regarder à deux fois avant de rendre ton adresse mail inaccessible à certains visiteurs, vu l'efficacité de plus en plus périlleuse des astuces anti-spam de ce type (et l'efficacité d'un filtre côté client mail).

Pour ta meta DC, peut-être d'après http://lcweb.loc.gov/catdir/cpso/lcco/lcco_z.pdf Mais en fait, je crois que la LCC n'est pas vraiment pertinente. Le Dublin Core recommande l'usage d'ontologies (vocabulaires) normalisées... mais celles-ci sont encore souvent à naître. Tu trouves des indications en cherchant chez Karl Dubost ou chez Philippe Janvier (je n'ai pas sous la main les liens précis vers leurs post abordant cette question). Pour les liens dans l'article Openweb... je vais voir ce que je peux faire dès que j'ai le temps

Et bien... pour commencer, à quoi diable sert cet horrible script qui crée un bien curieux <title>document</title> ? <script language="javascript" type="text/javascript">function f1(f1a){window.open("/?vv=im&v1="+f1a,"","resizable=no,toolbar=no,statusbar=no,scrollbars=no,width=550,height=400,left "+((screen.width-560)/2)+",top="+((screen.height-400)/2));}function f2(f2a,f2b,f2c,f2d){f2e=window.open("","","resizable=no,toolbar=no,statusbar=no,scrollbars=no,width="+f2c+",height="+f2d+",left="+((screen.width-f2c)/2)+",top="+((screen.height-f2d)/2));f2e.document.write('<html><head><title>document</title></head><body style="background-color:tan;margin:0"><a href="javascript:window.close()"><img src="docs/'+f2a+'" title="'+f2b+'" border="0" alt="document"></a></body></html>');}function f3(f3a,f3b){f2e=window.open("","","resizable=no,toolbar=no,statusbar=no,scrollbars=no,width=300,height=150,left "+((screen.width-300)/2)+",top="+((screen.height-150)/2));f2e.document.write('<html><head><title>document</title></head><style type="text/css">*{font-family:verdana,arial;font-size:13px}</style><body style="background-color:tan;"><br><div align="center">'+f3b+'<br><br><input type="button" value=" écouter l'extrait " onclick="location.href="docs/'+f3a+'""></div></body></html>');}window.onload=function(){for (i=0;i<document.links.length;i++) if (document.links[i].name.substr(0,4)=="ilto") document.links[i].href="ma"+document.links[i].name.replace("AENTOURE","@");}</script>

Sur quels thèmes porte ton diaporama ? Il semble que nous ayions un lien erroné à corriger, là, en effet

Non, du moins pas au sens ou tu l'entends. Pour obtenir ce résultat, c'est à toi de mettre en place le contenu traduit. Cependant, lorsque tu utilise Google Translate (par exemple), il est possible de "naviguer" de pages traduites en pages traduites simplement en suivant les liens du site dans la version traduite (en d'autres termes, ces liens ne renvoient plus à ton site lui-même, mais envoient les pages visées au robot traducteur). Sinon, sur le fond, vu la qualité encore très médiocre des traductions automatisées en ligne, il vaut mieux AMHA laisser tes visiteurs non francophones aller d'eux-mêmes sur le traducteur de leur choix s'il veulent te lire dans leur langue... Ajouter des liens directs comme ci-dessus n'apporte pas grand-chose.

J'ai déjà tenté cette expérience il y a quelques mois, de manière totalement confidentielle pour éviter que les problèmes de backlinks, de PR, etc. ne viennent fausser le résultat. Le bilan est... qu'il est justement impossible, AMHA, d'isoler ces paramètres "sémantique/non sémantique" et d'être sûr qu'aucun des autres paramètres utilisés par Google n'interfère. En fait, le fonctionnement de Google est (volontairement) trop adapté à un Web codé avec les pieds pour qu'on puisse avancer autre chose que quelques hypothèses temporaires: - Google prend en compte certains éléments sémantiques et pas d'autres, sans que ces choix soient forcément cohérent; - Le poids relatif des éléments sémantiques bien utilisés et de la soupe de tag est parfois en faveur de la soupe : <b> plutôt que <strong>, par exemple. Ce qui est logique puisque Google "colle" aux pratiques majoritaires des auteurs. Mais pas toujours : <h1> plutôt que les <FONT>... - L'évolution de Google elle-même ne semble pas aller dans une direction bien précise. Jusqu'à ces derniers temps, on pouvait par exemple constater que Google prenait en compte un îlot de données RDF dans un document XHTML pour en extraire une description visible dans la page de résultats. Mais les pages-tests que j'ai pu voir ne semblent plus fonctionner ainsi depuis le début du printemps... C'est pourquoi j'en resterai à cette position "minimaliste" : un document valide, bien structuré et soucieux d'une sémantique (X)HTML élémentaire ne nuit apparemment pas au référencement actuel... et a des chances de favoriser le référencement futur. Tiens, pour la petite histoire, un autre aspect amusant de Google : il semble acquis qu'il exploite le contenu des attributs alt des images, je crois, du côté référencement. Mais si tu prends Google Translate, tu verras qu'il ne traduit pas le contenu des attributs alt (En revanche, Babel Fish le fait...)

C'est une particularité du mode de rendu CSS "Standard" (celui du W3C) que l'on ne retrouve pas dans le mode de rendu "Quirks" (compatible Microsoft) ou le mode "Almost Standard" (propre à Mozilla). [edit]Mode de rendu CSS en bref : - Le mode de rendu CSS est la manière dont chaque navigateur applique les CSS. Microsoft ayant créé son propre mode de rendu non standard pour IE5 Windows, tous les navigateurs plus récents ont dû implémenter ce mode Microsoft en plus du mode standard qu'ils utilisaient déjà - Ils se sont également dotés d'un mécanisme appelé DocType Switching permettant aux concepteurs de pages Web d'indiquer quel mode adopter pour traiter leurs pages). - Ce système de double de mode de rendu et de DocType Switching fonctionne également dans IE6 Windows et IE5 Mac. [/edit] En mode de rendu strict, une image étant par défaut un élément en-ligne, elle est alignée verticalement exactement comme une lettre sans jambage (la lettre a, par exemple), c'est à dire au-dessus de la ligne de base du texte. Or, sous la ligne de base du texte, il reste un espace inférieur pour les jambages des lettres comme le p. C'est cet espace que tu vois apparaître. Ta solution de placer tout le code sur une seule ligne n'en est pas vraiment une, car elle repose sur un bug d'IE et ne fonctionne pas par exemple dans Opera. Pour empêcher cet espace d'apparaître, il y a trois solutions possibles : - Faire passer le navigateur en mode "Quirks" en utilisant le DocType switching (choix d'un doctype qui force ce mode de rendu). - Rester en mode "Standard" et faire traiter l'image comme un élément bloc au lieu d'un élément en ligne : img {display: block;} - Ou utiliser les règles d'alignement du texte par rapport à la ligne de base : img {vertical-align: bottom;} Voir Images, Tables, and Mysterious Gaps (en anglais).

Et bien... Comment dire ? Je ne me permettrai pas de qualifier cette idée de stupide, mais le media braille est défini ainsi par la spécification CSS: ( http://www.yoyodesign.org/doc/w3c/css2/med...tml#media-types ) Le fonctionnement des appareils brailles est totalement différent de celui d'un navigateur texte : ce sont des medias tactiles à grille de caractères fixe, et non des appareils visuels...

XHTML1.0 - permet de traiter les documents en tant que XML et de leur appliquer des transformations XSLT, par exemple pour créer automatiquement une version pdf d'un texte, la table des matières d'un article, un index, etc. Ce qui suppose qu'on sache utiliser XSLT ou qu'on veuille s'y mettre (ce qui est une excellente idée vu la puissance et la facilité de la chose), et qu'on dispose des outils et compétences nécessaires côté traitement serveur (PHP ou ASP par exemple). XHTML1.1, XHTMLbasic - y ajoutent la modularité : on peut ajouter au document XHTML des emprunts à d'autres dialectes XML, comme MathMl pour les formules mathématiques, ruby pour l'afffichage des signes diacritiques dans certaines langues s'écrivant en pictogrammes (chinois, hébreu...). Mais ça fonctionne très mal ou pas du tout selon les navigateurs, qui n'implémentent pas encore correctement ces outils. En outre, tous les dialectes XHTML ont un rôle "pédagogique" : comme ils reformulent le HTML en XML en conservant son vocabulaire de base et avec juste quelques modifications de syntaxe, ils permettent de découvrir l'utilisation du XML dans un cadre plus familier qu'avec un dialecte XML complexe comme DocBook par exemple. Sinon, XHTML n'apporte rien : - sur la pérennité des documents : les doctypes XHTML ne sont ni plus ni moins durables que les doctypes HTML. Et XHTML1.x sera à égalité avec HTML4.01 lorsqu'il s'agira de convertir des documents dans le futur XHTML2.0, qui ne sera pas rétro-compatible. - sur l'interopérabilité des documents : les pages en XHTML sont traitées actuellement comme du HTML par la plupart des machines (robots des moteurs de recherche, traducteurs automatiques, etc.) - sur l'accessibilité : les éléments spécifiques pour l'accessiblité (<label> des formulaires, attribut alt des images...) ont été introduit dans les normes précédant HTML4.01 et XHTML1.x n'y ajoute rien. - sur la séparation contenu/présentation, à quelques détails près (scripts et CSS fortements incités à ne plus figurer dans le document XHTML, mais dans des sources distinctes). - sur le poids des documents. - sur le référencement. Bref : à moins d'avoir besoin de manipuler ses sources via XSLT, ou d'avoir besoin de modules XML spécifiques, XHTML1.0 n'est intéressant que pour apprendre à rédiger conformément aux règles XML.

Argh ! j'avais manqué ce problème de fond à propos de ce site: Grantome, tu reproduis l'erreur consistant à produire du XHTML1.1 en ignorant la question du type MIME des documents. C'est un point que le validateur du W3C n'implémente pas, et le résultat est en fait totalement invalide. En résumé, du XHTML1.1 ne doit pas être servi en tant que text/html (bien qu'un bug du validateur du W3C ne lui permette pas de faire la différence). Ce n'est plus du HTML : il ne peut être servi que comme application/xml+xhtml, parce que c'est du XML uniquement, et non plus un hybride HTML/XHTML comme XHTML1.0. Voir les précédentes discussions sur ce sujet ici: - http://www.webmaster-hub.com/index.php?sho...indpost&p=30761 - http://www.webmaster-hub.com/index.php?sho...indpost&p=37282 - http://www.webmaster-hub.com/index.php?sho...indpost&p=37281

Il n'y a pas de XHTML 1strict. Le test ci-dessus et le raisonnement sous-jacent sont tout aussi valable pour XHTML1.0 strict (ça, ça existe) : http://validator.w3.org/check?uri=http%3A%...mage-et-xhtml11 (Là, le validateur reçoit du XHTML1.0 strict). Comme le sujet revient de temps en temps, je résume rapidement : - Les attributs height et width sont valides en HTML4.01 Strict, ne relevant pas des attributs de présentation (voir la spécification) qui font l'objet de la distinction strict/transitional. - XHTML1.x reprend exactement le vocabulaire d'éléments du HTML4.01, et la quasi-totalité de son vocabulaire d'attribut. Dans sa version strict, il fait les mêmes exclusions que HTML4.01 strict. En aucun cas, il n'exclut height et width pour les images. XHTML1.1 supprime les dernières concessions au HTML présentes en XHTML1.0, et conserve bien-sûr ces deux attributs. Bref, cette histoire de devoir passer en CSS les dimensions des images est une interprétation totalement erronée des spécifications. Comment faut-il l'expliquer pour mettre fin à ce fantasme ?

Petit test à ce sujet : http://lgd.name/index.php/2004/08/01/12-image-et-xhtml11 (Attention à valider en s'assurant que la DTD XHTML1.1 est prise en compte par le validateur, autrement dit en faisant un "Valider le code source" à partir de la page affichée dans Opera, par exemple. Un copié collé de l'url dans le formulaire de validation du W3C validera la version XHTML1.0 envoyé faute de réponse correcte du validateur sur l'acceptation du type mime application/xml+xhtml)

Non. les attributs height et width des images sont valides en XHTML1.1, 1.0, basic et autres variantes à venir La taille d'un objet visuel ne relève pas de sa présentation, mais de sa structure.

Remplace d'abord les esperluettes (caractère &) dans les urls par l'encodage & Tu y verras plus clair dans les erreurs de validation (il semble qu'il y aussi un problème de structure du formulaire, mais je n'ai pas regardé en détail).

Merci d'avoir pris la peine de revenir indiquer la solution, de sorte que ton sujet puisse servir à d'autres Edit : j'ai rectifié dans ton message : MIME et non pas MINE.

je ne peux guère te répondre que pour DotClear. Pour l'instant, c'est une application de blog individuel, qui permet de gérer plusieurs auteurs avec des droits différents si nécessaire, mais sur un blog unique. Il ne permet donc pas de gérer plusieurs blog à partir d'une installation unique. cependant, l'installation de multiples DotClear sur un seul serveur est très facile, et pas mal de choses peuvent être centralisées, notamment le "thème" qui détermine la structure et la présentation du blog. Cela dit, l'un des membres de ce forum, Clair de Lune, a utilisé DotClear pour un multi-blog en détournant le système des catégories. C'est une expérience qui peut peut-être t'intéresser : http://amalgame.theatre.free.fr/troupe.htm (je n'ai plus sous la main le sujet où nous en avions discuté).

En prenant la version XHTML comme source et avec une XSLT pour produire le HTML, ce serait en effet facile. Mais quel serait l'intérêt ? D'autant que le XHTML a toutes chances ici d'être en fait du HTML, c'est à dire envoyé aux navigateurs en tant que text/html, et non application/xml+xhtml.