Pour une question différente, j'ai composé cette réponse , y compris cet exemple de code .
Dans ce code, j'utilise la molette de la souris pour effectuer un zoom avant / arrière sur un canevas HTML5. J'ai trouvé du code qui normalise les différences de vitesse entre Chrome et Firefox. Cependant, la gestion du zoom dans Safari est beaucoup, beaucoup plus rapide que dans l'un ou l'autre.
Voici le code que j'ai actuellement:
var handleScroll = function(e){
var delta = e.wheelDelta ? e.wheelDelta/40 : e.detail ? -e.detail/3 : 0;
if (delta) ...
return e.preventDefault() && false;
};
canvas.addEventListener('DOMMouseScroll',handleScroll,false); // For Firefox
canvas.addEventListener('mousewheel',handleScroll,false); // Everyone else
Quel code puis-je utiliser pour obtenir la même valeur «delta» pour la même quantité de molette de la souris sur Chrome v10 / 11, Firefox v4, Safari v5, Opera v11 et IE9?
Cette question est liée, mais n'a pas de bonne réponse.
Edit : Une enquête plus approfondie montre qu'un événement de défilement 'up' est:
| evt.wheelDelta | evt.detail ------------------ + ---------------- + ------------ Safari v5 / Win7 | 120 | 0 Safari v5 / OS X | 120 | 0 Safari v7 / OS X | 12 | 0 Chrome v11 / Win7 | 120 | 0 Chrome v37 / Win7 | 120 | 0 Chrome v11 / OS X | 3 (!) | 0 (peut-être faux) Chrome v37 / OS X | 120 | 0 IE9 / Win7 | 120 | indéfini Opera v11 / OS X | 40 | -1 Opera v24 / OS X | 120 | 0 Opera v11 / Win7 | 120 | -3 Firefox v4 / Win7 | undefined | -3 Firefox v4 / OS X | undefined | -1 Firefox v30 / OS X | undefined | -1
De plus, l'utilisation du trackpad MacBook sous OS X donne des résultats différents même en se déplaçant lentement:
- Sur Safari et Chrome, la
wheelDelta
valeur est de 3 au lieu de 120 pour la molette de la souris. - Sur Firefox,
detail
c'est généralement2
, parfois1
, mais lorsque vous faites défiler très lentement AUCUN ÉVÉNEMENT HANDLER INCENDIE .
La question est donc:
Quelle est la meilleure façon de différencier ce comportement (idéalement sans aucun agent utilisateur ni reniflage du système d'exploitation)?
la source
e.wheelDelta/120
?Réponses:
Edit septembre 2014
Étant donné que:
… Je ne peux que recommander d'utiliser ce code de comptage simple basé sur les signes:
La tentative originale d'être correcte suit.
Voici ma première tentative de script pour normaliser les valeurs. Il a deux défauts sur OS X: Firefox sur OS X produira des valeurs 1/3 ce qu'elles devraient être, et Chrome sur OS X produira des valeurs 1/40 ce qu'elles devraient être.
Vous pouvez tester ce code sur votre propre navigateur ici: http://phrogz.net/JS/wheeldelta.html
Les suggestions pour détecter et améliorer le comportement sur Firefox et Chrome sous OS X sont les bienvenues.
Edit : Une suggestion de @Tom est de simplement compter chaque appel d'événement comme un seul mouvement, en utilisant le signe de la distance pour l'ajuster. Cela ne donnera pas d'excellents résultats sous un défilement fluide / accéléré sous OS X, ni ne gérera parfaitement les cas où la molette de la souris est déplacée très rapidement (par exemple,
wheelDelta
240), mais cela se produit rarement. Ce code est maintenant la technique recommandée indiquée en haut de cette réponse, pour les raisons qui y sont décrites.la source
(((evt.deltaY <0 || evt.wheelDelta>0) || evt.deltaY < 0) ? 1 : -1)
ne sais pas ce que QA découvre avec cela, cependant.Voici ma folle tentative de produire un delta cohérent et normalisé entre navigateurs (-1 <= delta <= 1):
Ceci est totalement empirique mais fonctionne assez bien sur Safari 6, FF 16, Opera 12 (OS X) et IE 7 sur XP
la source
event
-object eno
?o
variable est là pour montrer que nous voulons l'événement d'origine et non un événement encapsulé comme jQuery ou d'autres bibliothèques peut passer aux gestionnaires d'événements.Nos amis de Facebook ont mis au point une excellente solution à ce problème.
J'ai testé sur une table de données que je construis en utilisant React et ça défile comme du beurre!
Cette solution fonctionne sur une variété de navigateurs, sur Windows / Mac, et les deux utilisant le trackpad / souris.
Le code source peut être trouvé ici: https://github.com/facebook/fixed-data-table/blob/master/src/vendor_upstream/dom/normalizeWheel.js
la source
J'ai fait un tableau avec différentes valeurs renvoyées par différents événements / navigateurs, en tenant compte de l'
wheel
événement DOM3 que certains navigateurs prennent déjà en charge (tableau ci-dessous).Sur cette base, j'ai créé cette fonction pour normaliser la vitesse:
http://jsfiddle.net/mfe8J/1/
Table pour
mousewheel
,wheel
et lesDOMMouseScroll
événements:la source
Une autre solution plus ou moins autonome ...
Cela ne prend cependant pas de temps entre les événements. Certains navigateurs semblent toujours déclencher les événements avec le même delta, et les déclencher plus rapidement lors du défilement rapide. D'autres font varier les deltas. On peut imaginer un normaliseur adaptatif qui prend en compte le temps, mais qui serait quelque peu compliqué et difficile à utiliser.
Travail disponible ici: jsbin / iqafek / 2
la source
Solution simple et fonctionnelle:
la source
Pour la prise en charge du zoom sur les appareils tactiles, inscrivez-vous aux événements gesturestart, gesturechange et gestureend et utilisez la propriété event.scale. Vous pouvez voir un exemple de code pour cela.
Pour Firefox 17, l'
onwheel
événement devrait être pris en charge par les versions de bureau et mobiles (selon les documents MDN sur onwheel ). Aussi pour Firefox, peut-être que l'MozMousePixelScroll
événement spécifique à Gecko est utile (bien qu'il soit vraisemblablement obsolète puisque l'événement DOMMouseWheel est maintenant obsolète dans Firefox).Pour Windows, le pilote lui-même semble générer les événements WM_MOUSEWHEEL, WM_MOUSEHWHEEL (et peut-être l'événement WM_GESTURE pour le panoramique du pavé tactile?). Cela expliquerait pourquoi Windows ou le navigateur ne semble pas normaliser les valeurs d'événement de la molette de la souris lui-même (et pourrait signifier que vous ne pouvez pas écrire de code fiable pour normaliser les valeurs).
Pour la prise en charge des événements
onwheel
(et non sur la molette) dans Internet Explorer pour IE9 et IE10, vous pouvez également utiliser l' événement standard W3Conwheel
. Cependant, une encoche peut avoir une valeur différente de 120 (par exemple, une seule encoche devient 111 (au lieu de -120) sur ma souris en utilisant cette page de test ). J'ai écrit un autre article avec d'autres détails sur les événements de roue qui pourraient être pertinents.Fondamentalement, dans mes propres tests pour les événements de roue (j'essaie de normaliser les valeurs de défilement), j'ai constaté que j'obtenais des valeurs variables pour le système d'exploitation, le fournisseur du navigateur, la version du navigateur, le type d'événement et le périphérique (souris à molette Microsoft, gestes du pavé tactile d'ordinateur portable , pavé tactile d'ordinateur portable avec zone de défilement, souris magique Apple, boule de défilement puissante Apple, pavé tactile Mac, etc.).
Et devez ignorer une variété d'effets secondaires de la configuration du navigateur (par exemple, Firefox mousewheel.enable_pixel_scrolling, chrome --scroll-pixels = 150), les paramètres du pilote (par exemple le pavé tactile Synaptics) et la configuration du système d'exploitation (paramètres de la souris Windows, préférences de la souris OSX, Paramètres du bouton X.org).
la source
C'est un problème avec lequel je me bats depuis quelques heures aujourd'hui, et pas pour la première fois :(
J'ai essayé de résumer les valeurs sur un "balayage" et de voir comment les différents navigateurs rapportent les valeurs, et elles varient beaucoup, avec Safari rapportant des nombres plus importants sur presque toutes les plates-formes, Chrome rapportant beaucoup plus (comme 3 fois plus ) que Firefox, Firefox étant équilibré sur le long terme mais assez différent entre les plates-formes sur les petits mouvements (sur Ubuntu gnome, presque seulement +3 ou -3, il semble qu'il résume des événements plus petits et envoie ensuite un gros "+3")
Les solutions actuelles trouvées en ce moment sont trois:
L'idée de Qooxdoo est bonne et fonctionne, et c'est la seule solution que j'ai actuellement trouvée pour être complètement cohérente avec un navigateur croisé.
Malheureusement, il a également tendance à renormaliser l'accélération. Si vous l'essayez (dans leurs démos) et que vous faites défiler de haut en bas à vitesse maximale pendant un moment, vous remarquerez que le défilement extrêmement rapide ou extrêmement lent produit pratiquement la même quantité de mouvement. Au contraire, si vous rechargez la page et ne la glissez que très lentement, vous remarquerez qu'elle défilera assez rapidement ".
C'est frustrant pour un utilisateur Mac (comme moi) qui avait l'habitude de faire des glissements de défilement vigoureux sur le pavé tactile et de s'attendre à atteindre le haut ou le bas de l'objet défilé.
De plus, comme il réduit la vitesse de la souris en fonction de la valeur maximale obtenue, plus votre utilisateur essaie de l'accélérer, plus il ralentira, tandis qu'un utilisateur à «défilement lent» connaîtra des vitesses assez rapides.
Cela fait de cette solution (autrement brillante) une implémentation légèrement meilleure de la solution 1.
J'ai porté la solution sur le plugin jquery mousewheel: http://jsfiddle.net/SimoneGianni/pXzVv/
Si vous jouez avec pendant un certain temps, vous verrez que vous commencerez à obtenir des résultats assez homogènes, mais vous remarquerez également qu'il tend à + 1 / -1 valeurs assez rapidement.
Je travaille maintenant à l'améliorer pour mieux détecter les pics, afin qu'ils n'envoient pas tout "hors échelle". Il serait également intéressant d'obtenir également une valeur flottante entre 0 et 1 comme valeur delta, afin qu'il y ait une sortie cohérente.
la source
Il n'y a certainement pas de moyen simple de normaliser tous les utilisateurs de tous les systèmes d'exploitation dans tous les navigateurs.
Cela devient pire que vos variantes listées - sur ma configuration WindowsXP + Firefox3.6, ma molette de souris fait 6 par défilement d'un cran - probablement parce que quelque part j'ai oublié que j'ai accéléré la molette de la souris, soit dans le système d'exploitation ou quelque part dans environ: config
Cependant, je travaille sur un problème similaire (avec une application similaire btw, mais non-canvas) et cela me vient à l'esprit en utilisant simplement le signe delta de +1 / -1 et en mesurant au fil du temps la dernière fois qu'elle a été déclenchée, vous avoir un taux d'accélération, ce est à dire. si quelqu'un fait défiler une fois contre plusieurs fois en quelques instants (ce que je parierais, c'est comment google maps le fait).
Le concept semble bien fonctionner dans mes tests, ajoutez simplement quelque chose de moins de 100 ms à l'accélération.
la source
la source