Comment donner une couleur à <hr/>? [résolu]

Bonjour,

j'aimerais savoir comment donner une couleur et une largeur au trait de séparation <hr/>. Je l'ai fais comme suit dans le html car je ne savais pas quoi mettre dans le CSS, mais cela ne marche que sur IE.

<hr size="1" color="#FF0000"/>

Je préférerais une solution avec du CSS.

Merci.
Modifié par mathmax (21 Aug 2005 - 21:54)

Salut, la question a déjà été posée, je te donne les pistes :
* http://www.sovavsiti.cz/css/hr.html
* http://www.saila.com/usage/tips/defn.shtml
* http://www.blakems.com/experimental/hr/

Au passage, c'est <hr /> (avec l'espace) et non <hr/>.

Merci pour les infos.

Stephan a écrit :
Au passage, c'est <hr /> (avec l'espace) et non <hr/>.

Bonjour,

Pas forcément. <hr/> est tout à fait valide et passe à peu près partout. L'espace avant le slash final dans les balises uniques en xhtml sert à éviter une erreur de parsing sur certains agents utilisateurs un peu à la ramasse.

Mais à l'heure actuelle, c'est plus une habitude de codage qu'autre chose

C'est ce que j'avais entendu dire, du moins. Dites-moi si je me trompe

LeTenia a écrit :
Pas forcément. <hr/> est tout à fait valide et passe à peu près partout. L'espace avant le slash final dans les balises uniques en xhtml sert à éviter une erreur de parsing sur certains agents utilisateurs un peu à la ramasse.

Tout à fait, mais c'est tout de même une pratique conseillée par le W3C.

Je pense que tout est dit ici :
http://blog-and-blues.org/weblog/2005/01/09/371-fermeture-elements-vides-xhtml

Tiens j'ignorais que le w3c en personne s'était fendu de quelques lignes sur la question.

Au risque d'insister, est-ce vraiment nécessaire de faire autant de compatibilité descendante?
Visiblement l'agent utilisateur qui pose le plus gros problème avec <br/> ou <hr/> est netscape 4: on ne peut pas dire ni qu'il soit encore très utilisé, ni qu'il soit vraiment le navigateur idéal

Arranger un site pour WinIE (parce que beaucoup utilisé, etc..) certes.
Arranger un site pour NS4, bof bof..

PS: il est peut-être préférable d'ouvrir un autre sujet sur la question, puisque c'est une digression sur un sujet résolu. Venant d'arriver je ne connais pas encore bien la politique de la maison, mais j'aimerais autant ne pas me faire virer à peine inscrit

LeTenia a écrit :
Au risque d'insister, est-ce vraiment nécessaire de faire autant de compatibilité descendante?

Boarf, ça ne nécessite franchement pas beaucoup d'efforts (surtout que ça devient très très vite un réflexe) donc pourquoi s'en priver ?

Ah si tous les "hacks" étaient aussi simples à mettre en oeuvre...

djfeat a écrit :

Boarf, ça ne nécessite franchement pas beaucoup d'efforts (surtout que ça devient très très vite un réflexe) donc pourquoi s'en priver ?

Pour gagner 1 octet par <hr/>

Çà peut paraître incongru, mais des sites à très gros trafic peuvent économiser beaucoup de bande passante en n'économisant finalement qu'une vingtaine d'octets par page (en comptant les <meta/>, <input/>, <br/>, <img/>).

ESPN, lors de son redesign "html crado" => "xhtml sémantique" a noté une économie de 2 Tera-Octets par jour (ce n'est pas rien)
En optimisant à mort le code HTML, ils peuvent encore grapiller bon nombre de Mo ce n'est pas inintéressant pour eux.
Quand on sait ce que coûte un To de bande passante.. et qu'on le compare aux revenus publicitaires..

C'est sûr que pour le petit site perso de Jean-Kevin Boulay, gagner 20 octets/page peut sembler un luxe inutile

LeTenia a écrit :
Pour gagner 1 octet par <hr/>

Avec ce raisonnement, aussi bien de retirer les virgules et les points dans les phrases, ils vont sauver encore plus d'octets.

Il faut savoir arrêter l'optimisation en poids un moment donné, et assumer pleinement le prix de la bande passante.

D'ailleurs, à mon humbe avis, au lieu de sauver que quelques octets avec les espaces avant les slashs, aussi bien de compacter le code source html en une ligne. Le code restera valide, exploitable par tous les navigateurs et le nombre d'octets sauvé sera énorme.
Modifié par Merkel (23 Aug 2005 - 21:46)

Non, on n'a pas à enlever les virgules des phrases.

C'est toi qui suit le raisonnement trop loin, au-délà de la limite à ne pas dépasser

Le code à compacter c'est la 1ère des choses à faire... => à quoi rajouter ce genre d'optimisations (j'insiste)
Si ton site ne draine pas un nombre de visiteurs si elevé que tu cours après la première optimisation, tant mieux pour toi (ce n'est pas ni ironique, ni condescendant je le pense vraiment )
Mais je ne vois pas où est l'inconvénient: moi je n'y vois qu'un avantage.

Ce que je trouve étrange, c'est le nombre de sites conformes aux standards qui ne se gênent pas pour expliquer au visiteur perplexe qu'IE6Win c'est pas bien çà pue tout çà... et qui souhaiteraient alors ouvrir grand leur porte à NS4 ?

Un truc m'échappe..

PS: j'ai plus de visiteurs sous "Solaris/Mozilla" que "[n'importe-quel-OS]/NS4" il faut s'avoir arrêter la compatibilité descendante un moment donné..

je ne fais que passer pour dire:
merci pour les liens donnés...
Modifié par Maxwell (23 Aug 2005 - 22:13)

LeTenia a écrit :
Non, on n'a pas à enlever les virgules des phrases. C'est toi qui suit le raisonnement trop loin, au-délà de la limite à ne pas dépasser

C'était dit de façon sarcastique. C'est certain que chacun peut mettre ses propres limites, mais si les gens commencent à effectuer ce genre de manipulation pour sauver quelques octets, qu'est-ce qui les empêchera, "moralement" parlant, de décider de retirer le doctype, les métas tags, la balise body, et j'en passe. Je pousse effectivement loin l'idée au-delà du bon sens, mais de nombreux créateurs de sites semblent dénués de ce bon sens. Il ne faudrait pas leur laisser trop la porte ouverte à ce genre de raisonnement.

LeTenia a écrit :

Le code à compacter c'est la 1ère des choses à faire... => à quoi rajouter ce genre d'optimisations (j'insiste)
Si ton site ne draine pas un nombre de visiteurs si elevé que tu cours après la première optimisation, tant mieux pour toi (ce n'est pas ni ironique, ni condescendant je le pense vraiment )
Mais je ne vois pas où est l'inconvénient: moi je n'y vois qu'un avantage.

Honnêtement, nous avons développés et nous hébergons une trentaine de sites web, et aucun d'entre eux n'a été compacté que sur une ligne. Évidemment, nous n'avons pas le trafic de google. Mais il reste tout de même que j'ai rarement vu de sites avoir un code source que sur une ligne. La première chose à faire c'est séparer le contenu de la présentation via XHTML et CSS, ainsi que le code Javascript. Retirer les balises, les ID et les class inutiles. Optimiser les images. Déjà, avec ca, le gain est majeur. Ensuite, si c'est vraiment crucial, tu utilise un bon vieux script pour compacter tes documents html lorsque tu les met sur le serveur de production.

LeTenia a écrit :

Ce que je trouve étrange, c'est le nombre de sites conformes aux standards qui ne se gênent pas pour expliquer au visiteur perplexe qu'IE6Win c'est pas bien çà pue tout çà... et qui souhaiteraient alors ouvrir grand leur porte à NS4 ?

Un truc m'échappe..

Ces webmasters sont étranges oui. Personnellement, je n'ai jamais craché sur IE6Win. Il est imparfait, mais pas au point de se faire mettre sur un bûché. Il faut se soucier de tous les navigateurs, même si on ne les aime pas, car d'autres les apprécient.

Pour ce qui est de la compatibilité descendante, je le fais au niveau html, mais pas au niveau graphique. Bref, avec Netscape 4.x, mes sites sont en mode sans CSS. Ro le vilain ! Pour plusieurs raisons :

- Faut qu'un jour les gens se mettent un peu à jour quand même
- Je préfère investir mon temps pour améliorer la qualité des sites et modules de gestion que je développe, ce qui comprend sémantique, accessibilité, conformité, normes de qualité etc... plutôt que d'avoir un rendu graphique dans de vieux navigateurs comme Netscrape 4.x.
- Peut-être un peu par paresse et/ou désintérêt total vis-à-vis Netscrape 4.x
Modifié par Merkel (23 Aug 2005 - 22:34)

Merkel a écrit :
si les gens commencent à effectuer ce genre de manipulation pour sauver quelques octets, qu'est-ce qui les empêchera, "moralement" parlant, de décider de retirer le doctype, les métas tags, la balise body, et j'en passe. Je pousse effectivement loin l'idée au-delà du bon sens, mais de nombreux créateurs de sites semblent dénués de ce bon sens. Il ne faudrait pas leur laisser trop la porte ouverte à ce genre de raisonnement.

Tu as certainement raison sur ce point, je ne vois peut-être qu'un seul côté de la chose

<troll>
Par contre, quitte à ne pas avoir de rendu graphique dans NS 4 on peut donc légitimement se moquer du fait qu'il ignore <br/> ou <img/>, pas vrai ?
Ok ok j'ai compris je sors
</troll>

LeTenia a écrit :

<troll>
Par contre, quitte à ne pas avoir de rendu graphique dans NS 4 on peut donc légitimement se moquer du fait qu'il ignore <br/> ou <img/>, pas vrai ?
Ok ok j'ai compris je sors
</troll>

Non, car le br désigne un saut de ligne. C'est plus ou moins graphique. Cela a un sens réel selon moi.

Les img, quant à eux, servent normalement à afficher des informations pertinentes sous forme d'image accompagné d'un texte alternatif(alt), et non pour le design graphique du site. Les éléments décoratifs devraient en théorie toujours être en background via CSS. Alors ton troll, remballe-le ! Mais c'était bien essayé de ta part !

Edit : Bref, les balises img et br font parties du contenu, et non de la présentation comme les CSS.
Modifié par Merkel (24 Aug 2005 - 14:17)

Du coup il semble tout à fait possible d'omettre cet espace dans les éléments vides du <head> tels <meta/> et <link/> puisqu'ils n'ont pas de rendu graphique. Non ?

Bonjour,

Pour info: la notion même d'élément %EMPTY est problématique du point de vue SGML. Mais certains le sont plus que d'autres : les seuls qui seront ignorés par NS4.x en l'absence de l'espace sont <hr/> et <br/>, c'est à dire les séparateurs par opposition aux éléments ayant un pseudo contenu (img, iframe, meta... ).

Sur le fond, c'est une simple question de choix qualitatif que chacun fera à sa guise, entre deux syntaxes également valides :
- opter pour la syntaxe qui ne pose aucun problème de validité dans le souci d'offrir un rendu de meilleur qualité pour une frange supplémentaire d'utilisateurs.
- Ou bien opter pour la syntaxe courte, pour un gain nettement plus réduit du côté du poids HTML (Un serveur qui en est à ce point a bien d'autres questions à se poser).

Autre remarque: l'un des atouts de la syntaxe XHTML est sa simplicité. Commencer à distinguer des éléments %EMPTY avec (hr br) et sans (img, meta... ) espace réintroduirait, toutes proportions gardées, la coûteuse complexité du HTML: avez-vous en tête par exemple la listes des éléments que vous avez le droit de ne pas fermer en HTML ? Sauriez-vous vous en servir sans erreur pour gagner quelques octets ? Faire en sorte surtout que des rédacteurs s'en servent sans erreur ?

Enfin, toujours entre deux syntaxes également valides, d'autres choix sont possible, pour d'autres économies de bout de chandelle. Par exemple:
- écrivons <script src=... /> en XHTML (bof pour les utilisateurs d'Opera, 2% du marché par jour de grand vent)
- adoptons HTML transitional et supprimons l'élément <body>, optionnel (grosse économie d'octets).

A chacun d'assumer ses choix. Evitons juste de qualifier péjorativement d'habitude de codage avec un point de vue étroitement technique ce qui est un choix réfléchi de qualité.
Modifié par Un vacancier (24 Aug 2005 - 08:33)