Aller au contenu

LaurentDenis

Membres
 Afficher le profil  Parcourir son contenu

  • Compteur de contenus

    1 281

  • Inscrit(e) le

  • Dernière visite

 Type de contenu 

Tout ce qui a été posté par LaurentDenis

  1. LaurentDenis
    Je vais sembler un peur dur, mais je ne suis pas allé plus loin que la page d'accueil tunnel en flash et son "Patientez svp LOADING 27 KB OF 139 KB" Une telle page: - est inaccessible en dehors d'un navigateur graphique doté du plugin flash activé - n'a aucun contenu utilisable pour un moteur de recherche - ne fait qu'obliger le visiteur à attendre devant la porte avant de devoir l'ouvrir lui-même pour entrer enfin et voir de quoi il s'agit. - est généralement zappée, comme toutes les intro flash, par la majorité des visiteurs qui reviennent. Une page d'accueil est plutôt à la fois : - le reflet de l'essentiel du contenu du site, directement accessible (donc en texte) - l'une des pages carrefours permettant de s'orienter dans le site
  2. LaurentDenis
    Une règle "color: #fff"de ta feuille de style figure sans doute sous un sélecteur trop général (body probablement). Tu peux: - utiliser deux feuilles de styles différentes - ou utiliser un sélecteur spécifique pour les pages de ton site, absent sur ton forum (ou l'inverse). body#site { color: #fff; } et <body id="site"> ou au contraire: body#forum { color: #000; } et <body id="forum">
  3. LaurentDenis
    Microsoft ne publiant (actuellement) aucune roadmap sur l'éventuelle futur version de son navigateur, je ne vois vraiment pas qui pourrait prétendre pouvoir répondre à ce genre de question. Rien n'empêche, en revanche, de faire remonter ce genre de besoin auprès de Microsoft, par exemple sur Channel9. En revanche, diaboliser un navigateur me semble totalement improductif : on fait beaucoup mieux la promotion des CSS en montrant comment (et dans quelle mesure) elles permettent de s'adapter à moindre frais aux inévitables différences de support dans les navigateurs (dégradation correcte de la présentation) sans retomber dans les versions multiples du "cross-browser" d'antant.
  4. LaurentDenis
    Supprime les positions absolues inutiles, et laisse faire le flux. Utilise position:relative pour obtenir un conteneur positionné. #conteneur { position: relative; margin: 5% 5% 0 5%; width: 90%; background-color:#E6E7D5; border: 2px solid black; }
  5. LaurentDenis
    C'est le prix à payer pour avoir une syntaxe de saisie capable de générer un code relativement complexe : elles nécessitent finalement de la part de l'utilisateur le même apprentissage et la même rigueur que s'il travaillait directement en HTML. A l'inverse, les syntaxes wiki peuvent être "autovalidantes" (fermeture automatique des tags laissés ouverts, annulation des imbrications...) mais limitent le code produit à un "template" parfois très réducteur (à l'extrême, une div ne contenant plus qu'un niveau de titre, un paragraphe et des <br>). Quelques bémols. Les formulaires : <!-- Formulaire de recherche --> <p class="recherche">Recherche générale :</p> <form action="recherche.php3" method="get"> <p style="margin: 0;"><input type="text" style="font-size:97%" name="recherche" value="Activité, Ville ou mot-clé" onfocus="this.value='';" /><input type="submit" class="rechok" value=" ok " /></p> </form> - Virer le texte par défaut : cette recommandation WCAG1 est une des plus critiquée, qui disparaît dans la prochaine version WCAG. Elle gêne finalement plus l'utilisateur qu'elle ne sert. - réorganiser le formulaire pour y placer un <label> explicite. Le menu "Retour à l'accueil |Contacts |Espace privé"... ne flotte pas dans Opera < 7.60. Voir http://blog-and-blues.org/weblog/2004/08/2...bug-float-opera (explications dans un commentaire). La largeur donnée à #menuhaut doit être donnée au <ul>.
  6. LaurentDenis
    Ah, je parie pour un bug dû à la majuscule : href="/css/majeur.css" au lieu de href="/Css/majeur.css"
  7. LaurentDenis
    Bah... Je vais documenter ça. Exactement. Le "hack" est des plus légers, puisque qu'en fait il n'y a aucun code détourné : - IE prend naturellement dans la CSS ce qu'il comprend (le float) et laisse le reste (le table-cell) - Un innocent html>body est nécessaire pour cacher le float... à Mozilla, qui s'empatouille dedans. Bien-sûr : Colonnes de même hauteur (variante) La colonne de droite a une largeur fixe en pixels (mais pas dans IE où elle reste proportionnelle). On pourrait encore plus facilement donner une largeur fixe à la colonne de gauche (et là, ce serait bon aussi dans IE). Au passage, les "petites" largeurs en em sont un peu dangereuses : la colonne peut être plus large que prévue si l'utilisateur n'a pas exactement les polices spécifiées dans la CSS, et que la police de substitution choisie par le navigateur est plus ample... Une coquille C'est évidemment 1px. A l'origine, si je me souviens bien, j'avais dû faire des bordures de 10px partout pour tester la résistance au box-model microsoft.
  8. LaurentDenis
    href="/css/mafeuille.css" (si le répertoire nommé "css" est à la racine du site)
  9. LaurentDenis
    Bon, je savais bien qu'il faudrait un exemple : Colonnes de même hauteur. "en-dessous" voulait dire "verticalement", pas dans le sens d'un empilage de div
  10. LaurentDenis
    Voir sur ce forum Problème de listes décalées vers la droite
  11. LaurentDenis
    Je dois manqer un peu d'imagination : ce serait bien de décrire un peu plus précisément ton problème, ou mieux, de donner un lien dans une page test.
  12. LaurentDenis
    Pourrais-tu préciser ? Voire donner un exemple précis et commenté ? Ce serait intéressant et utile : personnellement, je voyais plutôt le Hub comme très peu théorique
  13. LaurentDenis
    Je titille Sibelius pour le plaisir, mais cet excellent article est tout aussi valable en gérant son multi-colonnage... en float plutôt qu'en position:absolute
  14. LaurentDenis
    Jamais si footer est en flux+clear:both et si les colonnes sont en flux ou float : - le footer sera forcément en dessous de la colonne en flux - ET (inclusif) il sera forcément en dessous de la colonne en float la plus "longue". Dans IE, et autres navigateurs ne supportant pas "display:table" etc., les colonnes en float et en flux ne seront pas d'égale hauteur, et le footer sera en dessous. C'est tout. Ce sera juste parfois un peu moche selon le style du conteneur ou du body. Bon, maintenant, je suppose que tu ne seras pas convaincu tant que tu n'auras pas un exemple sous les yeux... Et si tu l'écrivais, cet exemple, histoire de te réconcilier avec les float ?
  15. LaurentDenis
    CSS est un outil de présentation, pas un outil "d'assemblage" HTML à la manière des frames. Il n'y a aucune solution à chercher de ce côté. A tout prendre, sur les bases que tu décris, le plus accessible (ou le moins inaccessible), reste un frameset bien conçu.
  16. LaurentDenis
    Avant d'en venir aux mains, permettriez-vous à un ex-intégriste de proposer ce qui suit, et qui n'est qu'une reformulation de vos propos respectifs ? Les propriétés CSS simulant un tableau (diplay: table-cell, etc) permettent effectivement de gérer les hauteurs dans un multicolonnage, comme Raphaël le souhaite. Mais il est vrai qu'elles ne sont pas supportées par certains navigateurs. Donc : - le rendu recherché est obtenu dans les navigateurs qui en sont capables, - il se dégrade tout à fait correctement (sans obstruction) dans les navigateurs qui ne le peuvent pas, en attendant qu'ils améliorent leur support de CSS C'est peut-être cela qui compte le plus dans CSS screen: cette idée de "dégradation non obstructive" selon les capacités du navigateur graphique, qui libère l'auteur de l'obsession d'un rendu identique et illusoire dans toutes les configurations utilisateurs.
  17. LaurentDenis
    pourrais-tu donner un exemple de ton code ? Il serait plus facile de voir où se trouve le problème.
  18. LaurentDenis
    Ne t'excuses pas: c'est moi qui ai ouvert cette parenthèse J'aurais dû créer tout de suite un nouveau sujet, ce qui est fait à présent. La question de "l'intégrisme" dans la promotion des Standards Web est intéressante, sans mauvais troll. Une réaction à cet intégrisme qui a fait date, et reste passionnante : W3C go home, c'est le HTML qu'on assassine
  19. LaurentDenis
    La suite de cette discussion portant sur le sujet "C'est bien, c'est mal de penser ça" a été déplacée dans un nouveau sujet.
  20. LaurentDenis
    Je n'ai jamais observé personnellement ce comportement d'un navigateur, mais il est logiquement tout à fait plausible : lorsque le navigateur s'appuie sur la meta pour déterminer l'encodage de la page, il ne devrait pas être capable d'interpréter correctement le contenu du <title> si la meta n'a pas été lue d'abord. Sauf que... - l'encodage éventuellement spécifié directement au niveau serveur l'emporte - en xml / xhtml, l'encodage peut avoir été spécifié par le prologue xml en tête de page - les navigateurs ont parfois des procédés de détermination de l'encodage qui échappent aux normes (par exemple, forcer un encodage windows par défaut sur un contenu sans encodage spécifié, ce qui coïncide souvent avec la réalité...).
  21. LaurentDenis
    Il est compris, oui, comme tout autre élément HTML standard. Le problème est de savoir s'il sera exploité avec le sens que tu lui a prêté. En tant que liste de définition au sens strict, oui. En tant que dialogue, peut-être. En tant que 'titre" ou que "sous-titre" d'une section de page, ce ne sera pas le cas.
  22. LaurentDenis
    Je suis mal réveillé d'une grosse sieste, mais j'ai du mal à te suivre, là ? Pour les navigateurs graphiques actuels avec CSS activée, que ce soit un <dl>, un <span> ou même en HTML un bon vieux <FONT size... avec des <BR> n'y change strictement rien, la seule exploitation faite étant celle du rendu visuel. Dans un navigateur sans CSS, <dl> ne fait qu'induire un rendu visuel par défaut, le plus souvent à base d'indentation des <dd>.... On peut dire en résumé que les navigateurs n'exploitent pas plus <dl> qu'autre chose. Le robot / système d'indexation d'un moteur de recherche, lui aussi, est un agent utilisateur. Celui de Google:definition retient spécifiquement les documents structurés avec <dl> en tant que sources pertinentes (ce n'est pas son seul critère, voir le lien de mon message précédent). C'est en ce sens que Google:definition est un des rares exemples d'outil exploitant le sens spécifique de <dl>
  23. LaurentDenis
    Nous débordons du sujet de ce fil... pour lequel nous pourrions ouvrir un nouveau sujet si la discussion se poursuit. Mais le petit monde des Standards francophone souffre effectivement d'une maladie de jeunesse : l'abus de prescriptions et de proscriptions, avec un certaine tendance à réécrire les 10 Commandements toutes les 5 minutes, de préférence en inventant ce qui n'est pas dans les specs C'est une sorte de surenchère dans la normalisation, peut-être pour compenser le remords d'avoir codé en toute anarchie pendant des années Cela dit, je crois que rares sont les promoteurs des Standards qui ne sont pas passés par là (moi le premier), et pour qui c'est encore un écueil fréquent (idem). Il faudrait prescrire moins, et expliquer plus. A partir de là, chaque concepteur doit être à même de prendre ses décisions face aux nombreuses incertitudes, défauts d'implémentation, voire erreurs des specs.
  24. LaurentDenis
    Bonne question : quel(s) outils, à part Google:definition, prennent-ils en compte les listes de définitions à l'heure actuelle ?
  25. LaurentDenis
    Ma formulation était humoristique : loin de moi l'idée de dire que "c'est mal de penser comme ça"
×
×
  • Créer...