Des éléments fixes positionnés à droite se cadrent sur window.innerWidth et non Window.width : page réduite
Bonjour,
Sur un site développé avec WordPress auquel s'ajouté un script important et des css et destiné à tous types de périphériques d'affichage et aux navigateurs les plus courants, je rencontre un bug bizarre auquel je n'ai pas trouvé de solution.
Le phénomène se produit de manière variable :
- Sur certains documents (répétitif)
- De manière différente suivant le navigateur dans le cas des documents défaillants (listes d'articles) :
- RAS sur PC (Chrome, Opera, Firefox, Edge)
- Sur Android mobile (Galaxy S7) : les éléments fixes sont cadrés à droite sur le cadre "innerHTML" au lieu de window.width (géré en partie avec JQUERY). Il est possible de zoomer (mais on perd la visibilité des éléments right:0;
- Firefox mobile (Galaxy S7): éléments fixes (right 0) sont dans la zone affichée (window.width mais pas à 0, il y a un facteur de zoom ?), l'image peut être déplacée et zoomée, les éléments se déplacent et changent de taille de manière très erratique : inutilisable.
Le phénomène essentiel:
Pour certaines pages (pas toutes et non testée sur mobile), des éléments (les premiers dans "body") positionnés fixes (position:fixed; right:0;) se positionnement par rapport a "window.innerWidth - ou == outerWidth au lieu de window.width en l'occurence 677 au lieu de 360 sur un Samsung S7).
La conséquence est que de manière automatique l'échelle d'affichage de tous les éléments est modifiée dans le facteur (360/677, et versus 640/1057 en hauteur).
En particulier l'ensemble de "body" apparaît sur un demi largeur d'écran.
Un scroll horizontal est possible sur les pages en cause.
Le site pour ces pages est ainsi inutilisable.
Il est possible de zoomer mais les icônes fixes placées à droite qui ouvrent des volets latéraux deviennent inaccessibles et les éléments se déplacent et changent de taille de manière totalement erratique avec Firefox.
Ma conclusion :
- des définitions de css (queries) ne sont pas prises correctement en charge (valeurs exprimées en em, vh et calc) et conduisent à un comportement erratique.
- pour les états en cause : une valeur de css ou des attributs gérés pas JQuery sont mal interprétés.
- certains scripts ne sont pas exécutés (dimensionnement d'éléments, montrer-cacher etc...)
- aucune explication sur le facteur déclenchant (les pages "standard" sont fixes et nécessitent des mises au point de css pour un cadrage correct en fonction des navigateurs et des mobiles)
Mes réflexions sur le développement net pour mobiles :
Peut-être faut-il en l'état de la technique développer une application par navigateur x périphérique existant (je n'ai que 12 applis en une)?
J'ai testé 4 mobiles, j'ai 14 queries pour les css, des cas particuliers par navigateur (test sur Chrome, Firefox, Opéra, Edge, IE11)
Faut-il aujourd'hui développer 50 à 60 versions d'un site pour avoir un site stable visible sur tout support ?
Le volume de mes css et de scripts par rapport à la version PC a été multiplié par 4, et je trouve tous les jours de cas de dysfonctionnements.
Il semblerait qu'il n'y ait toujours aucune stabilité ni un cœur de comportements stable des navigateurs.
Pourtant mon outil de développement "phpstorm" ne me signale pas de problème.
A près deux ans de travail et ce nouvel incident je désespère de pouvoir mettre le site en service.
Je n'ai aucune idée de cette dernière cause d'anomalie et je n'ai trouvé aucun remède.
Je n'ai pas de piste. HELP
Cordialement
Trebly
Bien d'accord, je ne confond rien, mais le comportement du navigateur reste "indeterminable"
Bonjour,
Je confond rien.
J'avais rédigé cette nuit un complément plus détaillé, mais un incident de frappe et tout à disparu (retour à version d'origine, sauvegarde disparue), je suis allé me coucher à 7h du mat.
Pour répondre aux questions directes :
1- Même si je comprend et modifie s'il y a lieu l'architecture générale du site, c'est WordPress (4.6.5) complété de mon theme, plugins, plugins étendus et patchs), je n'ai pas tout réécrit.
2- les minima requis :
Code:
<meta name="viewport" content="width=device-width, initial-scale=1.0">
ne figure pas (jamais vérifié), mais :
Code:
<meta name="viewport" content="width=device-width">
J'ai modifié le theme pour vérifier l'effet de "initial-scale=1.0"
L'effet est que les innerSizes ne seront pas modifiés et bien calés sur initial-scale=1.0.
Par contre le problème signalé pour les éléments fixés en right:0; demeurent avec une "erreur de calcul".
On trouve ainsi (nota : les valeurs calculées sont suivies de "=" assignées par style ":" '->' dépendance d'éléments)
#page width = 360px; ->
#main width = 360px; ->
#tabs position: fixed; right: 5px; width:38px; Valeurs calculées : right:5px; left = 634px;
Le navigateur s'évertue à positionner les éléments fixés par "right" (avec Chrome, différent avec Firefox) avec un bord droit virtuel a 634+5+38 = 677px;
A noter : Valeur précédemment affectée à innerWidth quand initial-scale !=1.0
A noter que dans le cas où initial-scale n'est pas défini du tout et que alors innerWidth devient = 677px, alors on trouve pour l'élément #tabs left = 634px;
Le initial-scale n'a qu'un seul effet, l'affichage d'origine. Le zoom a deux doigts remet les choses dans l'état identique au cas précédent, à l'exception que window.innerWidth qui traduit la valeur de Zoom courant qui en Zoom maximum prend la valeur 677px;
Le problème provient de plusieurs faits essentiels qui différencient les deux cas cités :
- innerWidth (et Height) dépendent de initial-scale qui par défaut prenait la valeur maximale dès l'initialisation (lancement de mon script js) dans les deux cas (voir note 1). Par contre les deux cas rencontrés ne sont pas équivalents parce que avec la production de pages et articles il n'y a pas de zoom possible (explication ?) et le calcul du positionnement d'éléments est correct alors que lors de la production des listes d'objets le zoom est actif (677/360 max)
- les éléments fixed-right sont positionnés par Chrome calés sur la droite du cadre "innerWidth" maximal : 677px; Je ne trouve pas d'écrit qui explique que les éléments "fixed" avec "right:<value>" sont positionnés par rapport au viewport maximal.
- Sur les PC le resize fixe le viewport et les éléments fixes suivent le bord droit de fenêtre (sauf cas de scroll), par contre il semble que sur mobile le problème soit plus délicat. C'est peut-être là le problème.
En complément :
- Je sais pas ce qui conduit Chrome à fixer le inner sur le Zoom max et quand (voir le changer après orientation-change). Ceci étant inner change avec le Zoom a deux doigts, mais pas le positionnement d'éléments fixed
- Je ne retrouve pas l'origine de la valeur de 677px qui correspond à un Zoom de 677/360 = 1.880 ou 1/x = 360/677 = 0.5317 %
- Autre constat : Les fonctions calc sur la largeur et qui utilisent "xx%" partent non de "100%" = largeur de l'élément parent (mécanisme d'héritage des dimensions exprimées en %) mais de innerWidth max.
A titre d'information lorsque je cherche à positionner mes éléments fixes en utilisant "calc" :
- Si la largeur totale innerwidth maximale = 677px;
- Si l'élément est positionné par : left: calc( 100% - 38px); les résultats seront : left = 322px (OK 360 - 38) mais right = -317px et est cadré sur la marge de droite à 677px;
Où est-il écrit que en HTML et css3 les positions fixes sont calculées par rapport au viewport
C'est donc un bug majeur pour moi évident de chrome (prouvé de fait par l'existence d'une incohérence des valeurs calculées, après pour les conséquences tout est possible). Ceci d'autant plus que pour sa part Firefox se comporte de manière différente mais encore plus erratique.
En tout état de cause la question est pour mon site : qu'est-ce-qui fait que pour l'état concerné le zoom est accepté et basé sur les valeurs que j'indique, je n'en est aucune idée.
Le problème peut-être général, mais si le zoom est bloqué (i.e. paramètre maximum-scale=1.0), alors le problème n'a peut-être plus lieu.
Quant au "queries" il y en a 13 pour screen.
Prend en charge des écrans PC de > 1900px jusqu'à 450px (présentation d'articles en une colonne)
Prend en charge divers mobiles (avec cas de résolutions différentes) testé sur Samsung Galaxy S7, Samsung I9060I, Samsung I90160I (S2), LG G4, Tablette LG V500.
Mais comme le test n'avaient pas été faits spécifiquement pour les listes d'objets, je tombe sur le problème sans comprendre complètement pour l'instant.
Donc pour la suite, je compare les deux documents, même scripts et css, mais pas exactement le même contenu pour identifier pourquoi le zoom devient actif.
( Pour information la différence apparaît dans body au troisième niveau de div ou dans le cas où innerWidth change de valeur (de 360px à 647px) on produit (WordPress) une liste de documents au lieu d'afficher le contenu d'un article.
Le but est d'identifier le mécanisme (déja avec Chrome).
Je travaille par comparaison.
Il sera peut-être possible de le contourner.
Cordialement
Trebly
_________________________________________________________________________________________________________________________
note 1 : mon script principal gère pour les changements d'orientation et les resizes un objet qui conserve et permet de comparer (état précédent-suivant) la plupart des paramètres qui caractérisent le périphérique.
L'objet est initialisé dès les premières instructions du script.
Les valeurs rapportées sont :
originOffsetY innerWidth innerHeight outerWidth outerHeight JQ :window.width() JQ :window.height()
Accueil (article simple) 320 360 560 360 560 360 560
W4pl (liste) 320 677 1054 360 560 360 560
Note 2 : Le site comprend entre autres :
- des volets latéraux avec chargement ajax,
- le réglage de taille de polices et de divers paramètres d'affichage (adaptation fine au périphérique),
- la gestion d'options utilisateur sauvegardée sur ses différents périphériques,
- la gestion de marque pages,
- historique de navigation avec le header ou le texte marqué comme grain
- gestion de documents multipages (plusieurs url pour un même "document" et de textes longs avec sommaires, bibliographies, index etc..
Problème en voie de résolution, avec beaucoup de recherche sur la gestion du VIEWPORT
Bonsoir,
Merci de vos commentaires qui enrichissent tous le sujet.
Le problème est presque totalement résolu, mais il y avait un peu de boulot, surtout pour trouver la bonne manière de faire pour plusieurs raisons :
- J'ai choisi d'essayer (et en passe de réussir) de n'avoir qu'un seul "site" pour tous les affichages et navigateurs (en note voir les raisons de mon choix). Par conséquent le <meta name="viewport" content=...> doit être modifié dynamiquement lors du chargement en fonction du navigateur hôte.
- Le viewport s'avère insuffisant, il doit être complété par le(les) css.
Infos complémentaires d'analyse
A- Cas général des pages et articles avec WordPress
Pour une raison encore indéterminée (code dans WP ? non encore identifié : trop d'instances > 100 dans le code) l'affichage d'articles ou de pages "standard" dont le meta viewport est :
<meta name="viewport" content="width=device-width">
va nous donner une page fixe largeur en 360px sur un Samsung S7Edge et à 320px pour un Samsung I9060i, c'est à dire l'équivalent de ce que donne complété pour le cas de mobiles (mais sans effet nouveau) :
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">
et tout fonctionne
B- Cas de pages ou articles constitué de listes générées par le plugin W4pl
Par contre, (problème soft non trouvé, initalisation différente, calcul depuis le css ?) quand on utilise une liste (W4 post list) alors que les paramètres de meta viewport sont bien par défaut (cas des PC) :
<meta name="viewport" content="width=device-width">
A pour effet sur mobiles de fixer l'échelle par défaut à des valeurs variables et pour un Galaxy S7Edge à 360/677 = 0,5317577548005908 laissant visibles les éléments fixes positionnés a right:0;
La configuration par défaut ne fonctionne plus et l'on est dans le cas équivalent au paramètres meta viewport "schrink-to-fit=yes".
L'échelle passant donc à 360/677 = 0.53.. le document devient illisible ou bien est non manipulable si l'on augmente manuellement l'échelle.
La solution est :
- utiliser : <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">
- Mais c'est insuffisant pour ramener les éléments fixes dans la zone visible à l'échelle 1 (changer le viewport.width sans réduire l'échelle) il faut obligatoirement compléter le style de la div globale (juste après <body> nommée "site-content") par un attribut : "overflow-x:hidden;". Fixer cet attribut rend viewport width = device-width/ initial-scale (ce qui a pour effet de ramener les éléments fixes calés sur right:0; sur cette nouvelle largeur et évidemment de bloquer le déplacement horizontal qui sinon reste possible jusqu'à la largeur 677px (pour scale=1.0 sur le Samsung S7Edge). "user-scalable=no" bloquant le changement d'échelle à deux doigts mais pas le déplacement dans le cadre.
L'effet des paramètres et synthèse de la solution
Si l'on fixe initial-scale=1 alors
- l'échelle est correcte (compte tenu des dimension précisées en css)
- les éléments fixes en right:0; restés positionnés par rapport au viewport sont donc en dehors des device-sizes, ils sont visibles avec un déplacement horizontal.
- L'utilisateur peut changer l'échelle à deux doigts (pour vérifier l'échelle courante il suffit en mode debug d'afficher en console window.innerWidth/<677>
Si l'on fixe maximum-scale=1
- L'utilisateur ne pourra pas augmenter l'échelle plus qu'à l'origine, mais pourra la réduire jusqu'à 360/677
- L'utilisateur pourra déplacer horizontalement l'affichage
Si l'on ajoute user-scalable=no
- L'utilisateur ne pourra plus changer d'échelle
- L'utilisateur devra déplacer l'affichage vers le gauche pour voir les éléments fixed right:0; qui sont toujours calés sur 677px;
Pour ramener les éléments "fixed" dans la zone visible et en fait ajuster la largeur de viewport de "site-content" à la valeur the_width=device-width/initial_scale il va falloir en sus (ça marche mais cela ne veut pas dire que c'est la seule solution) utiliser le style : overflow-x : hidden;
Dès lors notre écran se comportera
- en largeur fixe = the_width=device-width/initial_scale (position du right:0;)
- il n'y aura plus d'accès à des objets comportant de valeurs (devenues) négatives de right (cas cité précédemment dans le sujet, pour des objets donc placés à droite de la limite)
- il n'y aura plus de zoom modifiable par l'utilisateur
A noter, très important : à l'exception de initial-scale, les modification de "meta name="viewport" content= ..." doivent comporter tous les paramètres utiles, sinon le résultat est aléatoire (Un paramètre non précisé peut voir sa valeur antérieure recalculée de manière non maitrisable).
Enfin la question est comment modifier en js le contenu de "meta viewport" de façon à ce que la modification soit prise en compte instantanément (recalcul comme une modification importante de style, en général toute la mise en page est recalculée) :
- On crée (pour pouvoir la réutiliser) un Element (ici nommé "viewport" en utilisant "querySelector" avec le sélecteur "meta[name=viewport]"
- On utilise setAttribute pour modifer "content".
Exemple
Code:
1
2
3
| var viewport = document.querySelector("meta[name=viewport]");
// ...
viewport.setAttribute('content', 'width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no'); |
Mais les paramètres de cet exemple (comme indiqué plus haut) ne suffiront peut-être pas pour fixer la largeur du viewport à the_width=device-width/initial_scale, il faut aussi que la div générale possède l'attribut de style "overflow-x: hidden;". Cet élément de style devra être modifié ou rétabli après la modification du meta viewport pour forcer le recalcul si par exemple user-scalable à du être modifié (pour permettre un zoom sur une image par exemple).
A noter que la requête équivalente JQuery n'a pas fonctionné correctement, je ne sais pas pourquoi (pas le temps d'analyser).
A noter aussi que si le meta tag viewport n'existe pas il faudra l'ajouter dans le head à l'aide d'une commande append.
J'ai testé les effets des modifications de content de viewport, en mode Console, en faisant varier tous les paramètres.
Les paramètres valides sur Chrome 57 (testé uniquement pour l'instant) sont :
- width
- height
- initial-scale
- minimum-scale
- maximum-scale
- user-scalable
- schrink-to-fit
Voilà donc le résultat de mes investigations
Cordialement
Trebly
