Plusieurs ID pour une seule balise ?? [réglé]

Bonjour,

Je me suis rendu compte dans le cadre d'un boulot de débogage CSS que l'utilisation de l'attribut id pouvait être sujet à "conflit d'intérêt" entre designer et développeur, certaines valeurs d'id pouvant être générées par le moteur du site et de ce fait avoir des allures illisibles et... variables??

Difficiles de les exploiter dans une feuille CSS donc.

Aussi demandais-je au développeur concerné si l'attribut id était de préférence à laisser à l'usage du développement. Il me répondit que oui, "pour bien faire". Quitte alors à se rabattre en design sur l'attribut class, même si sa valeur devait être unique, comme on le ferait avec un attribut id.

Oui mais... n'est-il tout simplement pas possible que cette balise ait 2 attributs id? Plusieurs éléments ne peuvent avoir un même id, ok, mais qu'est-ce qui empêche qu'un élément ait plusieurs "étiquettes" comme l'exemple ci-dessous:

<div id="epg82l3986c3lk12zetssm" id="pagecontact">

Le moteur de rendu écraserait-il la valeur "pagecontact" pour imposer la sienne ??

Qu'en dites-vous?
Modifié par log_x (25 Oct 2011 - 23:31)

Salut,

Un attribut HTML, quel qu'il soit, ne peut pas être répété au sein d'un même élément. En revanche, certains attributs (comme l'attribut class, mais pas l'attribut id) acceptent plusieurs valeurs, séparées par une espace.

Florent, tu omets que dans la plupart des cas les identifiants sont générés par lien de parenté. Et c'est complètement inexploitable par un dév. front-end.

Alors bien sûr, on peut se baser sur le fait qu'on peut utiliser les valeurs de l'attribut Class. Mais pour un composant d'interface unique sur une page (notamment avec simple détection de présence) c'est juste très con. Cela reviendrait à priver les dévs de l'usage des Singletons ...

fvsch a écrit :
Aucune idée de ce que ça peut vouloir dire. Il doit y avoir un concept qui m'échappe; n'hésite pas à préciser.

J'avoue que ma phrase était un peu obscur .

Dans les technologies serveur concernées par cette main mise sur les IDs et que j'ai pu côtoyer, le nom du type d'élément serveur ainsi que l'identifiant serveur (pour le code behind) sont employés pour générer la valeur de l'attribut id. Cette valeur impactant également les valeurs des attributs id des éléments enfants.

Exemple Dot Net fictif (sans syntaxe ; à l'esprit) :

Élément serveur de type "Composant" avec identifiant serveur "MonComposant" soit en sortie HTML une valeur d'identifiant "Composant_MonComposant". Même logique pour les enfants, si dans cet élément, tu as un enfant de type "SousComposant" avec identifiant serveur "MonSousComposant", cela va devenir "Composant_MonComposant_SousComposant_MonSousComposant".

Après parce que quand même, c'est chiant à manipuler, il me semble qu'une méthode genre "clientID" permettait d'avoir le nom du bouzin et de pouvoir le manipuler ...
Cela a peut être changé en 2/3 ans ...

Bonsoir.

Petite question par curiosité au passage. Je n'y connais pas grand chose en .Net (que je fuis comme la peste à dire vrai), mais quel est l’intérêt pour une techno serveur de rajouter des ID dans le HTML?

Le framework génère aussi du JS ou bien?

Florian_R a écrit :
Petite question par curiosité au passage. Je n'y connais pas grand chose en .Net (que je fuis comme la peste à dire vrai), mais quel est l’intérêt pour une techno serveur de rajouter des ID dans le HTML?

Le framework génère aussi du JS ou bien?

Je me pose la même question que toi sur l'intérêt de rajouter des attributs id. Pour le reste, .Net englobe tout le contenu dans un formulaire nommé aspnetForm dont les premiers éléments enfants sont des éléments input de type "hidden" ayant pour valeur une espèce de clé très longue (donc, impossible de coder un site en .Net en HTML 4.01 ou XHTML 1.0 strict si l'on se soucie de la validité du code).

Florian_R a écrit :
Petite question par curiosité au passage. Je n'y connais pas grand chose en .Net (que je fuis comme la peste à dire vrai), mais quel est l’intérêt pour une techno serveur de rajouter des ID dans le HTML?

Je pense que je ne connais pas plus que toi mais j'ai eu l'occasion de travailler en tant qu'intégrateur sur des projets Dot Net donc je comprends un peu la logique derrière tout ça.

En fait, ce framework est conçu avec la philosophie que la couche cliente doit être simplifiée pour une mise en place des scripts par des développeurs (qui ne sont pas front). Ainsi, le développeur, pour chaque élément de la page lié au serveur :
- doit fournir un identifiant (afin qu'il puisse être utilisé dans le code behind (code serveur)) ;
- peut utiliser des attributs spécifiques qui permettent de mettre en place certains scripts.

Pour ce deuxième point, le framework se sert alors des identifiants en présence pour appliquer les scripts indiqués. Inutile de dire, qu'un développeur front-end n'a plus que ces yeux pour pleurer dans l'optique d'appliquer des scripts personnalisés. Sans parler des conflits possibles avec certains frameworks. Je le répète ces expériences datent de 2007-2008 : le constat est peut-être bien différent désormais.

Victor BRITO a écrit :
Je me pose la même question que toi sur l'intérêt de rajouter des attributs id. Pour le reste, .Net englobe tout le contenu dans un formulaire nommé aspnetForm dont les premiers éléments enfants sont des éléments input de type "hidden" ayant pour valeur une espèce de clé très longue (donc, impossible de coder un site en .Net en HTML 4.01 ou XHTML 1.0 strict si l'on se soucie de la validité du code).

Pour la clé, il s'agit si mes souvenirs sont bons d'une clé servant aux variables de session. En ce qui concerne la validité du code, c'est exact. Mais il me semble qu'à l'époque des méthodes périlleuses existaient afin de rendre ce code valide (le formulaire pour sa part étant toujours le premier enfant de l'élément body).

yodaswii a écrit :
Pour ce deuxième point, le framework se sert alors des identifiants en présence pour appliquer les scripts indiqués.

C'est effectivement sur des projets .NET que j'ai rencontré ce cas d'ID complètement farfelus. Et ils avaient bien ce genre d'utilité.

yodaswii a écrit :

Deux possibilités :
- changer de technologie serveur ;
- changer de développeur (humour partiel ).

- le développeur ne jure que par le .NET
- le développeur est mon boss

Et merci pour vos infos avisées !
Modifié par log_x (25 Oct 2011 - 23:27)