100vw != 100% ?

Les dimensions en vw

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour tlm !

Juste par curiosité, j'ai voulu mettre une largeur en vw à une div, et me suis rendu compte que 33.33vw > 33.33%.

En effet, 33.33vw prenait une largeur de quelques pixels de plus que 33.33%. Donc, je n'ai pas réussi à aligner 3 div avec la valeur en vw.

J'ai testé tout ça seulement sur Firefox (v.30).

Quelqu'un est déjà tombé sur ça ?

Édité par Coyote

+0 -0

Salut !

Je pense que la méthode d'arrondi (voire même de calcul) n'est pas la même si tu spécifies des % ou des vw, d'où la différence. Peut-être parce que Firefox ne comprend pas ou pas correctement l'unité vw ?

Édité par Ymox

Evitez qu'on vous dise de les lire : FAQ PHP et Symfony 2Tutoriel WAMP • Cliquez 👍 pour dire merci • Marquez vos sujets résolus

+0 -0
Staff

Peut-être tout simplement parce Firefox arrondit au pixel près l'unité vw, ce qui peut donner des résultats différents une fois multiplié.

Par exemple, si tu as l = 960px, alors 1% = 9.6px, soit 1vw = 10px avec l'arrondi.
Et en multipliant ça donné d'un côté 33.3% = 319,68px (en gros 320px) et de l'autre 33.3vw = 333px.

Et voilà, la magie des arrondis ! :D

Staff

Tout dépend des valeurs et de la précision de l'arrondi. ;)

J'ai utilisé l'entier le proche pour l'exemple, mais il est aussi possible que les calculs intermédiaires soient fait avec des flottants (il faut voir avec quelle précision).

@Ymox : Du peu que j'ai utilisé ces unité, Firefox a l'air de plutôt bien s'en sortir, à l'inverse d'IE et des vieux Android…

Édité par viki53

Je donnais une simple piste, moi, avant ce message sujet, je ne connaissais pas cette unité.

Et note que je n'étais pas tombé loin, d'ailleurs  ;)

Édité par Ymox

Evitez qu'on vous dise de les lire : FAQ PHP et Symfony 2Tutoriel WAMP • Cliquez 👍 pour dire merci • Marquez vos sujets résolus

+0 -0
Auteur du sujet

Il me semble que les vw sont adaptés pour les tailles de police, et non pour les blocs, mais comme 1 vw est censé être = 1% width, alors …

Et pour info, ça peut aider pour spécifier des hauteurs, si on veut une div carrée on lui mettra un width et un height de 33.33vw par exemple …

Édité par anonyme

+0 -0
Staff

Adapté est un bien grand mot.

Si tu utilises 1vw tu risque d'avoir un texte trop petit sur mobile (sûrement même, j'ai testé). Si à l'inverse tu utilises 20vw, tu auras un monstre sur desktop.

Donc il vaut mieux partir sur des em en général, sauf cas particuliers (comme un splashcreen d'accueil, par exemple)…

Je me suis déjà penché deux ou trois fois sur la question, pour essayer de suivre l'évolution, et j'en arrive à la même conclusion que viki : Les em sont toujours les plus adaptés pour l'instant. À vrai dire, je ne vois pas vraiment où ils essaie d'aller avec ces nouvelles unités ; j'ai l'impression qu'ils ont proposé des trucs et qu'ils se cassent le fion pour y trouver une utilité maintenant, au lieu de partir sur le constat d'un besoin et d'y apporter des solutions.

Pour exemple, ce qui aurait été vachement pratique (parce que ça correspond à un besoin existant), c'est de pouvoir définir un texte qui se réduit en taille (sans créer de saut de ligne, avec un word-wrap par exemple) pour remplir la largeur de son parent OU pour ne pas dépasser le parent si celui-ci se réduit (façon max-height).

Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !

+0 -0
Auteur du sujet

Pour exemple, ce qui aurait été vachement pratique (parce que ça correspond à un besoin existant), c'est de pouvoir définir un texte qui se réduit en taille (sans créer de saut de ligne, avec un word-wrap par exemple) pour remplir la largeur de son parent OU pour ne pas dépasser le parent si celui-ci se réduit (façon max-height).

Manumanu

Tu peux utiliser les overflow avec hidden ou scroll au pire. Mais un texte qui s'adapte à son parent, en effet ça serait super bien.

PS : un mec qui suit l'évolution des css mais qui a mit pour avatar le logo IE ?

Édité par anonyme

+0 -1
Staff

@Solid : Les dernières versions d'IE sont loin d'être aussi mauvaises que les précédentes.

@Manumanu : C'est vrai que cette unité est pas toujours utile, mais ça peut être pratique pour une homepage façon splashscreen. Après toutes les propriétés CSS ne sont pas utiles en permanence, certaines sont faites pour des cas précis…

@Solid : Les dernières versions d'IE sont loin d'être aussi mauvaises que les précédentes.

viki53

Je dirais même plus : Les précédentes versions d'IE n'ont pas été mauvaises, juste trop en retard au niveau de l'implémentation des specs. Et ça ne concerne pas IE6, qui avait le meilleur support du marché à sa sortie ; son problème à lui, c'est le même que Windows XP : être resté trop longtemps sans successeur.

@Solid: Attention quand tu me lances sur des sujets (trolls ?) pareils, ça me passionne très vite et après pour m'arrêter, c'est mal barré. ;)

@Manumanu : C'est vrai que cette unité est pas toujours utile, mais ça peut être pratique pour une homepage façon splashscreen. Après toutes les propriétés CSS ne sont pas utiles en permanence, certaines sont faites pour des cas précis…

viki53

Ah bien entendu hein ; mais quand on gère un truc pareil, ça me semble logique de mettre la priorité sur les trucs essentiels ^^

Édité par Manumanu

Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !

+0 -0
Auteur du sujet

Haha pas de soucis pour le troll Manumanu, tu peux y aller.

C'est juste que je suis en train de faire un site, avec plusieurs propriétés css3, et la plupart ne sont supportées que par IE10, mais pas avant.

Le problème c'est peut-être que les gens ne mettent pas assez souvent leurs navigateurs à jour, après au temps de IE6 je sais pas, mais en ce moment tu concèderas le fait qu'IE casse les pieds à bcp de webmasters, à cause de son non-suppoort des propriétés récentes

+0 -0

Oui et non ; en soi, c'est pas IE qui casse les pieds, c'est effectivement le fait que les utilisateurs et les clients ne soient pas à jour. Le reproche que je fais à Microsoft, c'est de ne pas forcer ces mises à jour au maximum (mais même comme ça, le nombre de gens qui désactivent les maj de leur PC sont légions). Et si ça embête beaucoup de webmaster, c'est souvent une question de compétences, de connaissance, et de conception. Ce sont des choses qui ne s'improvisent pas : Quand on doit coder pour un vieux navigateur (que ce soit IE ou Firefox, d'ailleurs. Je suis déjà tombé sur des clients qui étaient encore en Firefox 2), on ne s'occupe pas d'abord du récent pour chercher ensuite comment faire pour rendre le neuf compatible avec du vieux : Ça ne marchera juste jamais.

Mon analogie préférée pour ça : Quand le client a un lecteur VHS, on ne lui livre pas un Blu-ray. On peut remettre en cause le fait qu'il utilise encore un lecteur VHS, on peut en discuter avec, tenter de le convaincre du besoin de se mettre à jour, mais le seul à blâmer le jour de la livraison si ce n'est pas compatible, c'est celui qui a gravé son Blu-ray et qui tente désespérément de le faire lire à un lecteur VHS devant le client.

Pour un même résultat, on ne code pas de la même façon en fonction de son besoin. Si on doit coder pour IE9 mini, IE8 mini ou IE7 mini, on le prévoit à l'avance, et ainsi on évite tout problème.

Pas de prise en charge de border-radius, text-shadow et box-shadow, c'est franchement pas grave ; si ça l'est et que ça empêche la lecture ou la navigation, c'est qu'il faut impérativement revoir le design, en dehors de toute question de navigateur et de CSS. Pour tout ce qui est mise en boite, float marche depuis longtemps. Pour inline-block, y a un palliatif simple sous IE7 (zoom), et ça marche sous IE8. Pour tout une majorité des autres bugs, c'est souvent juste une question de connaissance et de compréhension ; hasLayout, je l'ai expliqué je ne sais pas combien de fois, même à des professionnels.

Le seul soucis que je rencontre en général, c'est le support de :after/:before quand je dois rendre un site compatible IE7 (ça marche dès IE8). Et encore, c'est un problème de conception : Quand je sais que je dois rendre un site compatible IE7, je n'utilise pas de pseudo-élément et je les ajoute directement au markup. Si je dois reprendre un site sensé être compatible IE7 qui a ce genre de problème, je dis juste au client de me laisser faire la prochaine fois, parce que si son intégrateur mets des before/after en sachant qu'il doit être compatible IE7, c'est qu'il n'est pas au point, tout simplement. Je n'ai jamais rencontré de problème insurmontable à ce niveau.

Tout ça, en sachant que je milite toujours pour que les gens mettent leur navigateur à jour (parce qu'ils n'ont vraiment aucune excuse pour ne pas le faire) et que pour les clients, je passe toujours du temps à leur expliquer l'importance d'être à la page. Malgré ça malheureusement, y a toujours des cas où on ne peut rien faire. Et là, c'est à nous de bosser en conséquence et dans le bon ordre.

Là où ça m'énerve, par contre, c'est quand la dernière version de Firefox ne gère toujours pas le positionnement dans une cellule de tableau, alors que ça fait plus de 10 ans que ce bug est signalé ; un ami a le même soucis avec line-height dans les input. C'est aussi quand la dernière version de Chrome prétend toujours gérer les nouvelles valeurs de background-position pour gagner des points dans les testeurs en ligne (html5test.com), alors que ce n'est toujours pas le cas en réalité. Là oui, les mauvaises gestion de propriétés dans des navigateurs modernes (IE compris), ça me pose problème.

Édité par Manumanu

Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !

+3 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte