RE: [Dolibarr-dev] ajout gestion des particuliers

[Yannick Warnier]

Le jeudi 08 juin 2006 à 17:55 +0200, Loic LE BLEIS a écrit :
> Salut,
> 
> Le problème des classes multiples sur les éléments HTML (div, td, etc) c'est
> que même si ça respect le W3C ça n'est (surprize!) pas interprété par notre
> chere IE qui va prendre en compte la dernière des classes présente dans le
> CSS.

Oui en fait c'est pour ça que je me disais que mon exemple n'était pas
bien fait. En fait si je reprends mon exemple:
<td class="monstyle peutsecacher">

et que j'inverse les classes:

<td class="peutsecacher monstyle">

Alors ça marche avec IE aussi puisque "monstyle" est le seul qu'on veut
vraiment interpréter et changer, l'autre pouvant être là simplement pour
indiquer que l'élément "peut se cacher" (comme son nom l'indique :-)).

Donc dans ce dernier exemple IE interprétera bien "monstyle" mais
renverra toujours l'élément quand on cherchera pour "peutsecacher" avec
getElementsByTagName('td').
Dans le JavaScript, on substituera la string "monstyle" par
"monstylecaché" et le tour est joué. L'autre classe reste là pour la
manipulation inverse où on veut remontrer les champs cachés.

Compris? J'ai pas vraiment vérifié mais je crois qu'Hervé a donné un
exemple avec le JS/non JS (je lui fais confiance pour cette fois ;-)).

Bon, en gros c'est un hack, il faut dire ce qui est, donc oui, la
solution la plus pure est d'utiliser un ID pour chaque élément, mais tu
peux faire une pseudo-catégorie en utilisant les classes et en restant
conforme à W3C. Tu as maintenant toute la palette de possibilités. Il te
reste à choisir (mais comme Loïc veut bien mettre les IDs pour toi, le
calcul n'est plus très compliqué).
Cela dit, c'est bien joli les IDs mais ça veut dire que chaque fois
qu'on veut rajouter un élément il faut modifier la page HTML et le
JavaScript (et si on oublie ça déconne). Bah... je suis incapable de
décider sur ce coup-là. Dur dur...

Yannick