Aller au contenu

Denis

Hubmaster
  • Compteur de contenus

    1 537
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par Denis

  1. Et bien stooomy, voilà qui fait drôlement plaisir à lire ! Mais c'est beaucoup trop d'honneur pour le misérable vermisseau que je suis. Je suis très honoré d'avoir pu t'être utile au fil de ton évolution avec les CSS. Ce sont des commentaires comme celui-là qui me donnent le carburant nécessaire pour continuer, mois après mois. Merci, du fond du coeur, ça me touche beaucoup.
  2. L'affichage est nickel sous MSIE (5.0, 5.5, 6.0), Mozilla (1.6), FireFox (0.8), Firebird (0.7), Opera (7.23), K-Meleon (0.8) et Netscape (7.1). Beau boulot. La seule chose, c'est que tes boites 'Musique' (à gauche) et 'Musique et photo numérique' (droite) ne sont alignées horizontalement que dans Internet Explorer. Dans tous les autres, la boîte de droite est décallée d'une vingtaine de pixels vers le bas, probablement du à un padding ou un margin non spécifié à 0.
  3. Excellents commentaires Laurent Voici une page qui compile plusieurs adresses de validateurs d'accessibilité, de HTML et plus encore : http://www.tbchad.com/validator.html
  4. Arf... c'est loin d'être parfait un synthétiseur vocal...
  5. Bon et bien, je vais commencer à ramasser mes sous !
  6. Tiens, de base et très simplement, voici un fichier contenant un tel menu : <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"> <head> <meta http-equiv="Content-Type" content="text/HTML; charset=iso-8859-1" /> <title>exemple de menu par liste</title> <style> #menu {margin: 0; padding: 0; list-style-type: none; font-weight: bold;} #menu li a {display: block;} #menu li a.encours {display: block;} #menu li a:link, #menu li a:visited {color: #EEE; text-decoration: none;} #menu li a:hover {background-color: #790c21; color: #fff;} #sousniveau {font-weight: normal; padding: 0; margin: 0; list-style-type: none; color: #999;} #sousniveau li a {color: #999; margin: 0;} #sousniveau li a:hover {background-color: #fff; color: #999;} </style> </head> <body> <ul id="menu"> <li>Item 1</li> <li>Item 2 <ul id="sousniveau"> <li>Sous item 1 de item 2</li> <li>Sous item 2 de item 2</li> </ul></li> <li>Item 3 <ul id="sousniveau"> <li>Sous item 1 de item 3</li> <li>Sous item 2 de item 3</li> <li>Sous item 3 de item 3</li> <li>Sous item 4 de item 3</li> </ul></li> <li>Item 4 <ul id="sousniveau"> <li>Sous item 1 de item 4</li> <li>Sous item 2 de item 4</li> <li>Sous item 3 de item 4</li> <li>Sous item 4 de item 4</li> <li>Sous item 5 de item 4</li> </ul></li> <li>Item 5</li> <li>Item 6</li> </ul> </body> </html> Tu pourrais juste lui donner un look en fonction de tes goûts.
  7. Pour virer le décalage, suffirait de réduire le padding et le margin de gauche
  8. Ben, ça dépend... tout dépendra de ta feuile de style et de la manière dont elle est structurée... Si tu ne spécifiais que ul li {... régles CSS quelconques...} Alors oui, tous les li auraient les mêmes règles d'appliquées. Mais si tu avais ul li {... régles CSS quelconques...} ul li ul li {... autres régles CSS quelconques...} Alors les <li> contenus dans des <ul>, contenus dans des <li> auraient une attribution différente des <li> directement contenus dans des <ul>. M'exprime-je clairement ?
  9. Oui, ça l'est Ce que j'en retiens en fait, c'est que dans certains cas, le <br /> peut effectivement voir son intérêt, même si dans la majorité des cas, une astuce CSS est à privilégier. Dans un soucis d'économie de code, il est préférable d'utiliser un <br /> que deux <l></l>. Par contre, les poèmes sont effectivement le seul endroit ou je trouve que le <br /> conserve de son intérêt (à part bien sûr les tableaux HTML ou les règles de paddings et de margins ne sauraient être prises en compte par le navigateur, mais come plus personne de nos jours ne construit ces mises en pages en tableaux, il est inutile de le souligner ) Pour les tableaux, je blague, évidemment. Et c'est justement ce qui est dommage.
  10. Ça fait déjà un moment que je cherche à mettre la main sur c2 commen om de domaine... impossible de réserver quoi que ce soit. Il y a ceux qui sont déjà existants (.com, .net, .org), mais j'aurais bien aimé tomber sur .ca (Canada) ou .qc.ca (Québec) Seulement, on m'en refuse le droit, disant que les noms de domaines contenant seulement deux caractères ne peuvent contenir de chiffres ou de traits d'unions.
  11. Bien que je sois également plus sympathique à la cause de Dotclear que n'importe quel autre outil de blogue, il ne faut quand même pas perdre de vue que n'importe quel système fonctionne sous le même modèle, à savoir, un affichage mensuel de l'information. C'est aussi vrai de Movable Type, de Blogger, de Radio, etc.
  12. Bienvenu Zil, je crois que ton impression est bonne. Du moins, il fait bien laisir de la lire. Les discussions ici sont intéressantes, enrichissantes, courtoises et constructives. En espérant que tu sauras t'y plaire autant que nous !
  13. Merci Laurent pour l'éclaircissement... ce sont de très bonnes indications qui font beaucoup de sens.
  14. Si bien sûr, tu peux y mettre ce que tu veux, mais pourquoi aurais-tu besoin de quoi que ce oit d'autre que des listes imbriquées pour créer un menu ? Sans voir ton code, en lisant ce qui semble être ton besoin, je verrais quelque chose comme ceci : <ul> <li>Item 1 de menu <ul> <li>Sous-item 1 de item 1</li> <li>Sous-item 2 de item 1</li> <li>Sous-item 3 de item 1</li> <li>Sous-item 4 de item 1</li> </ul></li> <li>Item 2 de menu <ul> <li>Sous-item 1 de item 2 <ul> <li>Sous-item 1 de sous-item 1 de item 2</li> <li>Sous-item 2 de sous-item 1 de item 2</li> </ul></li> <li>Sous-item 2 de item 2</li> <li>Sous-item 3 de item 2</li> </ul></li> <li>Item 3 de menu <ul> <li>Sous-item 1 de item 3</li> <li>Sous-item 2 de item 3</li> </ul></li> </ul> Avec ça, tu peux te créer toute la profondeur hiérarchique dont tu as besoin, sans utliser autre chose que des listes imbriqués. Si tu voulais donner un titre à l'ensemble de ce menu, tu pourrais très bien utiliser un h3 si tu le voulais.
  15. Justement, comme le dit Laurent... Pourquoi aurais-tu besoin d'un frame ? De plus, frame ou non, tu devrais pouvoir y référencer ta CSS avec un simple path correct. Tu lances l'appel avec un path relatif ou absolu ? Évidemment, sans la moindre ligne de code, nous ne pouvons par t'aider beaucoup...
  16. Bienvenue dans le hub CiD. J'espère que tu t'y plairas autant que nous !
  17. Effectivement, c'est ce que j'allais te proposer... si tu souhaites mettre en place une interface de publication sur le Web pour demeurer en contact et ne pas trop souffrir dans le processus, le mieux est de te configurer un petit DotClear tout mignon. Ça te prendra quelques minutes, au pire une soirée et tu seras en ligne, prêt à publier tout ce qui te plaira !
  18. J'apporte mon support à Monique, Laurent et les autres à propos des dimensions des images. Mis à part que ces attributs demeurent tout à fait valides en (x)html, certains pourraient avancer que les dimensions des images sont de l'ordre de la présentation, donc qu'ils devraient faire parti de la CSS. Je ne suis pas sûrs qu'ils aient totalement tort, mais cela va tellement à contre-sens de la logique que je me refuse à m'y plier, ne serait-ce que pour ne pas me ramasser avec un fichier CSS et HTML combiné de 325k pour couvrir toutes les images avec les classes y étant rattachées. Si toutes mes images étaient de la même dimension, je le ferai probablement, simplement pour alléger au maximum mon code, mais comme c'est rarement le cas... Pourrait-on plus avancer que les attributs height et width sont principalement de l'ordre de la structure du document et donc qu'ils devraient absolument demeurer dans le fichier HTML ? J'aimerais bien trouver une vraie référence là-dessus, c'est une question que je me pose souvent. Selon la simple logique, ils penchent plus du côté de la valeur structurelle que présentationelle. Il semble y avoir une démarcation entre ces deux attributs et l'attribut border qui lui, est définitivement considéré comme de l'ordre de la présentation. En même temps, il est facile de le régler par un simple img {border: 0;} dans la feuile de style, peu importe le nombre d'image affectées. Mais quelle est l'argument irréfutable et documenté qui différencie border de width et height ? Je le cherche encore...
  19. Re-hummm... <l>, un simple <span> avec un retour à la ligne ? Quelle différence alors par rapport à tous les autres éléments HTML existants ? Ne pourrions-nous pas, dans une certaine mesure, présenter à peu près n'importe quel élément HTML comme étant l'émule de tel autre, avec ou sans telle particularité ?
  20. lol OK Laurent, je m'avoue vaincu... je n'ai rien d'intelligent à ajouter pour faire valoir mon point. Peut-être la première réelle solution à l'organisation structurelle d'un poème véritablement sémantique nous viendra de l'élément line ( <l> ) en xhtml 2.0 ?
  21. Ce qui me semblerait plus intéressant encore (et complémentaire à ton initiative), ce serait de lister tous les validateurs connus et utilisés, afin d'en graduer la qualité et la tolérance. Le validateur du W3C n'est pas forcéement le meilleur, simplement dû au fait qu'il provienne du W3C (avec tout le respect que je leur dois, à eux et à l'effort surhumain que les bénévoles y déploient). Quand on compare le travail effectué par le W3C validator avec celui effectué par le WDG validator, on se rend compte que ce dernier est encore moins permissif, relevant des fautes là ou le W3C n'en relève pas. En faisant ce petit test, nous pourrions peut-être découvrir certaines choses et avoir des surprises...
  22. Effectivement... mais les mêmes manipulations pourraient se faire aussi bien pour quelqu'un à l'aise avec jsp, cfm, asp ou autre... tant que c'est une manipulation backend.
  23. Si on considère une strophe comme une phrase, alors le <p> est utilisable. Faire découper ce paragraphe en plusieurs lignes avec des <span> auxquels on passerait un display: block; me semble effectivement plus efficace que les <br />, ne serait-ce que pour conserver la possibilité de les ramener un jour sur une seule ligne... Plus j'y pense, plus je suis à l'aise avec ceci : <p> <span>Elle dormait : son doigt tremblait, sans améthyste</span> <span>Et nu, sous sa chemise, après un soupir triste</span> <span>Il s'arrêta, levant au nombril la batiste</span> </p> <p> <span>Et son ventre sembla de la neige où serait</span> <span>Cependant qu'un rayon redore la forêt</span> <span>Tombé le nid moussu d'un gai chardonneret</span> </p> <div> <cite>Stéphane Mallarmé</cite>, <cite>Mysticis umbraculis</cite> </div>
  24. Si l'exception de la poésie se tient, je ne suis pas convaincu à 100%... Car une strophe d'un poème n'est pas un paragraphe à proprement parler. Une utilisation du <div> ne serait-elle pas mieux indiquée ? Après tout, comme le cas est excpetionnel, il mériterait peut-être un traitement exceptionnel. <div> <div>Elle dormait : son doigt tremblait, sans améthyste</div> <div>Et nu, sous sa chemise, après un soupir triste</div> <div>Il s'arrêta, levant au nombril la batiste</div> </div> <div> <div>Et son ventre sembla de la neige où serait</div> <div>Cependant qu'un rayon redore la forêt</div> <div>Tombé le nid moussu d'un gai chardonneret</div> </div> <div> <cite>Stéphane Mallarmé</cite>, <cite>Mysticis umbraculis</cite> </div> Ou alors, avec des <span> ? <div> <span>Elle dormait : son doigt tremblait, sans améthyste</span> <span>Et nu, sous sa chemise, après un soupir triste</span> <span>Il s'arrêta, levant au nombril la batiste</span> </div> <div> <span>Et son ventre sembla de la neige où serait</span> <span>Cependant qu'un rayon redore la forêt</span> <span>Tombé le nid moussu d'un gai chardonneret</span> </div> <div> <cite>Stéphane Mallarmé</cite>, <cite>Mysticis umbraculis</cite> </div>
×
×
  • Créer...