11548 sujets

JavaScript, DOM et API Web HTML5

Bonjour à tous,

j'ai installé la dernière version de jquery 1.6.2.

malgré les infos sur le site de jquery je n'arrive pas à percevoir la différence entre:
$('#id').prop()

$('#id').attr()

$('#id').removeProp()

$('#id').removeAttr()


Pour être logique, pour modifier le DOM dynamiquement, on devrait toujours utiliser .prop et mettre au oubliette .attr().

Si quelqu'un peut m'éclairer sur la manière la plus propre de coder ca serait cool.

Merci
La documentation est pourtant claire sur ce sujet.

- attr pour les attributs (href, src, name...).
- prop pour les propriétés (checked, selected, disabled...).

Exemple :


<input type="checkbox"  checked="checked" />


$('input').attr('checked') renvoi : "checked" (ce qui sert pas à grand chose).

$('input').prop('checked') renvoi un booléen : true si la case est cochée, false si elle ne l'est pas

http://api.jquery.com/prop/
Modifié par jb_gfx (29 Jul 2011 - 11:22)
Oui mais du coup,

les propriétés interviennent sur l'aspect de l’élément et l'attribut précise l’élément. l'attribut rôle doit est un attribut et pas une propriété.

La différence reste assez subtile. Non?

La nouvelle version de jquery est juste plus correcte sémantiquement .

Je te remercie pour ta réponse.
Je reste sur le pb car ca mérite à mes yeux d'être éclairci!

quand on est sur mozilla, avec firebug, dans la console, on ajoute une propriété de la manière suivante:
$('[type="checkbox"]').prop('checked',true);

Certes, mes box sont cochées mais en parcourant l'élement, l'attribut checkbox n'apparaît pas. si on fait au contraire:
$('[type="checkbox"]').attr('checked',true);

alors là, l'attribut 'checkbox="checkbox"' apparait dans l'élément.
De plus dans les recommandations W3C, il est bien écrit que checkbox est un attribut. Quand on recherche propriétés, la première chose qui ressort c'est propriété CSS et pas HTML.
C'est bien qu'il y a un truc?
Je trouve vraiment pas ca très clair.
Si quelqu'un a une idée sur la question je suis preneuse Smiley ravi
Bonjour,

Je remonte ce post car je rencontre également moi-même un petit problème de compréhension sur "attr" et "prop"... Et la doc de jQuery n'est pas si claire à ce sujet. Techniquement, un élément html ne contient que des attributs, pas de propriété. Alors quelle propriété récupère la méthode prop() ?

L'attribut "checked" avec html 5 peut être vide ou contenir la valeur "checked" (ou toute autre valeur non normalisée).

Donc si j'ai bien compris, lorsque l'attribut "checked" contient une valeur, "attr" et "prop" renvoient qqch. Par contre, si l'attribut "checked" ne contient pas de valeur, seul "prop" renverra la bonne valeur, c'est bien cela ?

Si c'est la seule utilité, je ne trouve pas ce choix très heureux de la part de jQuery, et je ne vois pas trop l'utilité de faire deux méthodes. C'est pourquoi j'ai besoin d'un peu plus d'explications. De plus, il m'est déjà arrivé de ne pas avoir la bonne valeur avec prop()...

Merci d'avance si vous pouvez m'aider.

Sébastien.
Bonsoir c'est exactement ca!

l'idéal c'est d'utiliser prop pour checked/ selected ... pour avoir true ou false.

Voilou

C'est sympa mais il faut tout mettre a jour pour etre correcte

Missa
Bonjour,

Et merci pour ta réponse.

La mauvaise valeur avec prop() c'était lorsqu'une série de checkbox étaient cochées grâce à une autre checkbox (exemple : "sélectionner tout"). prop() renvoyait false sur ces checkbox mais attr() renvoyait la bonne valeur. Le code était un peu plus compliqué que cela car il y avait des tests et certaines cases ne pouvaient être cochées qu'avec conditions, etc...

Cela s'est produit suite à une mise à jour de jQuery. J'ai galéré un bout de temps à comprendre pourquoi cette mise à jour plantait mon code (merci à eux... la prochaine fois je lirai plus vite la doc...) et quand j'ai enfin trouvé le pourquoi, j'ai tenté de remplacer attr() par prop(), ce qui m'a donné l'erreur ci-dessus. Dans tous les cas, je pense que l'erreur venait de moi car mon code mélangeait alors des anciennes attr() et des nouvelles prop() et je pense que ce mélange ne devait pas plaire à jQuery. J'ai donc remis l'ancienne version de jQuery pour ce projet et laissé mon code en l'état qui fonctionnait très bien avant.

Quoi qu'il en soit, jQuery est un très bon fwk, mais ce choix là est largement discutable... qui plus est quand la rétrocompatibilité n'est pas maintenue !

Bonne journée.

Sébastien.
Moi j'ai pris l'habitude suivante:
Pas de mise à jour de jQuery, je prends la dernière version en cours et la conserve telle quelle durant la vie d'un site.
jQuery a tendance à devenir une usine à gaz et les emm... apportés par les mises à jour ne sont pas compensés par une utilité plus grande.

Donc exit les mises à jour.
Bonsoir,

La mise à jour reste tout de même nécessaire et importante

Certes sur ce point, dommage que la rétrocompatibilité n'ait pas été respectée.

Mais il ne fait pas négliger que les mises à jour de jquery permettent d'améliorer les performances du framework et qu'a grande échelle quand on l'utilise pour des sites à forte fréquentation, tu n'as pas le choix de mettre en place les mises à jour.

La facilité de jQuery est bien mais il faut essayer de voir plus haut et de se dire est ce que mon code est performant. Du coup, pour ce point, obligé de mettre en place les mises à jour.

Par ailleurs, il ne faut pas oublier que jQuery est la pour nous faire "oublier" la différence d'interprétation des navigateurs. La création de ce prop est nécessaire car il permet d'avoir toujours la même réponse quelque soit le navigateur à contrario de attr.

Donc certes il n'y a pas eu de rétrocompatibilité mais il ne faut pas lancer la pierre à jQuery qui a constaté un pb et qui essayé d'apporter une solution. Certes contraignante, mais ca reste une solution. Smiley biggol

C'est juste pour toi, essaie de revoir ton jugement sur les mises à jour, elles sont nécessaires. Et puis c'est ca le metier de développeur, se prendre la tête a optimiser et a toujours vouloir évoluer... Dès fois, il y a des moments durs, mais la pilule passe assez vite. Smiley biggrin

Je vous souhaite une bonne soirée et de bonnes fêtes de fin d'année. Smiley confused

Missa
Bonjour et bonne année 2012 à toutes et tous, etc, etc... Smiley smile

Pour clore ma vision des choses : pour le mises à jour, je préfère les faire pour obtenir les correctifs, les améliorations, les performances, etc...

Concernant attr, la c'est différent. En html, il n'y a que des attributs. Soit la case ou la radio est cochée et soit elle ne l'est pas. C'est binaire, il n'y a pas plus simple... La programmation, c'est déjà bien assez un métier qui ruine les coiffeurs...

Sinon, on ne s'en sort plus, ils vont faire pareil avec les select : il va y avoir la valeur en html et "l'autre" ? Et puis pourquoi ne pas faire pareil dans ce cas avec tous les champs ? Car pour tout type de champ il y a la valeur au chargement de la page et la valeur qu'on entre dans le champ (soit manuellement, soit avec un script, etc...). Et tout ça est bien contenu dans un seul et même attribut "value". Il n'y a bien qu'une seule et même méthode val() qui récupère la valeur, pas une valAttr() ou une valProp()... Il ne faut pas oublier qu'un bouton ou qu'une liste est simplement un "déguisement" du texte en html (c'est très simplifié comme explication).

Pour les différences de navigateurs, il suffisait simplement de modifier attr() pour qu'il renvoie la bonne valeur (ce qui a d'ailleurs à priori était corrigé dans les dernières versions vu les plaintes des utilisateurs), car comme tu l'as dit, un fwk est là pour gommer ces différences entre navigateurs, pas pour créer des méthodes en double en laissant celles qui ne "marchent pas" et celles qui marchent...

Donc pas le choix, je vais jongler avec les prop et les attr à l'avenir, mais je persiste et je signe, mauvais point, heureusement à priori corrigé puisque attr() semble appeler prop() en interne dorénavant.

Bonne continuation à tous.