LaurentDenis

A quoi ça sert que Ducrot, y se décarcasse pour écrire des articles ? http://blog-and-blues.org/weblog/2004/09/24/304 <edit>Voir dans IE pour le rôle des float; dans les autres navigateurs, c'est en table-cell</edit> La technique des float est en fait la plus déroutante dans les schémas de positionnement CSS, et à ce titre souvent sous-employée parce que méconnue. Ce n'est évidemment pas la panacée (celle-ci n'existe pas, à moins de repayer le prix imposé par les tableaux en terme de lourdeur du code et d'inaccessibilité). Mais elle est souvent écartée a priori après des essais trop rapides.

Par curiosité : - pour quelle raison précise ce site ne peut-il pas utiliser une simple combinaison "float+flux" au lieu d'un double float qui empêche effectivement de générer une largeur dynamique à côté d'une fixe ? - sinon, pour quelle raison n'utilise-t-il pas un double float mais uniquement en dynamique ? Pourquoi ce menu en largeur fixe ?

Il y a décidément quelque-chose qui m'échappe dans le minimalisme de FireFox

N'importe quel navigateur peut être paramétré pour ouvrir le code source dans l'éditeur de ton choix.

Pour le curseur de souris biduleux, un simple #divCursor {display: none;} dans la feuille de style du forum règle le problème. Reste cependant à vérifier si ton contrat avec ton hébergeur t'y autorise. Par contre, rien n'empêche de l'ajouter dans sa CSS utilisateur "anti-gadget", ce que je m'empresse de faire dans Opera

Pour être tout à fait honnête, ce n'est pas si simple : tout va bien tant qu'on s'abstient de réclamer un padding et/ou des arrières-plans de couleurs différentes et/ou des bordures, et tant que les contenus du <p> et du <span> restent sagement chacun sur une seule ligne... Sinon, le problème devient nettement plus amusant. Essayons de styler les 3 cas de figures suivants, avec: - le span à gauche et le reste du paragraphe à droite (Eh non, pas le droit de mettre un span aussi pour le contenu de droite ) - une bordure autour du tout et une bordure verticale séparant les contenus gauche et droite. - deux couleurs différentes d'arière-plan - un padding pour chacun <p> <span>gauche</span> droite </p> <p> <span>gauche Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipitlobortis nisl ut aliquip ex ea commodo consequat.</span> droite </p> <p> <span>gauche</span> droite Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. </p> Comme souvent, les navigateurs les plus respectueux de CSS2 s'en tirent facilement, mais il reste à gérer la dégradation dans IE. J'ai une solution (imparfaite), mais je ne voudrais pas vous orienter a priori. Que proposez-vous ?

Et si vous faisiez simple ? p { background-color:#ccc; width:80%; text-align: right; } span { float:left; text-align:left; width:20%; } <p> <span>allo </span> OUIIIIII!!! </p>

En HTML-CSS, la police doit obligatoirement être présente localement pour être rendue par le navigateur. Il faudrait donc que tes visiteurs téléchargent et installent ta police "gothic". Mais devoir télécharger etc. pour voir une page web... incite surtout à ne pas voir la page en question Pour utiliser ta police de façon limitée, sur des titres par exemple, tu peux passer par des formats graphiques (textes en image, Flash, SVG...), mais ils posent chacun des problèmes d'accessibilité. Voir http://www.mikeindustries.com/blog/archive/2004/08/sifr pour une technique de remplacement des titres en Flash, et http://www.blog-and-blues.org/weblog/2004/08/31/293 sur le problème d'accessibilité. Sinon, au cas où tu tomberais là-dessus, CSS2 intégrait un mécanisme de téléchargement automatisé (@font-face)... qui n'a jamais été implémenté sauf dans IE et encore, d'une manière à le rendre à peu près inutilisable (la police de caractère doit être convertie dans un format spécifique propre à Microsoft, et la qualité s'en ressent). Voir la discussion sur ce sujet dans http://www.webmaster-hub.com/index.php?showtopic=3584

SVG est simplement un format graphique vectoriel comme Flash, mais avec l'avantage d'être du XML en bonne et due forme. Il est encore peu utilisé aujourd'hui, surtout faute d'outil d'édition.

Ceci devrait faire l'affaire: body { padding: 0; font-size: 0.8em; margin: 5% 6% 0 6%; font-family: Arial, Helvetica, sans-serif; } #conteneur { border: black 2px solid; background-color: #e6e7d5; } #header { background-image: url(fine0000.jpg); background-repeat: repeat-x; } #header img { vertical-align: bottom; } #gauche { width: 140px; float:left; } #centre { border: black 2px solid; border-right-width:0; border-bottom-width:0; margin-left:140px; background-color: #acd8f5; } h1 { font-size: 1.5em; font-weight: bold; text-align:center; margin-top: 0; padding-top: 1em; } <div id="conteneur"> <div id="header"> <img src="plage000.jpg" class="header01" alt=""> </div> <div id="gauche"> - la marge de droite en trop dans IE5.5-60 est due au box-model IE et à la largeur 94% inutile sur #conteneur --> supprimée, les marges du body étant augmentée en conséquences. - la marge inférieure en trop dans IE5.5-6.0 est due à l'alignement du bas de l'image du header sur la "baseline" du texte de #header : il reste un espace de quelques pixels en dessous où s'affichent les jambages inférieures des lettres --> spécifier un vertical-align: bottom pour cette image. - IE5.0 gère mal la marge supérieure du h1 et crée un autre espace vide entre #header et #centre: remplacer cette marge par un padding-top. - IE5.0 encore a du mal avec la marge gauche de #centre : la réduire de 150 à 140px. - au passage, ajout d'un alt="" pour l'image (accessibilité), et suppression du "left: 0px;" dénué de sens dans #gauche (c'est un flottant, il n'a pas de propriété left).

L'utilisation des em ne peut avoir aucune influence sur ton problème de titre, pas plus qu'une autre unité. Aurais-tu une page d'exemple ? Et veux-tu dire: - que tes titres ne s'affichent pas avec la taille voulue ? - ou qu'ils ne sont pas modifiés comme tu l'attends quand tu utilises la commande Afficher > Taille des caractères du navigateur ?

C'est normal: float est fait pour ça. Un float dimensionné en % résoudra le problème, tant qu'il ne sera pas réduit en-dessous de la largeur du mot le plus long qu'il contient (mais c'est illisible longtemps avant).

Indigeste ? Je ne sais pas... Pour l'instant, je digère doucement mais sûrement les deux premiers articles. Complexe, inhabituel pour le webmestre et donc déroutant ? oui sûrement. Mais surtout passionnant et instructif ! Je sens que j'ai de quoi de prendre la tête utilement pendant mes longues soirées d'hiver rural, ce qui est toujours une bonne nouvelle. Surtout, ne t'arrête pas

Nos excellents spécialistes du Hub me corrigeront si je me trompe, mais il me semble que la stratégie de Google repose en grande partie sur l'obscurité de son fonctionnement. En ce sens, Google est un peu l'archétype de la technologie propriétaire, et un bon candidat à la diabolisation facile après Microsoft : - code-source opaque et mesures de rétorsions contre toute tentative de le manipuler, - clients maintenus sous dépendance, - évolutions imprévisibles, et finalement, grossse prise de risque pour ceux qui optimisent leur pages spécifiquement pour Google : j'ai cru comprendre que le marché des moteurs de recherche était plutôt volatile... que se passera-t-il demain ?

Ah... Excuses-moi, je ne suis pas toujours très clair. Pour être honnête, je suis (involontairement) très orienté sur une utilisation bien précise de ton script : on m'a demandé le CMS d'un photoblog à base de DotClear... où ton script conviendrait très bien au cahier des charges de la page d'accueil Donc mon idée de page HTML complète pour chaque image allait effectivement avec l'idée d'un site dynamique. Mais tu as tout à fait raison : dans la version de base actuelle de ton script, l'affichage brute des images en grand format est effectivement une dégradation tout à fait acceptable dans les navigateurs graphiques sans javascript activé. Surtout que je ne compte plus les modèles de galeries de photos que j'ai regardées et qui sont à peu près inutilisables hors d'une configuration utilisateur bien précise Pour l'accessibilité: - la liste non ordonnée serait impeccable. - pour inciter les gens à bien utiliser l'attribut alt, que dirais-tu de mettre pour les miniatures quelque-chose comme alt="Ecrivez ici la description de la miniature" (et sur le même principe pour les images en taille normale) ?

Le peu que l'on puisse dire de l'algorithme de Google Image, c'est qu'il exploite un peu tout et n'importe quoi On trouve selon les recherches, dans la première page de résultat : - des images au nom significatif aussi bien que d'autres au nom dénué de sens, avec ou sans attribut alt... - des images se trouvant dans un contexte de page très significatif, ou dans un contexte sans aucun rapport avec l'expression recherchée... - des images effectivement présentes dans la page avec un <img...>, ou simplement cible d'un lien contenu dans la page... Bref, Google, à son habitude, semble avoir élaboré tout un ensemble de stratégies très hétéroclite, qui n'exploitent pas de manière cohérente ou systématique les éléments "sémantiques" du HTML comme "alt". Peut-on se risquer à recommander quelque-chose ? A quoi cela servirait-il de dire : - que renseigner correctement l'attribut alt ne nuira pas au référencement, l'aidera peut-être, mais pas forcément. (en revanche, ce sera indispensable pour d'autres raisons telle l'accessibilité) ? - que nommer son image de manière significative ne nuira sans doute pas non plus, mais ne servira pas forcément ? - que le contexte de l'image a apparemment un poids important... mais pas forcément ? Il y a beaucoup trop de "peut-être" et d'incohérences pour que ce soit autre-chose qu'une sorte de roulette russe

Je crois que c'est une très belle utilisation de javascript : - effectivement non obstructive - simple (pas de traitement trop lourd côté client) - et qui apporte vraiment quelque-chose à l'utilisateur. Ce n'est pas si souvent qu'on voit ce genre de script Bravo ! Pour améliorer, quelques pistes auxquelles tu as peut-être déjà pensé : - éviter les liens adjacents pour les miniatures et revoir les textes des alt pour les rendre plus signifiants. - mettre en lien des miniatures non pas l'image brute mais une page en bonne en due forme. Peut-être sous la forme "images/photo1.html", le script se chargeant de modifier l'extension en "photo1.png" ? Cette page "vue en taille normale" pourrait comprendre, outre l'image en taille normale et les éléments de navigation du site : - le descriptif texte de l'image (pour évacuer le problème du "longdesc") - les liens vers les vues normales de l'image précédente / suivante. Bref, elle donnerait au visiteur sans javascript (et aux lecteurs d'écran...) une expérience de navigation aussi confortable qu'au visiteur avec javascript. Tiens, au passage, dans un photoblog, je verrais bien les commentaires dans cette page "image agrandie"...

3 éléments de réflexion sur le sujet : - Les statistiques de fréquentation par navigateur sont à manier à beaucoup de précautions, en raison de leur très fréquent manque de fiabilité : dans la plupart des cas, les scripts utilisés n'exploitent pas correctement les identifiants HTTP des navigateurs. Sans compter que tous les navigateurs ne sont pas identifiables (masqués par un firewall par exemple). - as-tu la certitude que cette proportion n'est pas susceptible de changer ? Autrement-dit, qu'investir dans un site optimisé pour un navigateur unique est n'est pas un pari risqué ? - Si le site en question a une présentation défectueuse dans les autres navigateurs, il est logique qu'il attire peu de visiteurs utilisant ceux-ci

Un problème de "modèle de boîte", c'est à dire de mode de calcul des dimensions de ton #barredegauche et de ton #main différent dans IE Windows et dans les autres navigateurs. Tes largeurs étant calculées au pixel près dans un conteneur rigide (720px), ça ne pardonne pas Tu peux y remédier au plus simple en indiquant des largeurs différentes réservées à IE à l'aide d'un hack. Par exemple: #main { width:500px !important; width:450px; } #barredegauche { margin-left:519px !important; margin-left:469px; width:200px; } Autre syntaxe de hack possible, sur le même principe : #main { width:450px; } html>body #main { width:500px; } #barredegauche { margin-left:469px; width:200px; } html>body #barredegauche { margin-left:519px; } J'y suis allé un peu à la louche en mettant a priori 50px de moins pour IE. Tu pourras calculer ça plus finement à partir des indications données dans http://www.openweb.eu.org/articles/dimensions_boites_css/

La réponse s'appelle je crois "spam indexing" : polluer les stats d'un site serait paraît-il aussi profitable que spammer les commentaires, les wiki, les forums, etc.

Aurais-tu un exemple de page ? Un peu de code ? J'ai l'impression que tu as dû mettre quelque-chose comme un * {font-size: 1em;} dans ta CSS, non ?

Bon, on va quand même dire, pour le principe, que : - html>body est un sélecteur CSS tout à fait valide et normal (à la différence de nombreux autres hacks). L'élément html existe, l'élément body est son enfant, et > signifie bêtement "le body enfant d'un html". - Mais il se trouve qu'Internet Explorer Windows (toutes versions actuelles) ne connaît pas le sélecteur d'enfant >, et qu'il ignore les règles CSS qui suivent celui-ci. Donc: html>body p { color: red; } mettra tous les paragraphes en rouge, sauf dans IE.

ElMoustiko va finir par croire que je le poursuis pour le persécuter Mais : ça ne marche pas, comme l'a dit Raphael, seulement parce que "content" n'est pas supporté par IE. En revanche, l'utilisation du point virgule dans la CSS ci-dessus est tout à fait correcte: - c'est un séparateur qui n'est requis que lorsque plusieurs propriétés CSS se suivent - et qui est inutile lorsqu'une règle CSS ne comporte qu'une seule propriété, ou pour la dernière propriété de la règle. Cela dit, pour ma part, je mets toujours le point virgule, même lorsqu'il n'est pas nécessaire... histoire d'en faire un automatisme et de ne pas risquer de l'oublier quand il est indispensable

Hola ! ça n'est pas du tout ça Le sélecteur universel * désigne "tout élément", y compris le conteneur initial de la page, c'est à dire le <body> (en HTML) ou le <html> (en XHTML). Son utilisation n'a rien d'un hack : * { border 1px solid; } ...donnera une bordure à tous les éléments susceptibles d'en avoir un. .blabla * { border 1px solid; } ...fera la même chose mais uniquement dans les conteneurs de classe "blabla" Pour le * selecteur { propriété ; }, il fonctionnera dans tous les navigateurs (heureusement, puisqu'il veut simplement dire "tel élément situé dans n'importe quel élément"), mais ne servira à rien puisqu'il signifie aussi "tel élément situé dans le body". Maintenant, il y a une syntaxe absurde en CSS, qui est en fait * html img {...}, qui signifierait "les images contenues dans un élément html lui-même contenu dans n'importe quel élément". Or l'élément html est l'élément parent du document, et n'est contenu dans rien. Cette syntaxe renvoit donc toujours un résultat vide... sauf dans Internet Explorer Windows 5.0 à 6.0, qui le lit comme si c'était un simple img{}. IE est donc le seul à appliquer les propriétés spécifiées à l'aide de cette syntaxe. Cela dit, c'est un hack à proscrire, car il repose sur une syntaxe détournée, aux effets imprévisibles dans les navigateurs futurs...

RSS ne sert pas spécialement à diffuser des "résumés", et peut aussi bien diffuser le contenu intégral des documents. C'est d'ailleurs préférable, dans la mesure où les agrégateurs évolués deviennent des outils de surf à part entière... D'autre part, RSS ne vise pas uniquement les agrégateurs personnels, mais aussi les sites de syndication qui rassemblent le contenu de plusieurs sites "individuels".