Superposition de bouton et de texte dans un onglet

Bonjour,

Je viens poser à des psécialistes une colle... Je suis sur un projet un peu particulier où il m'est interdit d'utiliser du JavaScript. J'ai cependant un formulaire à soumettre, ce dernier possédant plusieurs boutons "submit". Dans la pratique, nous utilisaons des

<input type="submit" name="cmd" />

Ca c'est pour la mécanique. Pour l'esthétisme, une partie de ces boutons doit apparaitre sous forme d'onglets. Ceux-ci doivent tous avoir la même largeur, et apparaitre sous forme de cadres contenant un lien. Hors boutons, dans de tels cas, le texte trop long devient multiligne, et tout est ok. Avec des boutons, ça se complique...

Modifier un bouton pour en faire disparaitre l'apparence, ok. Cependant, dans ce cas, les boutons adoptent un visuel monoligne, avec impossibilité de gérer la longueur. Enfin, si manuellement en faisant des retour à la ligne dans les sources mais ça passe sous Firefox, mais pas sous IE.

On a pensé à superposer 2 divs. La première contiendrait le bouton, transparent, la seconde le texte. Problème...

Dans un environnement style tableau, je n'arrive pas à accéder au bouton. Peu importe le z-index, j'ai toujorus le texte sous le curseur.

J'ai essayé de me débarasser du tableau, mais je ne suis pas arrivé à imposer la largeur maximum de l'onlet (en fait, la largeur devrait être identique pour tous...).

Est ce que quelqu'un a une solution ?

Merci par avance.

Bonjour et bienvenue,

Euh... et ça doit ressembler à quoi ce mic-mac?

Deux pistes en attendant:
- si les intitulés seront toujours les même, tu peux utiliser un <input type="image"> comme bouton de validation;
- tu as essayé d'utiliser l'élément button plutôt que input?
Modifié par Florent V. (14 Apr 2008 - 17:42)

Bonjour et merci pour le bienvenu

Ce micmac doit être accessible à tous, donc en effet pour les navigateurs pour personnes à mobilité réduite, exit JS... La présence de tous les onglets faisant des submits est motivée par le fait que toute navigation doit déclencher la sauvegarde du formulaire en cours, donc tout lien = submit + aller là où mène le lien.

Au sujet des pistes : les intitulés sont différents et nous n'avons pas envie de dépendre d'une infographie. Nous avons bien pensé à créer un générateur d'image à la volée (le projet est en java, donc à prioris ce serait peanuts) mais d'un on est pas chaud et de deux, on part du principe que une image est une image et ne doit pas représenter du texte. De plus ça coince au niveau du client. On garde la solution en ultime recours.

Button à la place d'input pose un gros problème : en fait pour gérer l'envoi de paramètres et les problèmes de compatibilité de navigateurs (pour IE, le libellé affiché = value), on utilise name="cmd" pour paramétrer les requêtes avec par exemple :

<input type="submit" name="cmd_destination1" value="destination1" />
<input type="submit" name="cmd_destination2" value="destination2" />

Au niveau de mon contôleur, je récupère le paramètre commencant par cmd_ et je regarde où il me dirige (destination1 ou 2). IE6 envoi tous les buttons, il m'est donc impossible de savoir lequel a été appuyé... Donc pas utilisable.

Bon, eh bien pas de solution pour ma part, pour les raisons suivantes:

1. Je ne visualise pas exactement ce qui vous voulez réaliser (même si je commence à m'en faire une bonne idée), et les contraintes graphiques et de comportement que cela implique.

2. J'ai quelques doutes sur l'ergonomie du machin, ce qui a tendance à me faire perdre tous mes moyens.

3. Certains postulats de base que tu expose sont erronés (je cite: «doit être accessible à tous, donc en effet pour les navigateurs pour personnes à mobilité réduite, exit JS»; et plus anecdotique: «on part du principe que une image est une image et ne doit pas représenter du texte»). Ces postulats erronés empêchent d'envisager des solutions pertinentes... dommage.

Bonjour,

Merci pour les réponses Je vais peut être reformuler le tout pour préciser ma question.

Florent V. a écrit :
Je ne visualise pas exactement ce qui vous voulez réaliser (même si je commence à m'en faire une bonne idée), et les contraintes graphiques et de comportement que cela implique.

J'ai quelques doutes sur l'ergonomie du machin, ce qui a tendance à me faire perdre tous mes moyens.

Alors, je ne suis pas venu chercher une aide sur l'ergonomie, celle-ci étant assez bien étudiée et efficace. Je pose en effet juste une question de réalisabilité (néologisme personnel... ) technique. Mon point bloquant est :

- Je souhaite soumettre un formulaire et acheminer mon visiteur vers une page.
- L'utilisateur doit avoir plusieurs moyens pour soumettre ce formulaire (= plusieurs boutons, je parle de widget ayant la fonction de bouton, c'est à dire servant à réaliser une action, celle de soumettre le formulaire).
- Cette fonctionnalité doit être réalisée sans utilisation de Javascript.
- ces différents boutons doivent avoir une apparence d'onglets (tous de la même largeur/hauteur).
- Ces boutons doivent ressembler à des liens.

Dans l'absolu, sans JavaScript, je ne connais que les balises <input type="submit">, <input type="image"> et <button type="submit">. Le texte à afficher doit être mis en forme (retour à la ligne en fonction de la longeur). Submit ne semble pas le permettre. Button a un comportement pas acceptable sous IE6. Image, on ne préfère pas l'utiliser (j'y reviens).

J'ai essayé une mise en page avec un tableau à une seule ligne ou une liste horizontale. Dans le cas de boutons, la mise en forme du texte semble impossible (width fixé, si le texte déborde, il déborde, peu importe le heigth).

J'ai essayé alors de ruser : un bouton vide de texte (transparent d'ailleurs, donc visuellement invisible) et le texte à coté. le tout superposé. Lorsque je les met dans un tableau, le bouton semble inaccessible du fait que la div du texte le masque. Dans le contexte de liste, j'ai pas l'impression de pouvoir jouer sur les tailles affichée...

Donc avez vous une solution pour répondre à ces contraintes ?

a écrit :
Certains postulats de base que tu expose sont erronés (je cite: «doit être accessible à tous, donc en effet pour les navigateurs pour personnes à mobilité réduite, exit JS»;

Non, justement, je parle d'accessibilité. Certains navigateurs spécialisés ne prennent pas en charge Javascript, donc je ne peux utiliser Javascript.

a écrit :
et plus anecdotique: «on part du principe que une image est une image et ne doit pas représenter du texte»).

C'est en effet plus anecdotique, et ce pourrait être la solution ultime envisageable. Seulement, mis à part que les liens sont textuels et que cette solution nécessite de bien blinder les balises (cause d'accessibilité, prend le cas des outils à synthèse vocale), pour ces mêmes raisons d'accessibilité on préfère éviter. L'autre problème est que soit cela nécessite une intervention lourde pour changer un libellé (modification d'image) soit de développer un générateur d'image. Avec à nouveau une intervention lourde si il y a une grosse modification.

a écrit :
Ces postulats erronés empêchent d'envisager des solutions pertinentes... dommage.

Comme je l'ai dit, ma demande concerne plus le coté technique de la réalisation, je crois qu'on a fait le tour déjà de la pertinence des solutions envisageables. Merci néanmoins de ton intérêt.
Modifié par martopioche (15 Apr 2008 - 10:53)

J'ai une solution en tête, mais elle ne colle pas avec les postulats formulés. Pour information, il s'agirait d'utiliser JavaScript intelligemment.

martopioche a écrit :
Non, justement, je parle d'accessibilité. Certains navigateurs spécialisés ne prennent pas en charge Javascript, donc je ne peux utiliser Javascript.

Je ne suis pas expert en accessibilité, mais je m'y connais juste assez pour dire que ce raisonnement est infondé. Détaillons:

martopioche a écrit :
Certains navigateurs spécialisés ne prennent pas en charge Javascript

C'est vrai pour certains, tandis que d'autres prennent en charge Javascript (la plupart des lecteurs d'écran le font). Parmi les navigateurs ne prenant pas en charge Javascript, on peut citer certains navigateurs pour mobiles, ou tout simplement les navigateurs «classiques» lorsque Javascript y est désactivé.

martopioche a écrit :
donc je ne peux utiliser Javascript

Faux.
Rien n'empêche de prévoir un fonctionnement de base efficace sans Javascript, et d'utiliser du Javascript non intrusif en surcouche pour quelques améliorations ergonomiques (les moyens secondaire de valider le formulaire, c'est à dire ici les onglets).

Pour revenir à ta question technique: je ne pense pas qu'il soit possible de faire exactement ce que tu souhaites avec des <input type="image"> (si tu ne souhaites pas d'images...), <input type="submit"> (trop limité pour la mise en forme) ou <button type="submit"> (plus souple, mais ne répondant apparemment pas à ton besoin technique). De plus, j'ai de sérieux doutes sur l'accessibilité d'un formulaire qui placerait en entrée (c'est à dire avant les champs de formulaire à remplir) une série de boutons de validation, aux intitulés pas forcément limpides. Disons que dans le cadre d'un accès linéaire au contenu, le principe de clarté n'est pas vraiment respecté.

J'utiliserais donc les onglets uniquement comme un indicateur de progression, et envisagerais dans un deuxième temps une solution Javascript pour les rendre actif. À voir s'il faut les rendre actif uniquement au survol ou également au focus.

Ça me semble être la solution la plus efficace et la plus élégante.