LaurentDenis

Je crains qu'il n'y ait pas de solution vraiment satisfaisante : - le stylage CSS d'un "input" est hasardeux, chaque navigateur ayant ses limitations spécifique. Ici, par exemple, Mozilla/FireFox ne souligne pas le lien et Opera ne supprime pas la bordure. - le document.write empêchera le passage éventuel du site en XHTML (documentwrite est ignoré en "vrai" XHTML) - le bouton posera des problèmes d'accessibilité et de CSS - d'une manière générale, des utilisateurs seront déroutés de ne pas trouver un bouton submit pour le formulaire, comme ils en ont l'habitude. En fait, ton client a une très mauvaise idée... Mais ce n'est sans doute pas facile de le lui expliquer

Aurais-tu un exemple de code ? Une url de test ? Que veux-tu_dire exactement par "la colonne du milieu en fait composée de 2 blocs sur sa hauteur" ? - deux colonnes ? - deux blocs successifs, un en haut, un en-dessous ? Sinon, le schéma classique pour 3 colonnes sans pieds de page : - header en flux avec hauteur fixe en pixel - colonne centrale en flux avec marges - colonnes latérales en position:absolute, la valeur de top étant fonction de la hauteur du header. Avec un pied de page, il suffit de le mettre en flux et de lui donner les mêmes marges que la colonne centrale. Si le header a une hauteur variable, on préfèrera les flottants : - header en flux - colonne gauche en float - colonne centrale en float - colonne droite en flux (ou float) Avec cette solution, le code HTML est du type header > gauche > centre > droite. Si on préfère avoir header > centre > gauche > droite, il suffit d'utiliser position:relative pour intervertir le float gauche et le float central. Enfin, si tes deux "blocs de la colonne du milieu" se suivent verticalement et que tu veuillent contrôler leur hauteur... ce ne sera possible que dans les navigateurs supportant display:table-cell, ce qui exclut IE.

Mystère et boules de gommes J'avoue renoncer à chercher, car pour tout te dire, je découvre à chaque nouveau regard une bizarrerie de plus dans ta CSS: #Navigation { background: transparent; display: block; float: right; margin: 0.4em 0 0 0; padding : 0 0.4em 0 0.4em; position: absolute; right: 0; text-align: left; width: 20em; } Que veux-tu faire exactement ? - un float ? - une position:absolute ? Les deux sont incompatibles. Ici, le float est annulé par la position absolue... Il faut se souvenir que CSS n'a que 3 schémas de positionnement. Un élément ne peut être exclusivement que: - soit en flux (ce qui inclut aussi la position relative lorsqu'elle est seule) - soit en float (ce qui inclut aussi float+position relative) - soit en positionnement absolu (ce qui comprend position:absolute et position:fixed) Lorsqu'on se retrouve dans une de ces 3 erreurs classiques : - mélanger les règles de 2 schémas (float+position:absolute) - ou faire un float sans largeur spécifiée - ou vouloir qu'un positionnement absolu réagisse à la dimension des autres éléments (en ne les chevauchant pas, le cas typique étant la colonne qui chevauche le pied de page) ... c'est qu'il y a une erreur quelque-part

Ah... Je me demandais pourquoi Opera appliquait le float qu'il ne devrait pas appliquer. En fait, il ne l'applique pas, mais le fait que la colonne de droite soit elle-même flottante et dotée d'une largeur suffit, avec le jeu des marges, à aboutir à donner l'apparence de deux colonnes flottantes... En fait, c'est l'utilisation des 2 float qui est à revoir, avec: - un float:left + largeur pour le conteneur - un flux + marge gauche pour la colonne de droite Au passage, le display:block sur les float est inutile: un flottant devient automatiquement un élément bloc.

L'origine du problème est une simple erreur d'utilisation du float dans: #Conteneur{ background : transparent; display: block; float: left; margin: 0 20em 0 0; padding : 0 0.4em 0 0.4em; text-align : left; } En effet, un flottant doit avoir une largeur explicite spécifiée par la propriété width (voir http://www.w3.org/TR/REC-CSS2/visuren.html#floats ) Faute de largeur spécifiée, il se trouve que FireFox/Mozilla applique (abusivement) le float en lui calculant une largeur à partir de sa marge droite... mais la modification de largeur du lien contenu dans un h3 remet en cause ce calcul. Le tout est remis en place quand tu survoles un lien du footer, le calcul étant à nouveau réactualisé. En ne codant que pour Mozilla/FireFox, tu joues en fait sur un bug de celui-ci qui devrait ignorer le float. Conclusion: développez vos CSS simultanément dans 2 navigateurs implémentant bien CSS, pour que les bugs de l'un soient immédiatement repérable d'après le comportement de l'autre. Le couple FireFox / Opera donne d'excellents résultats dans cette démarche. Sinon, pour que le résultat soit moins catastrophique dans IE, la suppression des sélecteurs d'enfant (>) inutiles fera déjà beaucoup.

Si tu as testé dans IE, c'est normal : son implémentation de display: table-cell est buggué. Cette propriété fonctionne en revanche dans Opera, Mozilla/Firefox, Safari...

Sans passer par le flux RSS, il suffit de récupérer le script d'affichage des derniers billets dans le template de DotClear, et de l'adapter à la page d'accueil du site.

Bon, si tu es revenu, j'y ai droit aussi : Pour flatter un peu plus ton égo ( ), et renseigner tout de même ceux qui s'égareraient sur ce fil où même les modérateurs dérapent, l'explication se trouve dans ce billet de Denis, où il détaille la mise en place de la diffusion du site Cybercodeur... en site vocal consultable au téléphone : C² accessible par téléphone. Le futur, c'était hier

Cette réputation de moindre permissivité du validateur WDG m'a toujours laissé songeur. Je ne la conteste pas a priori, mais sur quels tests s'appuie-t-elle ?

Vu que tu es à ma connaissance le seul blogueur à diffuser son site sur un media purement vocal, je pensais que tu sauterais sur l'allusion: il suffit de le faire en X Voice (XHTML + Voice, spécification pour des pages entièrement interactives à la voix) Bon, je -------> [] aussi

Pour la petite histoire, un display: table-cell permet de ramener la bordure d'un titre à son texte au lieu de l'étendre à la zone d'affichage.

<b> et <i> n'ont aucun rapport avec l'accessibilité, et sont de ce point de vue à peu prêt aussi neutre qu'un <span>. D'autre part, ils sont tout aussi modifiables qu'un autre élément par l'internaute via sa CSS user (actuellement très virtuelle car utilisée seulement par quelques geeks) : b { font-weight: normal; color: yellow submarine; smell: good; clignote: oui; Me fait un café: sans sucre, merci; } i { text-decoration: none; etc } Ce qui est erroné, c'est l'utilisation de <i> quand il s'agit de marquer une emphase <em>. En transitional, <i> est valide pour marquer une mise en italique... Et les choses deviennent beaucoup plus amusantes lorsque XHTML devient modulaire ( http://www.w3.org/TR/xhtml-modularization ) car rien n'empêche alors d'utiliser le module "presentation" ( http://www.w3.org/TR/xhtml-modularization/...sentationmodule ) ou même les antiques FONT et autres CENTER du module "legacy" ( http://www.w3.org/TR/2001/REC-xhtml-modula...#s_legacymodule ) Il faudrait, AMHA, cesser de se focaliser sur ces éléments de présentation conservés en (X)HTML transitional, ou se demander pourquoi ils y ont été conservés

Chiche qu'on fait une page navigable uniquement avec la langue ? (mais attention : elle ne peut pas bouger la souris ni appuyer sur le clavier)

"Stupide", on ne se permettra pas Disons plutôt très théorique et inutilement figé. Un détail m'échappe : puisque tu as décidé de recourir aux "position: absolute", pourquoi diable ne pas placer ta div .cent avant ta div left dans ton code HTML, ce qui te permettra d'avoir ton contenu principal avant tes colonnes de menu et d'info annexe dans les navigateurs et tous autres medias sans support CSS ? A part cela, le "height: 400px" ne sera pas interprété correctement ici et là, et provoquera bon nombre de collisions avec ton pied de page collé au pixel près juste en dessous... Pour te prémunir de ce type de problèmes en position:absolute, laisse ton .cent et ton .foot en flux (ce qui évitera tout téléscopage entre eux) et réduit la largeur du .foot à celle du .cent (pour éviter les chevauchement avec les colonnes). Il ne reste plus qu'à laisser tomber les height pour les colonnes (height est une propriété vraiment trop mal implémentée et d'un maniement de toute façon assez hasardeux sur le fond). Autre solution plus radicale : remonter le tout en flux+float si tu veux conserver un .foot occupant toute la largeur de la zone d'affichage sans risque d'empiètement.

Je ne comprends pas : - pourquoi la page d'index et pas les autres ??? Pourquoi là je suis "extrémistement standard" selon mon interprétation personnelle, et pas ailleurs ? - pourquoi proscrire <em> et <strong> ? Ils n'ont aucun rapport avec la dissociation de la forme et du contenu (ou plutôt, de la structure) ? Ces éléments sont valides, accessibles, propres sur eux, inoffensifs et tout ? Ils signifient une "emphase", donc une information ajoutée sur les termes concernés : attention, mot-clé ! - pourquoi procrire <i> et <b> ? Ils sont valides dans les doctype idoines avec les mêmes qualités que <em> et <strong> ? Et ils jouent actuellement exactement le même rôle signalétiques pour les moteurs de recherche.

Je ne vais pas être constructif, mais ce que je trouve sur cette page n'a aucun sens. La racine carrée à coup d'image et de CSS combinées ne figure pas dans le contenu, qui du coup est illisible. Il suffit de voir le résultat sans image ou sans CSS pour s'en rendre compte. Il existe une technique pour le langage mathématique : MathMl... évidemment très mal supportée selon les navigateurs, nécessitant de faire du XHTML1.1 que tous les navigateurs ne supportent pas... Il faut en convenir : nos navigateurs actuels ne nous permettent pas de diffuser proprement un contenu aussi élémentaire qu'une bête racine carrée. Que faire dans l'immédiat ? Des textes mis en images pour les formules mathématiques, dotés de alt="..." explicites sont encore les plus signifiants et les plus universels. Et les plus imprimables Même si ça n'est pas bien du tout, au regard des "SSStandards".

Qui a dit, déjà, que les tests ne prouvaient jamais que "l'aptitude à passer des tests" ? C'est amusant de constater à quel point les tests de recrutement sont surtout révélateurs de la crédulité de l'employeur envers tel ou tel discours magique emprunté aux "sciences humaines"

Bon, tu as l'air sûr de ton coup Alors il est tout à fait possible que le serveur ait été paramétré pour envoyer en en-tête HTTP un encodage par défaut (windows-1252) différent de l'encodage réel du fichier (iso-8859-1). Si c'est le cas et que l'encodage correct était spécifié par une <meta...>, il est facile de s'en assurer: le validateur HTML W3C valide la page, mais signale un "character Encoding mismatch!" Le WDG validator en revanche ne signale pas cette erreur. Or il me semble que c'est celui que tu utilises de préférence ?

Que quelque-chose doit m'échapper quelque-part En effet, ton site utilise de nombreux <strong> et <em> ... dont certains semblent uniquement là pour plaire aux moteurs de recherche: <h1><strong>création de sites internet </strong></h1> Un titre h1 se suffit à lui-même pour "l'importance" qu'il donne à son contenu. Y ajouter un <strong> est une redondance inutile, non ? Au passage, une erreur sur les accesskeys : <a href="creation-de-site-internet.php" title="création de site internet" accesskey="11"> Un accesskey (touche d'accès clavier) ne peut pas être une combinaison de caractères, mais doit correspondre à une touche "caractère imprimable" unique du clavier. Il est impossible d'utiliser un accesskey "11".

Sauf erreur de ma part, Gribouille26 travaille en transitional. L'élément <i> est donc parfaitement valide et adapté dans son cas. Je sais, c'est un élément de présentation... mais valide, efficace, simple, direct et parfaitement sans danger <edit> Ce n'est pas de la provocation ni de la malice de ma part : - vous-êtes vous demandé pourquoi certains "éléments de police" étaient restés en transitionnal alors que d'autres éléments présentatifs étaient exclus ? - n'avez-vous jamais eu besoin, pour traduire une certaine connotation d'un texte, d'autre chose qu'une emphase <em> ou <strong>, sans pour autant que cela puisse se réduire à une simple question de présentation graphique ? </edit>

Une page en php qui sert à créer et envoyer un document Web à un navigateur n'envoit rien d'autre que du (X)HTML. En fait, le PHP est totalement invisible au navigateur, puisque cette technologie ne s'exécute que côté serveur. Il n'y a donc aucune différence à faire pour le doctype entre une page statique HTML et une page dynamique PHP (ou aussi bien ASP etc.). Tu ne choisis ton doctype qu'en fonction du code HTML final.

Les navigateurs vocaux y seront indifférents...

Passer des tableaux aux sans tableau nécessite de renoncer à la mise en page pour les navigateurs de génération 4, dont le support CSS est beaucoup trop partiel et buggé. Voir à ce sujet l'article historique "fondateur" du mouvement en faveur de Standards HTML CSS : Envoyons paître les mauvais navigateurs Tu peux : - soit faire comme c'est devenu la règle, et adresser à IE4 etc une page HTML brute (qui reste parfaitement lisible et fonctionnelle) - soit continuer à utiliser les tableaux pour le positionnement de tes colonnes, mais en passant en CSS tout le reste de la mise en page (couleurs, espacements, fontes, effets...) A condition de ne pas imbriquer de tableaux, tu auras même une page accessible

J'imagine qu'il y aura d'autres choses à mettre dedans

Que diable mettrais-tu dans cette balise <noscript> liée à aucun script et n'ayant donc aucune action spécifique à accomplir ? Si le site est accessible sans javascript de manière transparente... à quoi bon en informer l'utilisateur qui ne se rendra même pas compte de la présence des bribes de javascript inertes chez lui ?