Dev Faq
9
votes

Différence entre trouver ('option [sélectionné]') et trouver ("option"). Filtre ('[sélectionné]')

Scénario:

J'ai reçu 2 expressions jQuery: p> xxx pré>

Quelle moyenne (supposons qu'il n'y a qu'un seul sélectionner code> dans le document, car Simplicité): p>

  • a fort>: obtenez le Sélectionnez CODE>, puis recherchez toutes les «CODE> OPTION CODE> DÉMPENDANTS ATTRAIT UN ATTRACTE NAMÉ NOMMÉ SOCIÉ CODE>.
  • b fort>: obtenez le Sélectionnez CODE>, puis recherchez l'option code> code> des descendants, puis filtrez par ceux qui ont un attribut nommé sélectionné . li> ul>

    Comportement attendu: h2>

    A fort> et B fort> devrait donner le même résultat. P>

    Comportement réel: h2>

    Une fois que l'utilisateur a changé la sélection dans la liste déroulante, P>

    • A fort> retourne l'option em> sélectionnée em> (code> code>. li>
    • b strong> renvoie l'option nouvel em> (code> code>. li> ul>

      Question: H2>

      Alors pourquoi sont-ils différents? Est ma compréhension des sélecteurs de CSS incorrects? P>

      Démo en direct: H2>

      Démo en direct est ici grève> ici . P>

      Code source: h2>

      html fort>: p> xxx pré>

      JavaScript strong>: p> 

      +---------------------------+--------------+---------------------+---------+-----+
|          Browser          | Environment  |       jQuery        |    A    |  B  |
+---------------------------+--------------+---------------------+---------+-----+
| Chrome 22.0.1229.94m      | Win7         | 1.8.2, 1.7.2, 1.6.4 | default | new |
| Chrome 23.0.1271.64 m     | Win7         | 1.8.2, 1.7.2, 1.6.4 | default | new |
| Firefox 15.0.1            | Win7         | 1.8.2, 1.7.2, 1.6.4 | default | new |
| Firefox 16.0.2            | Win7         | 1.8.2, 1.7.2, 1.6.4 | default | new |
| IE 6                      | WinXP        | 1.8.2, 1.7.2, 1.6.4 | *new*   | new |
| IE 9                      | Win7         | 1.8.2, 1.7.2, 1.6.4 | default | new |
| Opera 12.02               | Win7         | 1.8.2, 1.7.2, 1.6.4 | default | new |
| Opera 12.10               | Win7         | 1.8.2, 1.7.2, 1.6.4 | default | new |
| Safari 5.1.7 (7534.57.2)  | Win7         | 1.8.2, 1.7.2, 1.6.4 | default | new |
+---------------------------+--------------+---------------------+---------+-----+
| Chrome 22.0.1229.94       | MacOS 10.7.5 | 1.8.2, 1.7.2, 1.6.4 | default | new |
| Chrome 23.0.1271.64       | MacOS 10.7.5 | 1.8.2, 1.7.2, 1.6.4 | default | new |
| Firefox 13.0              | MacOS 10.7.5 | 1.8.2, 1.7.2, 1.6.4 | default | new |
| Firefox 14.0.1            | MacOS 10.7.5 | 1.8.2, 1.7.2, 1.6.4 | default | new |
| Firefox 16.0.2            | MacOS 10.7.5 | 1.8.2, 1.7.2, 1.6.4 | default | new |
| Opera 12.01               | MacOS 10.7.5 | 1.8.2, 1.7.2, 1.6.4 | default | new |
| Opera 12.10               | MacOS 10.7.5 | 1.8.2, 1.7.2, 1.6.4 | default | new |
| Safari 6.0.1 (7536.26.14) | MacOS 10.7.5 | 1.8.2, 1.7.2, 1.6.4 | default | new |
+---------------------------+--------------+---------------------+---------+-----+
| Chrome 21.0.1180.82       | iOS 4.3.5    | 1.8.2, 1.7.2, 1.6.4 | default | new |
| Opera 7.0.5               | iOS 4.3.5    | 1.8.2               | default | new |
| Safari                    | iOS 4.3.5    | 1.8.2, 1.7.2, 1.6.4 | default | new |
+---------------------------+--------------+---------------------+---------+-----+

4 commentaires

Votre compréhension des sélecteurs CSS semble sonore. Cependant, JQuery ne fondte pas toujours les sélecteurs sur le balisage source. Cela est particulièrement vrai, j'ai trouvé, pour les sélecteurs d'attributs avec des valeurs pouvant changer. Aucune idée pourquoi JQuery traiterait ces problèmes de manière incohérente, cependant.

Note latérale: Utilisation de Option: sélectionnée au lieu de Option [Sélectionné] pour le #Resulta produira la même sortie que #Resultb < / code>.

@ SP00M: Je commence à vraiment vraiment détester le grésillement beaucoup.

Il y avait un problème avec ces sélecteurs ne renvoyant pas la même valeur dans les versions JQuery plus âgées que 1.7 - voir cette Rapport de bogue < / a>

5 Réponses :

0
votes

Cela dépend de la manière dont le DOM est construit par le navigateur .. Utilisation de Option [Sélectionné] [COTE] CODE> JQUERY Recherchez un élément d'option ayant l'attribut sélectionné qui dans certains cas, il n'a pas appliqué

Vous devez utiliser P> 

SelectObj.children(':selected')

1 commentaires

.filter ('[sélectionné]') FILTRES Options ayant aussi l'attribut sélectionné ... La question est pourquoi.

1
votes

Lorsque vous écrivez l'option [Sélectionné] Il recherchera l'attribut sélectionné / propriété Au lieu de cela, vous devez utiliser l'option : sélectionné Si vous avez lisonly propriété et que vous codez option [Readonly] Il retournera s

$ ("[" [Attribut] ') éléments qui ont l'attribut spécifié, avec n'importe quelle valeur.
Pour plus d'informations: a un sélecteur d'attribut [nom]

< fort> violon xxx < / p>

0 commentaires
0
votes

Votre implémentation est fausse, il n'est pas xxx

il devrait être, xxx

voici le violon édité:

http://jsfiddle.net/ugxtx/6/

et référence :

http://api.jquerery.com/selected-selector/

0 commentaires
3
votes

Le moteur SIZZLE vérifie le sélectionné propriété d'un élément (qui contient la valeur actuelle ) plutôt que l'attribut qui contient la valeur d'origine (par défaut).

voir https://github.com/jquery/sizzle/blob /master/sizzle.js#L788

Ce que je n'ai pas encore compris, c'est pourquoi votre deuxième sélecteur invoque apparemment grésillement, mais le premier ne semble pas.

Dans tous les cas, la propriété est ce que vous devez vérifier plutôt que l'attribut, vous devez donc utiliser le : pseudo-sélecteur sélectionné et non [sélectionné]

2 commentaires

Dmethvin explique la différence dans Ce numéro : le problème de : sélectionné Parcourez le chemin JavaScript de grésillement et regardez une propriété, alors que [sélectionné] passe par le chemin QuerySelectorall et regarde les attributs. (Sauf s'il y a un autre sélecteur non-QSA dans la chaîne, tels que [sélectionné]: premier .)

@Mottie En effet, sauf que j'ai utilisé le débogueur et j'ai constaté que .filter ('[sélectionné]') n'a pas compris le code sélectionné (code> Sizzzle. Impair...

1
votes

Quelles devraient renvoyer les expressions?

[Sélectionné] code> correspond à tous les éléments présentant un attribut code> sélectionné code>, avec n'importe quelle valeur (références: w3c , jQuery ). P>

Pourquoi les résultats incompatibles? H2>

J'ai soumis un rapport de bogue à jQuery ici . Il est marqué comme un duplicata de Un autre rapport de bogue qui est maintenant fixe fort >. P>

Toutes solutions? h2>

Pour obtenir la sélection actuelle forte>: p>

Utilisez le : sélectionné code> sélecteur (Démo en direct ici ): p> xxx pré>

Notez que la 2e expression est supposée plus lente em> , selon le DOC . P>

parce que : sélectionné code> est une extension de jQuery et ne faisant pas partie de la spécification CSS, requêtes à l'aide de : sélectionné code> ne peut pas tirer parti du boost de performance fourni par le Native DOM QuerySelectorall () Code> Méthode. P> blockquote>

Pour obtenir la sélection par défaut forte>: p>

pour jQuery 1.9 + strong>, utilisez l'une des expressions comme dans la question, c'est-à-dire p> xxx pré>

pour jQuery 1.6 + strong>, utilisez la propriété défaut de la propriété code> (Démo en direct ici , références: W3Schools , Mozilla , MSDN , MSDN ): P> 

$('select').find('option').filter(function() {
    return $(this).prop('defaultSelected');
});

0 commentaires

Articles qui pourrait vous intéresser :

Select2 ne s'affiche pas correctement dans le mode bootstrap
datetimepicker ne fonctionne pas avec bootstrap 4?
L'appel Ajax n'affiche pas de réponse en cas de succès
django admin - Comment ajouter du javascript à la fin d'un fichier