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
    La réponse finale et concise est donc : tu ne peux pas techniquement cacher ton code pour protéger tes droits à son égards, parce que les techniques en question sont inefficaces dans ce cas, et que ce n'est pas le rôle de la technique, mais plutôt de l'arsenal "juridique" à ta disposition : licences, etc... Chacune est évidemment totalement libre d'être juge en ce qui le concerne de l'intérêt d'Opquast, de ce qu'il en fait personnellement, etc. En revanche, il est faux de le qualifier de "donneur de morale". Les BP Opquast ont ceci de très nouveau qu'elles ne reposent pas sur un jugement subjectif individuel, du type "gourou de l'utilisabilité" : elles font au contraire l'objet de discussions et d'évaluations appronfondies de la part de tous les auteurs Web qui souhaitent y apporter leur contribution. Elles reflètent donc un état de la réflexion des "gens du métier", mais pas un jugement péremptoire disant "c'est bien, c'est mal".
  2. LaurentDenis
    Voir dans le terme "transitional" un jugement de valeur me semble assez surprenant : faut-il rappeler que le rôle principal du passage du transitional au strict est dans l'abandon des attributs/éléments uniquement présentatifs ? Ce terme traduit simplement le fait que les DTD transitional font la transition entre le HTML présentatif et le (X)HTML strict séparant présentation et contenu.
  3. LaurentDenis
    Il y a maldonne sur le rôle des Standards, là : - sur l'exemple du target, les "Standards" ne tranchent absolument pas pour ou contre, et laissent au contraire toute liberté aux auteurs de choisir une norme qui l'autorise (transitional) ou non (strict). D'ailleurs, un module spécifique XHTML garantit pour l'avenir que ce choix restera disponible après XHTML1.0. - plus généralement, les Standards n'imposent pas de modèle de contenu ou de comportement. Ils demandent en revanche que les auteurs assument au mieux leurs choix en les conciliant avec la nécessité d'un socle technique commun à tout le Web.
  4. LaurentDenis
    Il y a des fois où je me dis que j'ai raison de préférer le validateur du W3C
  5. LaurentDenis
    Plus simple... peut-être pas tant que cela. L'ajout de l'attribut border sur l'élément <img> directement dans le code HTML a un petit inconvénient (entre-autres) : tu devras le répéter pour chaque image lien. Tandis qu'un style CSS du type img {border: 0;} supprimera cette bordure indésirable d'un seul coup : - pour toutes les images de la page si le met dans un <style type="text/css">...</style> de sa section <head> - pour toutes les images de toutes les pages de ton site si tu le mets dans une CSS externe appliquée à celles-ci.
  6. LaurentDenis
    Ce n'est pas tout à fait ça. Pour n'afficher le contenu que dans IE5.0 et EI5.5, il faut utiliser la syntaxe disant "IE et version strictement inférieure à 6", c'est à dire: <!--[if lt IE 6]>...<![endif]--> Attention Denis: si tu as plusieurs IE installés simultéement, ils se comportent vis à vis des commentaires conditionnels comme s'ils étaient tous IE6... Monique: la syntaxe que tu cite est celle du "downlevel-revealed" qui sert au contraire à cacher le contenu du commentaire à IE... et qui est surtout invalide en HTML Bon, tant que j'y suis, les commentaires conditionnels à utiliser sont typiquement selon la cible: <!--[if gte IE 5]> pour afficher le contenu dans IE 5.0 55.5 et 6.0 <!--[if IE 5]> pour IE 5.0 <!--[if IE 5.5000]> pour IE 5.5 <!--[if IE 6]> pour IE 6.0 <!--[if gte IE 5.5000]> pour IE 5.5 et 6.0 <!--[if lt IE 6]> pour IE 5.0 et 5.5
  7. LaurentDenis
    Avant de regarder plus précisément : corriger le code HTML invalide (voir http://validator.w3.org/check?uri=http://n...hp?page=contact ), et si nécessaire le code CSS.
  8. LaurentDenis
    Il en est du javascript comme des images, du texte, et de tout ce qui parvient côté client : c'est fait pour être exploité/exécuté ou rendu... et c'est donc inévitablement et heureusement disponible à partir du navigateur. Certes, tu trouveras une ou deux bidouilles du type interdire le clic droit... qui ne feront qu'alourdir ta page et gêner les utilisateurs (pour imprimer, ouvrir un lien dans une nouvelle page...) mais qui seront totalement illusoire pour empêcher l'accès au code source. Au fait, pourquoi vouloir cacher ces javascripts ? Feraient-ils quelque-chose de vraiment très très honteux ?
  9. LaurentDenis
    Pourquoi ne pas simplement et logiquement : - garder tes div gauche en float et droite en flux - intégrer ton div menu_bas (en flux) dans le div centre en le dotant d'un clear:both
  10. LaurentDenis
    Je reste sur cette idée simple: un site a un menu de navigation, pas deux ou trois. Un, c'est déjà suffisamment difficile à gérer, aussi bien pour l'auteur que pour l'utilisateur Si, donc, un menu unique est variable selon la rubrique : - il doit avoir d'abord une permanence, c'est à dire les items de navigations communs à tout le site, en premier. - puis il se poursuit en se déclinant selon la rubrique, avec des séries d'items différents. De la sorte: - En page d'accueil, carte, Accessibilité... bref, toutes pages hors-rubrique, seule la partie générique apparaît. Dire qu'un sous-menu apparaîtra si on clique quelque-part ne sert pas à grand-chose, sauf à plonger l'utilisateur dans la perplexité : "qu'est-ce que c'est que ce menu qui avait l'air simple, et qui serait plus compliqué qu'il n'y paraît ?" - En page "rubriquée"... l'utilisateur soupire d'aise en retrouvant son menu générique (ses repères, ses marques...), et porte son attention sur le menu spécifique qui le suit ("tiens, il y a plus à voir ici ? Voilà qui n'est pas bête !"). Finalement, ce n'est ni un problème de structure ni un problème de présentation : c'est un simple problème d'ergonomie (ou de qualité, si on veux).
  11. LaurentDenis
    Pourrais-tu donner l'url d'une page de test ? Il est tout à fait logique que la hauteur de ton conteneur #centre soit indifférente au contenu flottant: float est fait pour ça, et le clear:both sur un 3e élément de contenu est la solution logique. Mais cette histoire de marge n'est pas très claire
  12. LaurentDenis
    Un point important qui me semble oublié ici: le DirectoryListing est plutôt suprenant pour des utilisateurs ayant compris qu'on pouvait modifier l'url afin de remonter au sommaire d'une rubrique, en transformant http://www.example.org/rubrique/blabla.html en http://www.example.org/rubrique/ Là où on s'attend à y trouver une page en bonne et due forme, on tombe sur un affichage crytpique
  13. LaurentDenis
    ce sont deux problématiques différentes, AHMA : - le contenu précède les menus car il faut simplement qu'il soit restitué en premier dans les medias non CSS, pas pour le particulier et le général, mais pour que la page ne soit pas au premier regard "toujours la même" avec son fichu menu au premier écran (il faut naviguer avec un navigateur texte pour en faire l'expérience) - le menu "principal" passe avant le menu spécifique des rubriques, parce qu'il y a effectivement là le jeu du "général" qui passe avant le "particulier", le répertoire racine accessible avant les sous-repertoire, le menu avant le sous-menu, etc. Bravo ! Saine réaction
  14. LaurentDenis
    Même remarque que précédemment. Ce code : - est finalement plus lourd (d'un poil) qu'une simple alternance titre / liste - sera moins accessible et efficace qu'une simple alternance titre / liste navigable via les titres. On pourrait rétorquer qu'en bonne logique, un navigateur (graphique, vocal ou autre) devrait être capable d'extraire aussi bien les <dt> que les <h2>, <h3>... d'une page, et devrait permettre de naviguer entre ceux-ci... Sauf que ce n'est pas le cas aujourd'hui, et que nous codons aujourd'hui. Demain, nous coderons en XHTML2.0, dans un contexte très différent
  15. LaurentDenis
    Sauf qu'il faut faire avec la technique disponible, et qu'HTML4.01, et par là également XHTML1.x, sont des langages de structuration à peu près "plats", sans notions de "sections" hiérarchisées et titrées. C'est frustrant, certes, mais c'est comme ça. Utiliser <dl> à cette fin revient à tenter de transformer HTML4.01 et XHTML1.x en XHTML2.0 (élément <section> et titres <h>)... ce qui ne relève guère que de l'exercice de style (ce qui n'ôte rien à son intérêt dans ce cadre étroitement "expérimental", mais qui le déconseille en situation de production réelle).
  16. LaurentDenis
    Hum... J'aurais envie de dire que les meilleures solutions sont généralement les plus simples et les plus communes: les listes de définitions utilisées pour le menu de navigation n'apportent pas grand-chose du point de vue "sémantique"... Elles n'apportent en tout cas rien de plus que de simple titres <h2>Navigation</h2> et <h3>Menu général</h3>, <h3>Menu de rubrique</h3> avec des listes <ul>. En fait, elles sont moins accessibles que ceux-ci, puisque de nombreux lecteurs d'écrans permettent de naviguer à travers les titres d'une page. Le menu de rubriques ne devrait pas apparaître en page d'accueil, puisqu'il est vide dans ce cas. Il serait par ailleurs mieux placé après le menu général qu'il développe (aller du général au particulier). Idem pour le pied de page : quelle est l'information ajoutée par le choix d'une liste de définition au lieu de simples paragraphes ou listes ? Les liens d'accessibilité gagneraient à être regroupés dans un menu unique en tête de page, incluant " Raccourcis", "Plan du site", "Aller au menu général". La page "politique d'accessibilité" relève plutôt du menu général. Au passage, attention à éviter les liens différents ayant le même intitulé (2 liens Accessibilité pointent vers des cibles différentes), dont la répétition est peu compréhensible hors contexte. Enfin, sur le fait d'éviter autant que possible <div> et <span>: - Il y a un "anathème" excessif sur ces éléments qui sont explicitement destinés à permettre d'ajouter du style (ou du sens). Certes, il ne faut pas "remplacer" un élément HTML significatif par un <div> ou un <span>, et il est plus élégant de styler directement les éléments existants que d'ajouter des éléments neutres... Mais il ne faut pas tomber dans une chasse aux sorcières - En revanche, le <div id="conteneur"> me surprend... puique la page est naturellement déjà contenue dans son body
  17. LaurentDenis
    Impression immédiate: c'est plutôt réussi, mais le chevauchement des colonnes et du bandeau supérieur donne davantage l'impression d'un bug de rendu que d'un effet graphique voulu... Le vide à droite du bandeau également. Par ailleurs, le contraste texte blanc/couleur d'arrière-plan risque d'être très insuffisant pour une lecture agréable: - des citations du bandeau d'en-tête - des "liens utiles"
  18. LaurentDenis
    Je ne crois pas qu'Arlette t'en ai voulu C'est juste qu'être modérateur n'est pas si facile, ni si simple... Et que si modérateurs bénéficient du fait d'être une communauté qui s'entraide dans ce rôle, cela n'empêche pas les avis extérieurs d'être toujours intéressants pour mieux mesurer la portée de nos interventions. C'est le grand mérite des utopies qui durent: elles cessent d'être des utopies en se dotant de mécanismes de contrôle En es-tu sûr ? Pour ma part (en tant que visiteur), je me suis longtemps désintéressé des forums en raison justement de leur proportion trop importante de contenu sans intérêt. Oui, c'est grave, c'est à dire pas innocent ni insouciant. Disons que c'est important (sans oublier cependant de ne pas toujours se prendre au sérieux dans ce rôle). Des règles du forum. Elles ne sont certes que des conventions, mais une convention est un peu plus qu'un jugement subjectif: c'est quelque-chose d'explicite, que l'on peut décider d'accepter ou de refuser en connaissance de cause. Tout comme l'une des libertés d'une communauté est de fixer une exigence de qualité vis-à-vis d'elle-même. Donc de ne pas accepter tous ses propres comportements potentiels. Pas tout à fait: disons que l'utopie mûrit, accepte de se confronter aux problèmes réels et de tenter d'y répondre. Du coup, elle cesse en effet d'être une utopie, mais elle devient quelque-chose de plus réfléchi et de plus riche.
  19. LaurentDenis
    J'en profite pour rappeler le réflexe immédiat à avoir lorsqu'on a un problème de syntaxe sur une propriété CSS : aller dans l'index des propriétés de la spécification CSS2 (en français), et suivre le lien sur la propriété en question, ou sur une propriété qui vous inspire tout à coup davantage Les spécifications ne mordent pas si fort ! Lisez-les
  20. LaurentDenis
    Ta page est en XHTML, et le code donné par Dan en HTML. Tu dois ajouter le / de fermeture dans la balise image: <img scr="..." alt="..." /> Il en est de même de tes balises meta, link, etc. Au passage, je n'avais pas vu dans ton autre fil, mais ta page ne devrait pas être en XHTML1.1, qui ne se justifie pas ici, et qui est invalide dans ton cas: - type-mime de la page incorrect (le type-mime se gère au niveau serveur. Celui par défaut sur ton serveur est text/html, qui ne convient pas à XHTML1.1, mais qui convient parfaitement à XHTML1.0 et HTML4.01) - doctype incompatible avec la présence des attributs de présentation dans le code XHTML (les width, size, font, align, etc. n'existent pas en XHTML1.1) Tu devrais utiliser XHTML1.0 transitional, ou HTML4.01 transitional. Tu n'auras alors qu'un minimum de corrections à apporter à ton code (quelques attributs à passer en style CSS et suppression de la balise <marquee> par exemple). A ce sujet, voir http://www.webmaster-hub.com/index.php?showtopic=3890 et les commentaires apportés dans http://blog-and-blues.org/weblog/2004/06/11/243
  21. LaurentDenis
    Ajoute un style="text-align: left;" à la cellule de tableau contenant les images de feuilles. Cela dit, cette mise page pourrait sans difficulté se passer de tableaux et utiliser uniquement les feuilles de styles CSS. Tu aurais alors un code beaucoup plus léger et facile à gérer... et ce serait une bonne occasion d'apprendre à utiliser CSS
  22. LaurentDenis
    Plutôt que de mettre cette roue dans ton contenu HTML, il sera beaucoup plus facile d'en faire une image d'arrière-plan CSS, à l'aide de la propriété background. Cela donnera quelque-chose comme: #contenu { background: #000 url("...") top right no-repeat; }
  23. LaurentDenis
    Mon avis va être des plus décevants : en fait, c'est un mauvais sujet pour te lancer dans javascript, car il ne faut pas mettre de valeur par défaut dans les champs de formulaires. Je sais : la WAI et les autres recommandations et validateurs d'accessibilité l'exigent (en particulier Bobby). Mais: - cette recommandation a disparu dans le projet WAI2.0, et ce n'est pas pour rien. - la WAI1.0 demande à ce que l'on mette des valeurs par défaut... en attendant que les agents utilisateurs sachent tous restituer correctement les champs vides. Or, c'est actuellement le cas, semble-t-il. Cette valeur par défaut crée maintenant plus de problèmes qu'elle n'en résoud: - ergonomiquement, en obligeant à l'effacer avant de saisir - ce que le javascript ne résoud pas puisqu'il n'est pas disponible pour tous les utilisateurs - ce qu'un javascript mal conçu rendra très problématique parfois : par exemple, si j'ai laborieusement entré mon adresse e-mail et fait une erreur... je dois tout saisir à nouveau puisque le champ sera effacé entièrement si je tente d'y avoir accès pour corriger... - et plus généralement, cette valeur par défaut est une source de confusion pour de nombreux utilisateurs, qui ne savent pas s'il faut l'effacer ou non... Donc: - javascript à revoir s'il rend impossible de corriger une saisie sans qu'elle soit effacée entièrement - javascript inutile. Il suffit de supprimer les value="..." du formulaire
  24. LaurentDenis
    Hé non Dans le cas de figure des deux colonnes en float comme ci-dessus, pour que la colonne droite puisse flotter à côté de la colonne de gauche, il faut qu'il y ait la place pour sa largeur+ses marges latérales
  25. LaurentDenis
    Attention dans ce cas à éviter les largeur trop ajustées et à laisser du jeu entre tes colonnes: la largeur finale calculée de ton menu sera variable selon la police de caractère effectivement utilisée. Même si tu t'assures que tout va bien avec les polices que tu as spécifiées dans ta CSS, il suffit qu'un visiteur n'ait aucune de ces polices, ou ait d'autres préférences exprimées dans le paramétrage de son navigateur... et une police plus "large" que prévue risque alors d'être utilisée. Dans ce cas, ton menu a une largeur finale calculée plus grande que prévue, et ta mise en page ne tient plus (les flottants se décalent vers le bas). Mieux vaut une largeur en %. Il n'existe aucun procédé permettant de faire effectuer des calculs de ce type en CSS. C'est une autre raison pour laquelle le choix d'une unité unique de largeur (le %) est plus rationnel que les mélanges %+em ou %+px. Mais surtout, as-tu vraiment besoin de faire flotter ta 2e colonne ? Il y a de fortes chances que ce soit inutile Si ta seconde colonne est en flux, elle occupera naturellement toute la largeur disponible à côté de ton flottant, que la largeur de celui-ci ait été indiquée en em, en % ou en px. On voit souvent ici une surabondance inutile de propriétés de positionnement dans les mises en pages "problématiques": laisser faire le flux partout où c'est possible est le meilleur moyen d'apprivoiser le positionnement CSS
×
×
  • Créer...