[Résolu] <ol start="">

Bonjour,
Je dois faire un formulaire conséquent, avec bon nombre de boutons radio. Je pars d'un modèle excel, le rendu doit être quasiment identique...

La première question: les lignes sont présentées comme suit:

Points à traiter
1. Tenue générale
1.1 Extérieur
Ligne 1
Ligne 2
Ligne 3
1.2 Intérieur
Ordre
Rangement

Et ainsi de suite.

Si je pars sur une construction avec des <fieldset>, <legend>, <label>, etc je comptais découper mon texte comme suit:

<form method="post" name="" action="" enctype="">
	<fieldset>
		<legend>1. Tenue Générale</legend>
		<ol start="">
		<li>Extérieur
			<ul>
			<li><label for="">Ligne1</label><input type="radio" class="input_radio" name="" id="" /></li>
			<li><label for="">Ligne2</label><input type="radio" class="input_radio" name="" id="" /></li>
			<li><label for="">Ligne3</label><input type="radio" class="input_radio" name="" id="" /></li></ul>
		</li>
	</fieldset>

<input type="submit" name="" value=""  />
	
</form>

-> Comment faire démarrer la première ligne de ma liste ordonnée par 1.1?

j'ai vaguement pensé à utiliser <ol start="">, mais finalement je ne vois pas comment


La seconde question est de savoir si je pars sur une mise en page "tableau" (peut-on considérer toutes les lignes comme des données tabulaires?) ou si je découpe mon formulaire avec les balises <fieldset>, <legend>, <label>,...
Au premier abord, je penche pour la seconde solution, mais j'ai bien peur que la mise en page soit compliquée à mettre en oeuvre (le formulaire sera utilisé avec IE6)

Vous auriez des avis là-dessus?
Modifié par speedlab (05 Aug 2010 - 22:47)

Salut,

si tu n'avais pas parlé de IE6 je t'aurais conseillé d'utiliser counter-reset mais du coup je ne vois pas comment tu peux faire en n'utilisant que <ol start=""> .

S'il ne s'agit que de présentation pourquoi ne pas gérer ça directement en PHP (incrémentation) ?

Salut,

Heyoan a écrit :
S'il ne s'agit que de présentation pourquoi ne pas gérer ça directement en PHP (incrémentation) ?

Je ne pensais pas à le faire en php: je gagnerai du temps à mettre le texte en dur… L'applicatif se résume à un seul formulaire, et les lignes du formulaire n'ont pas pour vocation de changer.

J'ai continué un peu les recherches pour finalement tomber sur ce post (2005!)

Comme le précise Laurent,

Laurent Denis a écrit :
Concrètement, pour des éléments non liste (titres), voire même pour certains cas de listes ordonnées, on utilisera un contenu HTML en dur, et non CSS ou même start.

… Tant pis

En tous cas, merci pour les pistes.

Quoiqu'il en soit, une appréciation pour la seconde question? (mise en page "tableau", ou construction d'un formulaire standard?)

speedlab a écrit :
Quoiqu'il en soit, une appréciation pour la seconde question? (mise en page "tableau", ou construction d'un formulaire standard?)

Ah ! J'avais pas fait gaffe : pour moi on ne peut pas "considérer toutes les lignes comme des données tabulaires" (bien essayé ) mais cela n'empêche pas que l'utilisation d'un tableau pour la mise en page de formulaires simplifie parfois bien la vie.

Heyoan a écrit :
pour moi on ne peut pas "considérer toutes les lignes comme des données tabulaires" (bien essayé ).

…Bha j'ai tenté

En tous cas, merci pour les appréciations, je me suis lancé dans une construction de formulaire "classique", sans <table>, et advienne que pourra!

Salut,

speedlab a écrit :
Quoiqu'il en soit, une appréciation pour la seconde question? (mise en page "tableau", ou construction d'un formulaire standard?)

Il faudrait voir de quelles lignes va exactement être constitué ton formulaire, mais si la partie qui te préoccupe est celle des titres de section (1. Tenue générale, 1.1 Extérieur, etc.), je ne crois pas que cela soit incompatible avec l'utilisation d'un tableau, du moment que tu balises bien tes entêtes (voir http://www.w3.org/TR/html401/struct/tables.html#non-visual-rendering et notamment l'exemple de la section 11.4.2)

Hello marcv,

j'ai beau lire l'article que tu cites je ne vois toujours pas en quoi on aurait ici des données tabulaires. Pour dire ça autrement de quelles colonnes et de quelles lignes serait constitué ton tableau ?

Je pense que marcv (salut ) a anticipé la totalité du formulaire…

Points à traiter [ oui] [ non] [sans objet]
1. Tenue générale
1.1 Extérieur
Ligne 1 [bt radio] [bt radio] [bt radio]
Ligne 2 [bt radio] [bt radio] [bt radio]
Ligne 3 [bt radio] [bt radio] [bt radio]
1.2 Intérieur
Ordre [bt radio] [bt radio] [bt radio]
Rangement [bt radio] [bt radio] [bt radio]

Et ainsi de suite.

C'est pour ça que j'avais précisé

speedlab a écrit :
Je dois faire un formulaire conséquent, avec bon nombre de boutons radio. Je pars d'un modèle excel, le rendu doit être quasiment identique...

On se trouve donc bien en présence de lignes et colonnes: chaque bouton radio répond à oui, non ou sans objet.

Ah ok. Je n'avais pas compris qu'à chaque rubrique correspondaient toujours les trois mêmes choix possibles.

Non c'est de ma faute, c'est en lisant le post de marcv que j'ai percuté: je n'ai pas été assez clair. Tu comprends mieux mon hésitation entre tableau et formulaire de base?

Je pars sur un formulaire standard, que je mixerai peut-être avec des <table>

Quoiqu'il en soit, pour la première question (qui était le sujet principal), vu que je ne peux pas utiliser counter-reset et consorts (compatibilité IE6), je vais mettre un petit [résolu].

Encore merci pour les réponses et les pistes.
Modifié par speedlab (05 Aug 2010 - 22:47)

Des remarques en vrac:

1. Le OL dans l'exemple de code donné, strictement aucun intérêt. J'ai vu un UL dans un OL, et là tout de suite je me suis dit «carton rouge». Non mais ho.

2. Je vois ça:

plan a écrit :
1. Tenue générale
1.1 Extérieur
1.2 Intérieur

Et je pense à un plan de document avec des titres HN. Des titres HN pour structurer les grands niveaux d'un formulaire, c'est d'ailleurs très bien. Ah ben cool alors. Quand aux numéros, soit en s'amuse à les faire en CSS 2.1 sans support de IE 6-7, soit on les met en dur et ça ira très bien. À noter: l'information sera accessible en dur, pas en CSS.

3. Pour le coup des lignes avec les trois choix à chaque fois, il y a deux cas de figure. Soit on a les intitulés des choix comme des en-têtes de colonne, et dans ce cas on fait un tableau avec des <th scope="col">oui|non|sans objet</th> et des <th scope="row">Ligne 1|2|3</th>. Soit on répète les «oui», «non», «sans objet», et alors chaque ligne doit être structurée ainsi en HTML:

<fieldset>
  <legend>Ligne 1</legend>
  <label for="l1c1">Oui <input type="checkbox" id="l1c1"></label>
  <label for="l1c2">Non <input type="checkbox" id="l1c2"></label>
  <label for="l1c3">Sans objet <input type="checkbox" id="l1c3"></label>
</fieldset>

(le tout pouvant être linéarisé en CSS, moyennant un span autour ou dans le LEGEND, peut-être, je sais plus exactement).
Le but de cette structure est d'associer les labels "Oui", "Non", "Sans objet" à un label commun "Ligne 1". Et on recommence pour la ligne suivante.
Modifié par Florent V. (08 Aug 2010 - 02:13)

Salut Florent,

Florent V. a écrit :
1. Le OL dans l'exemple de code donné, strictement aucun intérêt. J'ai vu un UL dans un OL, et là tout de suite je me suis dit «carton rouge». Non mais ho.

Qu'est-ce qui nous empêche d'avoir une liste ordonnée qui contient une liste à puce?

Pour l'idée des titres en HN, bonne piste, mais…
Mon idée était plutôt de partir avec une structure en <fieldset>, suivis de <legend> (qui correspondrait à tes HN): il me semblait que c'était plus approprié.

Je crois que je vais coder un début de formulaire, je reposterai pour avoir vos avis

speedlab a écrit :
Qu'est-ce qui nous empêche d'avoir une liste ordonnée qui contient une liste à puce?

Rien, c'est juste inutilement verbeux.

speedlab a écrit :
Mon idée était plutôt de partir avec une structure en <fieldset>, suivis de <legend> (qui correspondrait à tes HN): il me semblait que c'était plus approprié.

Je suis assez réservé sur l'usage des fieldset+légende pour diviser un formulaire long en grandes parties.

Les spécifications HTML4 et 5 disent simplement que FIELDSET sert à associer un nom (le contenu du premier LEGEND enfant ou descendant de l'élément FIELDSET) aux champs de formulaire contenus dans le FIELDSET. Donc ça colle plus ou moins avec l'usage courant des FIELDSET+LEGEND pour créer des titres dans les formulaires.

UAAG 1.0 est par contre plus précis sur ce que les user agents devraient faire de ces éléments. Et l'usage typique qui se dégage de cette recommandation, c'est celui que je donnais en exemple plus haut. Un lecteur d'écran comme JAWS implémente en partie cette recommandation, et dans certains modes de lecture il va répéter le contenu du LEGEND avant celui de chaque de chaque LABEL dans le FIELDSET. Donc un LEGEND servant de titre (plutôt que de label global pour une série de boutons radio ou checkbox) peut parasiter la lecture au lieu de l'aider.

Par ailleurs, les lecteurs d'écran ont peu ou pas de mécanismes pour naviguer d'un FIELDSET à l'autre, tandis qu'ils ont des mécanismes pour naviguer d'un titre à un autre. Vu ce que UAAG dit de FIELDSET et LEGEND, ça ne risque pas d'évoluer des masses.
Donc structurer un formulaire long avec des HN est à priori plus accessible.

Ma recommandation:
- FIELDSET + LEGEND pour rassembler une série de boutons radio ou checkbox (chacun avec son LABEL explicite) sous un même intitulé.
- HN pour structurer les formulaires complexes en donnant un titre aux différentes parties.

Re,
Donc je suis pour l'instant parti sur ce code là:

	<h1>1. Tenue Générale</h1>
	
	<h2>1.1 Extérieur</h2>
	
	<fieldset>
	<span style="float: left"><legend>Voie pompiers</legend></span>
		<label for="tenue1_1_1_oui">Oui</label><input type="radio" id="tenue1_1_1_oui" />
		<label for="tenue1_1_1_non">Non</label><input type="radio" id="tenue1_1_1_non" />
		<label for="tenue1_1_1_sansObjet">Sans objet</label><input type="radio" id="tenue1_1_1_sansObjet" />
	</fieldset>

	<fieldset>
	<span style="float: left"><legend>Propreté</legend></span>
		<label for="tenue1_1_2_oui">Oui</label><input type="radio" id="tenue1_1_2_oui" />
		<label for="tenue1_1_2_non">Non</label><input type="radio" id="tenue1_1_2_non" />
		<label for="tenue1_1_3_sansObjet">Sans objet</label><input type="radio" id="tenue1_1_3_sansObjet" />
	</fieldset>
		
	<h2>1.2 Intérieur</h2>

	<fieldset>
	<span style="float: left"><legend>Ordre et propreté</legend></span>
		<label for="tenue1_2_1_oui">Oui</label><input type="radio" id="tenue1_2_1_oui" />
		<label for="tenue1_2_1_non">Non</label><input type="radio" id="tenue1_2_1_non" />
		<label for="tenue1_2_1_sansObjet">Sans objet</label><input type="radio" id="tenue1_2_1_sansObjet" />
	</fieldset>

	<fieldset>
	<span style="float: left"><legend>Dépoussiérage</legend></span>
		<label for="tenue1_2_2_oui">Oui</label><input type="radio" id="tenue1_2_2_oui" />
		<label for="tenue1_2_2_non">Non</label><input type="radio" id="tenue1_2_2_non" />
		<label for="tenue1_2_2_sansObjet">Sans objet</label><input type="radio" id="tenue1_2_2_sansObjet" />
	</fieldset>

Et ainsi de suite...

Réflexion faite, je ne suis pas sûr de l'intérêt de répéter les «oui», «non», «sans objet». Enfin je verrai, quitte à utiliser effectivement des <th>.

Toutefois, j'aurais besoin de deux petites précisions:
1) Dans le code ci-dessus, j'ai effectivement entouré mes legend par <span style="float: left">. La question est pourquoi <legend style="float: left"> ne fonctionne pas (j'ai essayé, hein, têtu comme je suis)? C'est pourtant une balise de type inline, le float: left devrait... faire flotter <legend> à gauche

2) Tu indiques dans un de tes messages:

Florent V. a écrit :

<fieldset>
  <legend>Ligne 1</legend>
  <label for="l1c1">Oui <input type="checkbox" id="l1c1"></label>
  <label for="l1c2">Non <input type="checkbox" id="l1c2"></label>
  <label for="l1c3">Sans objet <input type="checkbox" id="l1c3"></label>
</fieldset>

Concernant le label, il ne devrait pas être fermé avant l'input, plutôt que de l'englober?
Modifié par speedlab (11 Aug 2010 - 16:53)

speedlab a écrit :
1) Dans le code ci-dessus, j'ai effectivement entouré mes legend par <span style="float: left">. La question est pourquoi <legend style="float: left"> ne fonctionne pas (j'ai essayé, hein, têtu comme je suis)? C'est pourtant une balise de type inline, le float: left devrait... faire flotter <legend> à gauche

Ça marche dans Firefox 3.6, mais pas forcément dans les versions précédentes et dans les autres navigateurs. Je n'ai pas testé en détail les limites à la mise en forme des éléments LEGEND.

Je pense que les problèmes rencontrés avec cet élément viennent de la mise en forme historique dans Netscape ou les premiers IE, qui a dû être réalisée «en dur» dans le navigateur plutôt qu'avec du CSS tout propre que l'on peut contredire dans une feuille de styles auteur.

speedlab a écrit :
2) Tu indiques dans un de tes messages:
<label for="l1c1">Oui <input type="checkbox" id="l1c1"></label>
Concernant le label, il ne devrait pas être fermé avant l'input, plutôt que de l'englober?

Bah non, pas forcément. On déconseille les labels implicites (<label>Blabla <input></label>), parce que pas supportés correctement par cette faignasse de JAWS. Par contre, si tu utilises la même structure mais rend le label explicite avec un attribut for qui va bien, ça marche à nouveau dans les lecteurs d'écran. C'est le label implicite-explicite.

On peut même utiliser cette technique pour faire des trucs tordus (voir billet, exemple et commentaires): Accessibilité des champs de formulaires, une nouvelle technique ?

1) Ok pour <legend>, je n'avais jamais été confronté à une mise en page de type inline, je n'y avais jamais fait attention… Promis j'essaie de m'en rappeler.

2) je bookmarke le lien chez Temesis: tu as raison, c'est tordu, mais intéressant.
C'est pas toi qui disait <mode=cheveux en 4 />?
Modifié par speedlab (11 Aug 2010 - 20:27)

Hello,
Je reviens sur le sujet pour un détail (euhum…) sur cette ligne:

<span style="float: left"><legend>faux texte</legend></span> 

Est-il possible de donner une taille (fixe ou pourcentage) à <legend>?
L'idée étant de faire un retour automatique à la ligne si le faux texte est trop long pour, disons, 400px, par exemple.

Le code ci-dessous n'étant pas correct sous ie6 et ff3

<span style="float: left; width: 400px;"><legend>faux texte</legend></span>

Quelqu'un a déjà donné une taille fixe à <legend>?

Salut,

ben comme je te le disais récemment ton code est invalide puisque l'élément FIELDSET doit être un élément enfant (c'est à dire descendant de premier niveau) de l'élément FORM.

Pour un intranet avec IE6 ce n'est pas un problème mais dans Firefox le code va être corrigé automatiquement et ce qui va être généré c'est :

<span></span><legend>faux texte</legend> 

Donc il est inutile de styler ce SPAN pour FF. Par contre il suffit de styler LEGEND correctement et ça fonctionnera.

Sinon pour IE6 je ne vois pas pourquoi ça ne fonctionnerait pas : tu as une page de test ?

Salut,
Mmmh, de rage et de colère, cette nuit, je suis repassé avec des balises <p> classées, parce qu'il faut que j'avance

Mais je n'ai pas réussi à styler un <legend></legend> à 400px avec un texte long. Les deux exemples suivant ne fonctionnent pas à minima sur firefox3 mac…

Exemple1:

<legend style="background-color:#CC0000; width: 400px;">Propreté (absence de papiers volants aux abords du site, de déchets autour des bâtiments…)</legend>

Exemple2:

<legend><span style="background-color:#CC0000; width: 400px;">Propreté (absence de papiers volants aux abords du site, de déchets autour des bâtiments…)</span></legend>

Exemple 1: il faut à priori changer la valeur par défaut de white-space:

<legend style="background:red; max-width:400px; white-space:normal;">Propreté (absence de papiers volants aux abords du site, de déchets autour des bâtiments…)</legend>

Exemple 2: un SPAN sera par défaut en display:inline, donc la propriété width est ignorée.