IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Commentaires

  1. Avatar de Kenjill20
    • |
    • permalink
    merci +1
  2. Avatar de psychadelic
    • |
    • permalink
    Ca fonctionne parfaitement avec Vivaldi !

    trop cool, plus ça va, et plus je kiff ce navigateur !

    https://vivaldi.com
  3. Avatar de a028762
    • |
    • permalink
    Ah, pas implémenté sur IE (IE11 ?). Décidément, MS ne croit toujours pas au WEB, toujours à la traîne.
    La démo ne fonctionne pas sur Firefox 40.0.3. ?
    Merci à l'auteur pour le billet
  4. Avatar de guiloj
    • |
    • permalink
    Bonjour, fonctionnalité très intéressante, mais encore trop rudimentaire et moins visible que le fameux "alert".

    Un point très embarrassant avec une configuration à deux écran et le navigateur sur l'écran secondaire la notification apparait dans l'écran principal toujours en bas a droite donc a l'opposée du curseur et de la vision de l'utilisateur.

    Prometteur.

    Merci pour le billet et l’information.
  5. Avatar de Invité
    • |
    • permalink
    [QUOTE=McFlyMarty;bt955]Ce sont des footeux en même temps, sil il fallait se mettre a leur niveau, on serait bien bas....:lol:[/QUOTE]

    Oui, c'est déjà étonnant qu'ils sachent compter jusqu'à 42 :lol:
  6. Avatar de ChipsAlaMenthe
    • |
    • permalink
    Ce sont des footeux en même temps, sil il fallait se mettre a leur niveau, on serait bien bas....
    Bien trouvé! Ca m'a bien fait rire ^^
  7. Avatar de Paul_Le_Heros
    • |
    • permalink
    Bonjour,
    Merci Bovino, pour avoir fait avancer le schmilblick...
    Je me sens moins seul quand je lis "SylvainPV" :
    une meilleure façon de faire que ces event.preventDefault() && event.stopImmediatePropagation() par ci par là
    Il n'a pas l'air d'être satisfait de lui : « par ci par là »...
    J'ai bien de la peine avec les événements et leurs handlers. J'ai beau (mal) chercher, je ne trouve rien sur le net pour clarifier définitivement cette situation. J'aime bien JQuery, alors si vous connaissez un tuto sur "le traitement des événements avec JQuery", dites moi ! Poyr vous donner une idée de l'aviron que j'ai pratiqué : il n'y a pas si longtemps que je m'usais à utiliser return !0; ou return !1; en sortie de handler pour signifier la fin ou non du traitement de l'événement, comme indiqué dans ma doc JS de Mathusalem (-: l'originale, peut-être !)
    Bon courage à tous,
    Paul
  8. Avatar de McFlyMarty
    • |
    • permalink
    Ce sont des footeux en même temps, sil il fallait se mettre a leur niveau, on serait bien bas....
  9. Avatar de jojolebg
    • |
    • permalink
    J'imagine aussi que les Listeners d'évènements associés aux champs du formulaire seront perdus avec la technique du innerHtml
  10. Avatar de danielhagnoul
    • |
    • permalink
    Je viens de voir : document.scripts (collection) : représente toutes les images du document (balises HTML <script>).
  11. Avatar de kolodz
    • |
    • permalink
    Super billet !
    J'avoue que l'a démo claque

    Il y a une raison pour que les notifications Chrome soient "plus moche" que les notifications Firefox ?
  12. Avatar de Bovino
    • |
    • permalink
    Salut Sylvain.

    Je ne connais pas du tout React, mais je sais qu'affecter tous les événements sur le body a été la première approche utilisée par jQuery avec la méthode .live(). Ils ont changé d'optique en considérant que le fait de ne pas pouvoir stopper la propagation de l'événement pouvait être problématique. J'aurais tendance à me ranger à cet avis en considérant aussi que devoir gérer tous les événements d'un même type sur la page est souvent un peu surdimensionné comparé au besoin réel la plupart du temps.
    Par exemple, si on doit gérer le clic sur un texte qui apparaitra au retour d'une requête AJAX ne nécessite pas pour autant que l'on gère tous les clics de toute la page constamment.
    Donc à mon sens, l'idéal est de placer le gestionnaire sur le plus proche parent connu de l'élément visé.
  13. Avatar de SylvainPV
    • |
    • permalink
    Merci Bovino, c'est vrai que c'est un sujet courant et qu'on avait rien comme ressources dessus.

    J'en profite pour te demander ton avis sur un micro-débat: penses-tu que cela ait un sens d'utiliser exclusivement de la délégation d'évènements sur l'élément de plus haut niveau (document.body) pour gérer tous les évènements d'une application ? Certains ont émis ce genre d'idées, notamment en parallèle avec l'utilisation de React et de l'architecture Flux, pour remplacer l'usage classique de la phase de propagation des évènements qu'ils trouvent confusante par leur propre système dispatcher (qui peut se résumer en gros à un pub/sub sur les composants React). Je suis pas un fada de React ni du fait de réinventer la roue, mais je dois avouer m'être demandé plusieurs s'il n'y avait pas une meilleure façon de faire que ces event.preventDefault() && event.stopImmediatePropagation() par ci par là.
    Mis à jour 31/05/2015 à 16h53 par SylvainPV
  14. Avatar de Bovino
    • |
    • permalink
    Arf... désolé.

    Avec un exemple, ce sera probablement plus compréhensible.

    Imaginons le code HTML
    Code html : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    <div id="A">
        <div class="B">
            <span>Cliquer sur le premier B</span>
        </div>
        <div class="B">
            <span>Cliquer sur le second B</span>
        </div>
    </div>
    Imaginons que tu veuilles traiter les clics sur les éléments ayant la classe B, tu poses donc le gestionnaire sur la div A.
    Sauf que lorsque tu cliques sur le texte, c'est la balise <span> qui va déclencher l'événement et ce sera donc elle qui sera référencée par event.target.
    Donc si tu fais le test if(initElem.className != 'B'){ ... }, il sera vrai. Il est donc nécessaire de vérifier si l'un des ancêtres de event.target possède cette classe.
  15. Avatar de exe2bin
    • |
    • permalink
    Il est important, quand on utilise la délégation d'événement, de faire attention que si l'élément ciblé possède des éléments enfants, alors Event.target peut ne pas correspondre à celui ciblé, il faudra dans ce cas remonter l'arborescence jusqu'à l'élément sur lequel le gestionnaire est posé en testant à chaque palier si l'élément en cours est celui recherché.
    Bel article mais je n'ai pas tout compris (voir ci-dessus);
    pourrais tu reformulé
  16. Avatar de tlt
    • |
    • permalink
    plutôt bon comme aide mémoire, surtout pour les gens comme moi qui ne sont dans le web qu’occasionnellement
  17. Avatar de Z4ng3tsu
    • |
    • permalink
    Merci beaucoup pour ce billet ! Fonctionnalité qui sera sûrement utilisée plus d'une fois. Moins de prise de tête pour du css/javascript maintenant !
  18. Avatar de Bovino
    • |
    • permalink
    D'ailleurs, il y a une erreur dans ton commentaire résultat !
    Les affres du copier/coller.
    Je ne corrige pas, ça me servira de leçon.
  19. Avatar de kolodz
    • |
    • permalink
    En effet, c'est pour briller en soirée !

    Car, dans tout les cas, il est aussi possible de faire :
    Code javascript : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    var MON_PRIX =12;
    console.log(MON_PRIX.toFixed(2)); //12.00
    Ce qui est un poile plus déclaratif, mais ce n'est pas plus mal pour savoir ce qu'on manipule !

    D'ailleurs, il y a une erreur dans ton commentaire résultat !
    console.log(12..toFixed(2)); // 12.00
    Note : Je n'étais pas au fait de la notation [] pour les méthodes !

    Cordialement,
    Patrick Kolodziejczyk.
  20. Avatar de kolodz
    • |
    • permalink
    Merci pour le billet, c'est une fonctionnalité HTML5 très intéressante !
Page 1 sur 2 12 DernièreDernière