Coller des boutons-liens

Question

neeteex

27 May 2009 à 00:35

Bonjour,

Je veux faire un petit bandeau avec des boutons qui sont autant de liens vers des pages web. Le code est valide, il fonctionne, mais c'est moche : j'ai 8 liens, à mettre dans 8 boutons de 12,5 % chacun pour une page de 100%, seulement je n'arrive pas à supprimer les marges entre les boutons, et en plus ils sont reliés par un trait horizontal bas.

Comment devrais-je faire pour avoir mes 8 boutons équitablement répartis sur 100% de la largeur et accolés les uns aux autres ?

Le code : (les border c'est pour suivre cette méthodo)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr">
	<head>
		<title>Bannière Survie</title>
		<meta http-equiv="Content-Type" content="text/html; charset=utf8" />
		<style type="text/css">
			body
			{
				width : 100% ;
				margin: 0;
				padding:0;
				border: 1px solid black;
			}
			.banniere
			{
				width : 100% ;
				margin: 0;
				padding:0;
				border: 1px solid blue;

			}
			.banniere input
			{
				width : 12.5% ;
				margin: 0;
				padding:0;
				border: 1px solid red;

			}
			* {margin: 0; padding: 0;}
		</style>

	
	</head>
	<body>
		<div class="banniere">
			<a href="http://survie.org" target="_blank"> <input type="button" value="Site de Survie"/> </a>

			<a href="http://billetsdafrique.survie.org" target="_blank"> <input type="button" value="Billets d'Afrique"/> </a>

			<a href="http://wiki.survie.org/doku.php/media:" target="_blank"> <input type="button" value="Survie Media"/> </a>

			<a href="http://bpem.survie.org" target="_blank"> <input type="button" value="BPEM"/> </a>

			<a href="http://forum.survie.org" target="_blank"> <input type="button" value="Forum Survie"/> </a>

			<a href="http://wiki.survie.org" target="_blank"> <input type="button" value="Wiki Survie"/> </a>

			<a href="http://adherents.survie.org" target="_blank"> <input type="button" value="Esp. adhérents"/> </a>

			<a href="http://interpellation.survie.org" target="_blank"> <input type="button" value="Esp. interpellat°"/> </a>


		</div>
	
	</body>
</html>

Modifié par neeteex (27 May 2009 - 00:35)

Heyoan

27 May 2009 à 01:35

Salut,

même si le validateur ne tique pas (bizarrement Smiley murf

) des éléments INPUT n'ont rien à faire en dehors de formulaires. Ce qui est amusant c'est que dans FF2 et FF3 cela m'ouvre 2 pages d'un coup et aucune dans IE7.

As-tu lu le tuto Créer des menus simples en CSS ?

D'autre part je t'invite également à lire Comment bien déclarer du XHTML 1.0 et du XHTML1.1 (en résumé : pour une page servie en tant que text/html ne pas utiliser XHTML1.1).

Pour ce qui est de ta question je pense que le plus robuste pour un menu étirable reste encore d'utiliser une table. En attendant une meilleure implémentation de display:table et display:table-cell tu peux aussi regarder du côté d'inline-block. Et sinon pour le fun j'avais fait un test en float.
Modifié par Heyoan (27 May 2009 - 01:47)

Agylus

27 May 2009 à 07:53

Salut,

Heyoan a écrit :
même si le validateur ne tique pas (bizarrement )

Ben le validateur ne peut que vérifier l'élément directement parent de chaque balise et non pas un ancêtre plus éloigné. Et on peut voir sur ce lien qu'un input peut se trouver dans une balise a.

neeteex

27 May 2009 à 10:31

Heyoan a écrit :

même si le validateur ne tique pas (bizarrement ) des éléments INPUT n'ont rien à faire en dehors de formulaires.

Agylus a écrit :
on peut voir sur ce lien qu'un input peut se trouver dans une balise a.

Oula, débat de spécialistes, j'ai bien fait de poser la question ! L'affirmation d'Agylus reste-t-elle valable en xhtml 1.0 ?

Heyoan a écrit :

D'autre part je t'invite également à lire Comment bien déclarer du XHTML 1.0 et du XHTML1.1 (en résumé : pour une page servie en tant que text/html ne pas utiliser XHTML1.1).

Effectivement, je le note : faudra que je comprenne un jour ce qu'est le xml (un autre tuto à conseiller ?) parce que là j'en ai pas besoin ou alors je ne le sais pas encore...

Heyoan a écrit :
Ce qui est amusant c'est que dans FF2 et FF3 cela m'ouvre 2 pages d'un coup et aucune dans IE7.

Oui, j'ai repéré après coup qu'il vallait mieux mettre target="blank" que target="_blank" : du coup ça ouvre un seul onglet qui est actualisé en fonction du bouton pressé sur la page mère. Intéressant...

Heyoan a écrit :

As-tu lu le tuto Créer des menus simples en CSS ?

C'est maintenant chose faite, et j'apprécie l'aspect de cet exemple. Ce qui m'ennuie est le comportement "retour à la ligne" qui est effectivement plus proche de ce que je recherche avec "table".

Heyoan a écrit :

Pour ce qui est de ta question je pense que le plus robuste pour un menu étirable reste encore d'utiliser une table.

C'est ce qui est utilisé ici : http://forum.survie.org/
Le problème, c'est que ça suppose un maquillage pour "transformer" les cellules en boutons, et surtout que le "hover" ne s'applique pas à l'ensemble de la case lorsque certaines cellules passent sur 2 lignes (en réduisant la fenêtre) : les cellules qui sont restées sur une ligne avec un texte moins long n'ont de "hover" que sur la partie texte et non sur l'ensemble de la case. Question d'optimisation du css ? Et si c'est le plus robuste, pourquoi n'est-ce pas l'approche privilégié dans le tuto que tu conseilles, qui préfère les "ul" ? Reste qu'avec un bouton, je suis sûr qu'il soit considéré d'un bloc.

Heyoan a écrit :

En attendant une meilleure implémentation de display:table et display:table-cell tu peux aussi regarder du côté d'inline-block. Et sinon pour le fun j'avais fait un test en float.

Pour le premier lien je vois pas trop comment l'utiliser sur cette question, si ce n'est ce qui est fait sur http://forum.survie.org avec les cases de la table en "display:block". Le second est plus parlant mais n'a pas l'aspect "boutons" de tailles identiques recherché.

Agylus

27 May 2009 à 10:41

neeteex a écrit :
L'affirmation d'Agylus reste-t-elle valable en xhtml 1.0 ?

Elle est valable quel que soit le DOCTYPE utilisé.

neeteex a écrit :
il vallait mieux mettre target="blank" que target="_blank" : du coup ça ouvre un seul onglet qui est actualisé en fonction du bouton pressé sur la page mère. Intéressant...

Ce n'est en fait pas lié uniquement à la valeur "blank" sans underscore. Tu aurais pu mettre un target="jevaismecoucherparcequejaisommeil" que ça aurait fait la même chose. En effet, _blank ouvre une nouvelle fenêtre sans lui attribuer de nom, donc à chaque clic sur le lien, une nouvelle fenêtre va s'ouvrir. Mettre autre chose que _blank (à l'exception de _self, _parent et _top) confère à la nouvelle fenêtre un nom. Donc quand tu recliques sur le lien, le navigateur tente d'ouvrir une nouvelle fenêtre avec ce nom, voit qu'il en existe déjà une et donc la remplace.

neeteex

27 May 2009 à 10:55

Agylus a écrit :

_blank ouvre une nouvelle fenêtre sans lui attribuer de nom, donc à chaque clic sur le lien, une nouvelle fenêtre va s'ouvrir. Mettre autre chose que _blank (à l'exception de _self, _parent et _top) confère à la nouvelle fenêtre un nom. Donc quand tu recliques sur le lien, le navigateur tente d'ouvrir une nouvelle fenêtre avec ce nom, voit qu'il en existe déjà une et donc la remplace.

C'est un bug de Firefox qui fait qu'il en ouvre 2 ?

En cherchant des explications sur les différentes "target", je suis tombé sur l'affirmation que c'était déprécié sur http://www.floatthatbox.com/articles/target-blank.php : bizarre, le validateur a pas l'air de s'en soucier pour autant.

floatthatbox.com a écrit :

Comme vous le savez probablement déjà, on peut forcer l'ouverture d'un lien dans une nouvelle fenêtre en lui ajoutant l'attribut target auquel on donne la valeur "_blank". Cet attribut a toutefois été déprécié en (X)HTML strict. Pourquoi ? Tout simplement parce qu'il s'agit d'une propriété affectant le comportement des documents et que HTML et XHTML stricts mettent l'accent sur la séparation entre contenu, présentation et comportement (ce qui permet notamment une plus grande flexibilité vis-à-vis de l'utilisateur et de son équipement matériel et logiciel).

Heyoan

27 May 2009 à 15:01

Agylus a écrit :
Et on peut voir sur ce lien qu'un input peut se trouver dans une balise a.

Oui, j'avais effectivement vérifié. Smiley cligne

Cela n'empêche pas que des éléments INPUT (même dans des liens) n'ont rien à faire hors des formulaires. Et d'ailleurs ce n'est pas parce que hiérarchiquement parlant c'est valide que ça a le moindre sens de les mettre dans des liens (ou alors qu'on m'explique...) : ça me rappelle un récent sujet où quelqu'un avait mis, après le message du validateur document type does not allow element "input" here; ses INPUT dans un élément INS.

Agylus

27 May 2009 à 15:12

Heyoan a écrit :
Cela n'empêche pas que des éléments INPUT (même dans des liens) n'ont rien à faire hors des formulaires. Et d'ailleurs ce n'est pas parce que hiérarchiquement parlant c'est valide que ça a le moindre sens de les mettre dans des liens (ou alors qu'on m'explique...)

Je n'ai pas dit le contraire. Smiley lol

Et je suis entièrement d'accord avec toi.

Je réagissais juste au fait que tu t'étonnes que le validateur ne tique pas en trouvant des input hors formulaire. Smiley lol

neeteex

27 May 2009 à 15:14

Heyoan a écrit :
ce n'est pas parce que hiérarchiquement parlant c'est valide que ça a le moindre sens de les mettre dans des liens (ou alors qu'on m'explique...) : ça me rappelle un récent sujet où quelqu'un avait mis, après le message du validateur document type does not allow element "input" here; ses INPUT dans un élément INS.

Pour la même raison : puisque le but est de 1) valider et 2) avoir l'aspect que l'on souhaite, ça devient vraiment difficile de 3) se donner des impératifs supplémentaires de clarté sémantique (même s'ils sont souhaitables).

Ici, mettre un bouton dans un lien, c'est intéressant pour avoir un lien qui ressemble à un bouton, c'est le seul sens que c'est supposé avoir. Après, il semble que ce soit difficile de les "coller" les uns aux autres, et l'effet des "target" est assez surprenant Smiley eek

, donc c'est pas la panacée. Reste que c'est une solution que j'avais cru intéressante. Smiley sweatdrop

Heyoan

27 May 2009 à 15:21

Agylus a écrit :
Je réagissais juste au fait que tu t'étonnes que le validateur ne tique pas en trouvant des input hors formulaire.

Ah OK.

neeteex a écrit :
Ici, mettre un bouton dans un lien, c'est intéressant pour avoir un lien qui ressemble à un bouton, c'est le seul sens que c'est supposé avoir.

Eh bien en général on utilise une image en background sur le LI ou sur le A (plutôt sur le A ce qui permet d'avoir un rendu différent sur le a:hover, a:active).

Sinon, pour un "bouton tout simple" il suffit d'utiliser quelque chose comme

li {
   border: 1px solid #000;
}

Modifié par Heyoan (27 May 2009 - 15:24)

Sujet clos

CSS et mise en forme, CSS3

Coller des boutons-liens