Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Comment modifier la ligne au-dessus des ?

99 réponses
Avatar
kurtbosh
Bonjour,

Je n'arrive pas =E0 supprimer ou =E0 diminuer la hauteur de la ligne qui
se trouve au-dessus des UL. Exemple :

Exemple
<ul>
<li>1=E8re ligne
<li>2=E8me ligne
</ul>

Il y a une ligne entre "Exemple" et "1=E8re ligne". C'est celle-ci qui
me g=EAne.

Pour cette page :

http://www.grenault.net/couples.htm (non, rien de cochon...)

Merci.

Guy

9 réponses

6 7 8 9 10
Avatar
kurtbosh
On 23 fév, 12:39, Pierre Goiffon wrote:
kurtbosh wrote:
>>> Il y a de l'idée dans tes remarques mais il ne faut pas toucher à mes
>>> tables, il n'y a que ça de vrai ! Les boites CSS pfftt.
>> Heu ... pour un bandeau et 3 colonnes dessous ...
>> les rendus doivent tout de même être assez proches,
>> vu comme ça de ma chaise.
> Les tables sont reconnues par :
> - HTML 4.01 STRICT
> - XHTML
> - HTML 5 (d'après ce que j'ai lu car seules les Frames disparaissent)

> Et puis c'est 100% fiable les tables !

> J'ai essayé à plusieurs reprises d'utiliser les boîtes CSS : quan d
> c'est parfait avec FF, ça m... avec IE et inversement, surtout au
> moment des resizing.

Si vous avez l'habitude de faire de la mise en page en utilisant des
tableaux alors oui, vous aurez quelques difficultés à changer vers du
contenu simplement structuré, avec le minimum de balises html servant
uniquement à la mise en forme.

Il y a aujourd'hui de très nombreux sites utilisant CSS avec le minimum
de tableaux et qui tournent depuis longtemps pour rejeter l'argument
"les tables fonctionnent partout, pas le CSS" !

D'un point de vue purement concepteur, vous avez de très nombreuses
bidouilles à connaître pour faire de la mise en page en tableaux, et
c'est la même chose si vous voulez faire du CSS. Cependant si l'on est
en strict avec un minima sur IE6, à mon sens ça réduit considérab lement
le volume de bidouilles à connaître, largement au profit de CSS !

Par contre, la mise en page par tableaux est une horreur absolue à
intégrer (je pense aux sites dynamiques en particulier) et à mainteni r !
Séparer fond et forme permet de gagner considérablement sur ces aspec ts.

En résumé, passer à CSS c'est un investissement, mais ça en vaut très
largement le coup.
Et il y a de très nombreux concepteurs aujourd'hui qui peuvent en
témoigner ! (moi par exemple :) )



Oui, sans doute mais je les aime bien mes tables, elles m'obéissent au
doigt et à l'œil et elles ne m'ont jamais posé le moindre problème.
Les boîtes, c'est vrai je ne les maitrise pas, elles n'en font qu'à
leur tête ! Je reconnais aussi que s'y retrouver dans une page où il y
a beaucoup de tables imbriquées ce n'est pas toujours simple !!!! J'y
viendrai, c'est certain mais je n'ai pas encore le courage. Pour
l'instant j'essaie de passer du transitionnel au strict sans erreur
détectée par le w3c. Ce sera déjà un gros progrès. Je viens déj à
d'utiliser les Hn pour les titres avec un seul H1 par page (et plus de
Hn pour autre chose que des titres...), maintenant c'est le passage au
Strict et c'est du boulot - même si je n'avais pas d'erreur en
transitional. Il me restera quand toutes les pages seront en strict à
condenser la page CSS pour avoir moins de déclarations... Il faut du
temps.

Merci pour les conseils judicieux.
Avatar
Michael DENIS
Olivier Miakinen a écrit :
des balises invalides en SGML (<br/> par exemple).



<br /> ;-)
C'est vrai, même si les navigateurs ne sont nullement gênés par cette
spécificité.

Il ne sera plus recevable lorsque la majorité des navigateurs pourront
utiliser un vrai parser XML pour lire du XHTML, et que l'on abandonnera
la soupe de balises text/html déclarée comme du XHTML. Ce n'est
clairement pas le cas aujourd'hui, et tu le reconnais toi-même (cf.
ta remarque sur les « navigateurs "anciens" »)



Si cela devient le cas, les utilisateurs de xhtml seront ravis d'avoir
fait le pari, à défaut... :-)

--
Michaël DENIS
Avatar
Pierre Goiffon
Michael DENIS wrote:
Il ne sera plus recevable lorsque la majorité des navigateurs pourront
utiliser un vrai parser XML pour lire du XHTML, et que l'on abandonnera
la soupe de balises text/html déclarée comme du XHTML.



Si cela devient le cas, les utilisateurs de xhtml seront ravis d'avoir
fait le pari, à défaut... :-)



Pas seulement !
La très large majorité des pages XHTML disponibles sur le Web
aujourd'hui ne passeraient pas du tout si elles étaient servies en
application/xml+xhtml !
Avatar
SAM
Le 2/23/09 11:27 AM, Olivier Miakinen a écrit :
Bonjour,

Le 20/02/2009 18:19, SAM a écrit :
Euh ? Je dirai que la majorité des navigateurs modernes proposent un
moyen de ne pas tenir compte des target non ?


Ah ? Dans firefox par exemple, comment fait-on ? Ça m'intéresserait...


Ha? J'aurais juré craché que c'était prévu.
Ben ... non :-(



Ah ? La méthode qui fonctionnait depuis des annnées dans Mozilla ne
fonctionnerait donc plus dans Firefox ?



Pour _choisir_ soi-même *même* fenêtre (ou onglet) ?
Au coup par coup (menu contextuel) ... non, pas trouvé.

<cit. http://www.miakinen.net/vrac/fenetre#t4>
Il vous suffit de mettre dans votre fichier user.js la ligne suivante.
user_pref("browser.block.target_new_window", true);
</cit.>



et ça fonctionne aussi avec : target="trucmuche" ?
(censé ouvrir dans une fenêtre-onglet nommée, probablement déjà ouverte)

(remplacer user.js et user_pref() par about:config pour un accès un peu
plus simple)



Oui mais ça ça bloque systématiquement le html-popup, non ?
Ha? il parait que ça ne fonctionne pas dans Fx ?

Bon, j'espère qu'en ce cas le menu contextuel continue à proposer :
- nouvelle fenêtre
- nouvel onglet

(je n'aime pas être coincé par des pré-choix, surtout s'ils ne sont pas
faciles d'accès)

--
sm
Avatar
Pascale
Pierre Goiffon écrivait
news:49a28b0f$0$5841$:

Par contre, la mise en page par tableaux est une horreur absolue à
intégrer (je pense aux sites dynamiques en particulier) et à maintenir !



V'là autre chose... (-:

--
Pascale
Avatar
SAM
Le 2/23/09 1:46 PM, kurtbosh a écrit :
On 23 fév, 12:39, Pierre Goiffon wrote:

Par contre, la mise en page par tableaux est une horreur absolue à
intégrer (je pense aux sites dynamiques en particulier) et à maintenir !
Séparer fond et forme permet de gagner considérablement sur ces aspects.

En résumé, passer à CSS c'est un investissement, mais ça en vaut très
largement le coup.
Et il y a de très nombreux concepteurs aujourd'hui qui peuvent en
témoigner ! (moi par exemple :) )



Oui, sans doute mais je les aime bien mes tables, elles m'obéissent au
doigt et à l'œil



Ben tes tables n'ont pas l'air de m'obéir au doigt et à l'oeil
(comme déjà dit) en particulier au retrécissizing

Je reconnais aussi que s'y retrouver dans une page où il y
a beaucoup de tables imbriquées ce n'est pas toujours simple !!!! J'y
viendrai, c'est certain mais je n'ai pas encore le courage.



Bon, on va patienter alors ;-)

Mais le passage de table à non-table c'est du boulot !
(extraire tous les contenus des td sans en oublier pour les remettre
dans du html plus normal, c'est assez fastidieux.)

Alors tente déjà de prévoir tes nouvelles pages sans tables, et migre
les autres progressivement.

--
sm
Avatar
SAM
Le 2/23/09 2:15 PM, Michael DENIS a écrit :
Olivier Miakinen a écrit :
des balises invalides en SGML (<br/> par exemple).



<br /> ;-)
C'est vrai, même si les navigateurs ne sont nullement gênés par cette
spécificité.



Heu ... est-ce que ça ne fait passer Fx en quirksmode ?

--
sm
Avatar
Pierre Goiffon
SAM wrote:
des balises invalides en SGML (<br/> par exemple).



<br /> ;-)
C'est vrai, même si les navigateurs ne sont nullement gênés par cette
spécificité.



Heu ... est-ce que ça ne fait passer Fx en quirksmode ?



Ha ? Jamais entendu parler.

En tout cas écrire <br/> dans une page XHTML servie en text/html c'est
passer outre l'annexe C. Ce dernier n'est pas normatif, juste informel...

Je ne connais pas le comportement des navigateurs si l'on omet les
recommandations de l'annexe C, mais je ne suis pas sûr que ça soit très
raisonnable de s'aventurer à aller les connaître, tout comme cela me
parait dangereux de renvoyer du (x)HTML invalide...
Avatar
Olivier Masson
SAM a écrit :

Ha! oui! OK
et quand on se trompe dans l'autre sens (HTML4.01 + attribut complété)
ça n'y fonctionne plus.
Si on me permet de m'exprimer : ce truc est simplement débile!
D'autant qu'en JS on continue de tester true/false
et non pas (checked == 'checked')




Ouais, je sais que tu es un rebelle. Va raler auprès du W3C.
6 7 8 9 10