Trolloscope Who is the best ? - Page 13

Ouai la lisibilité sur mobiles/pda c'est pas vraiment une question de standards. Faire des sites taillé en px etc c'est standart, ça donne un résultat très génant mais y'a bien pire (genre les éléments qui se rétrécissent à une largeur ~nulle ou qui se remetent dans un ordre vraiment bizare, .. )

Yann B (./360) :

Webkit respecte au contraire davantage les standards que Gecko Seulement, ce n'est pas parce que tu respectes bien les standards que ton site sera adapté à une interface machine complètement différente (tu ne vas pas concevoir ton site de la même façon s'il doit être lu sur un écran en 1920x1200 avec clavier/souris ou sur un écran en 120x80 avec une interface tactile...)

J'ai jamais dit le contraire ;-) La faute n'était pas au navigateur, mais au site : les standards prévoient tout à fait de quoi faire tourner un site aussi bien sur un ordinateur de bureau que sur un portable par les CSS : dans l'en-tête, on peut lier différentes CSS en fonction du média ; une CSS bien lourdingue pour les ordinateurs de bureau, et une CSS allégée pour la version mobile. Après, le principal problème vient à mon avis du passage du mode portrait au mode paysage : ce dernier mode est plutôt désagréable pour lire de long textes et les sites doivent donc eux-mêmes redimensionner leurs blocs pour que ce dernier s'affiche sur 50/60% de la largeur totale de l'écran, alors que sur un mobile on est déjà sur le bon format.

Mais il n'y a pas que ça ! Tout n'est pas question de CSS, sur un mobile tu ne peux tout simplement pas présenter la même quantité d'informations que sur un écran, et l'interface (tactile dans le cas de l'iPhone, clavier souris pour un ordi) n'est pas la même. Typiquement, je ne trouve pas que la liste des connectés soit vraiment intéressante à mettre sur une version mobile de yAronet, etc..

display:none c'est bien du CSS

voui, enfin pour le coup ça serait bien de pouvoir alléger la page destinée à un usage sur mobile, et pas seulement visuellement (ne serait-ce que pour accélérer les transferts et économiser de la bp, vu qu'envoyer un élément qui a un display:none c'est d'un intérêt discutable dans le cas que tu suggères).

[edit] css -> page

oui, mais si tu veux présenter vraiment différemment et sans charger la page (genre une page longue que tu vas splitter en plusieurs pages sur la version mobile), tu vas finir par avoir le site en double, mais sur la même page
et vive la lourdeur pour le coup

Zephyr (./364) :
voui, enfin pour le coup ça serait bien de pouvoir alléger la CSS destinée à un usage sur mobile, et pas seulement visuellement (ne serait-ce que pour accélérer les transferts et économiser de la bp, vu qu'envoyer un élément qui a un display:none c'est d'un intérêt discutable dans le cas que tu suggères).

la liste des connectés ça prend pas énormément de bp, bien sûr qu'on peut vouloir optimiser à fond mais en première approximation se contenter d'améliorer la CSS c'est déjà 80% de ce qu'on veut...

en première approximation ouep, mais perso si je voulais voir yN sur un mobile, il y a largement plus que 90% du contenu de la page que je voudrais pouvoir éviter (à vue de nez je dirais au moins 50%, un rapide coup d'oeil à la source de la page que tu es en train de lire devrait pouvoir t'en convaincre ^^)

Pollux (./366) :

Zephyr (./364) :
voui, enfin pour le coup ça serait bien de pouvoir alléger la CSS destinée à un usage sur mobile, et pas seulement visuellement (ne serait-ce que pour accélérer les transferts et économiser de la bp, vu qu'envoyer un élément qui a un display:none c'est d'un intérêt discutable dans le cas que tu suggères).

la liste des connectés ça prend pas énormément de bp, bien sûr qu'on peut vouloir optimiser à fond mais en première approximation se contenter d'améliorer la CSS c'est déjà 80% de ce qu'on veut...

C'était juste sur un exemple, hein Et je ne suis pas sûr du tout que la CSS permette vraiment de faire ce qu'il faut (mais ça va dépendre d'un site à l'autre, c'est sûr)

Zephyr (./367) :
en première approximation ouep, mais perso si je voulais voir yN sur un mobile, il y a largement plus que 90% du contenu de la page que je voudrais pouvoir éviter (à vue de nez je dirais au moins 50%, un rapide coup d'oeil à la source de la page que tu es en train de lire devrait pouvoir t'en convaincre ^^)

- si l'optimisation était aussi cruciale que tu le dis on pourrait aussi pas mal optimiser la version "normale", or c'est déjà pas vraiment une priorité
- les trucs dont tu parles sont en gros en deux catégories :
[ul][li]le contenu qui n'est pas essentiel mais qui reste important si l'écran est pas trop petit (signatures, infos sur le bord des posts) : en fait je pense pas que ça prenne trop de place une fois compressé en gzip parce que c'est très répétitif, donc c'est pas grave de le laisser
[li]les features supplémentaires qui ne sont pas du contenu (trucs pour insérer les balises dans le formulaire, "mes raccourcis", etc) : si l'optimisation était importante on pourrait s'en débarrasser même pour la version normale, en passant par un js externe plutôt que de recopier tout le code à chaque chargement de page sans possibilité pour le client de le mettre en cache[/ul]

Par contre, il existe toujours des forfaits internet mobile très désavantageux. Je suis chez Universal Mobile, et en plus de la publicité offerte gracieusement dès qu'on veut écouter notre crédit ou comme ça en message vocal, malgré le fait qu'on ait désactivé ceci, on paye 1ct le (kilo/kibi?)-octet transféré. Mine de rien, 1Kio de groupement de balises <img ...> pour des boutons inutiles en trop, ça revient vite cher dans ce cas. Je sais pas si le proxy utilisé par Opera Mini suffit à compresser ceci et s'il transfère les éléments affectés par "display: none;", mais je doute que ça soit le cas sur les navigateurs "classiques". De ce point de vue, c'est vrai que les CSS sont insuffisantes pour faire un bon site web mobile ; mais je pense et j'espère que bientôt ces arnarques ne seront plus.

./369 :

- Pas du tout : quel intérêt d'optimiser des pages qui s'affichent en une petite poignée de millisecondes avec les connexions actuelles ? par contre, pour un appareil mobile qui met plusieurs secondes à afficher une page, là ça devient intéressant (voire essentiel)
- Tu oublies beaucoup d'éléments. Par exemple, autant je veux avoir les signatures des membres dans la version "normale", autant les supprimer dans la version "light" m'offrirait un gain significatif (et même si il est possible d'avoir plusieurs fois la même signature au sein d'une page, il reste envisageable d'en avoir 30 différentes). Il en est de même pour le formulaire de post (surchargé) en bas de la page (je peux me passer de tous les boutons de mise en forme si ça présente un intérêt), et sur tout un tas de petites informations secondaires qui une fois additionnées représentent une taille non nulle (date d'inscription des utilisateurs, nombre de posts, adresse mail, bombe, boutons d'administration, etc...)

Zephyr (./371) :
./369 :
- Pas du tout : quel intérêt d'optimiser des pages qui s'affichent en une petite poignée de millisecondes avec les connexions actuelles ? par contre, pour un appareil mobile qui met plusieurs secondes à afficher une page, là ça devient intéressant (voire essentiel)

Tout le monde n'a pas une bonne connexion, et yN a vécu pendant longtemps à l'ère du 56k sans pour autant que l'optimisation ait été considérée comme cruciale A la limite je dis pas ça spécialement pour yN, je dis juste que généralement les webmasters s'en foutent et que déjà leur demander de faire une CSS pas trop moche sur petit écran, c'est le plus important -- si on peut grapiller 30% sur la taille de la page pourquoi pas, mais ça reste du détail. Et puis l'avantage de faire juste une CSS mobile c'est que la transition est transparente, alors qu'un webmaster qui implémenterait une version spéciale sans faire gaffe risque de le faire de façon crade, genre en passant par une url différente ou en hardcodant des user-agents (tiens d'ailleurs c'est quoi la bonne façon de le faire ?)

- Tu oublies beaucoup d'éléments. Par exemple, autant je veux avoir les signatures des membres dans la version "normale", autant les supprimer dans la version "light" m'offrirait un gain significatif (et même si il est possible d'avoir plusieurs fois la même signature au sein d'une page, il reste envisageable d'en avoir 30 différentes). Il en est de même pour le formulaire de post (surchargé) en bas de la page (je peux me passer de tous les boutons de mise en forme si ça présente un intérêt), et sur tout un tas de petites informations secondaires qui une fois additionnées représentent une taille non nulle (date d'inscription des utilisateurs, nombre de posts, adresse mail, bombe, boutons d'administration, etc...)

Les signatures sont quand même souvent répétées, et il y a vraiment pas des masses d'infos en dehors du post, donc peut-être qu'on peut gagner 30% avec de la chance (ce qui n'est pas inutile), mais on est loin des 50% dont tu parles. Pour le formulaire de post, je suis bien d'accord avec toi, et un js externe ou au pire une option dans le profil ne seraient pas superflus même sur la version normale ; pareil pour "mes raccourcis" dont le contenu est apparemment retransmis intégralement à chaque fois... Bref, c'est sûrement plus simple de faire quelques optimisations communes à toutes les versions que de s'amuser à maintenir deux versions différentes ^^

(il n'y a pas forcément que yN dans la vie, y a pas mal de sites qui passent très mal sur un petit écran, et qui à mon avis demanderaient pas mal plus de travail qu'une simple CSS)

genre ? (j'utilise internet que sur pc)

Pollux (./372) :
Tout le monde n'a pas une bonne connexion, et yN a vécu pendant longtemps à l'ère du 56k sans pour autant que l'optimisation ait été considérée comme cruciale

Je te renvoie à webarchive, qui te rappellera bien mieux que moi que l'interface de yAronet est devenue de plus en plus chargée au fil des années et (peut-être pas à cause de, mais le résultat est là) de l'évolution des connexions. Par ailleurs, yAronet n'est pas spécialement agréable à utiliser avec un 56k, je te laisse imaginer ce que ça donne avec une connexion bien inférieure (ce que j'ai sur mon téléphone portable, par exemple) : c'est lent et assez pénible au final.

A la limite je dis pas ça spécialement pour yN, je dis juste que généralement les webmasters s'en foutent et que déjà leur demander de faire une CSS pas trop moche sur petit écran, c'est le plus important -- si on peut grapiller 30% sur la taille de la page pourquoi pas, mais ça reste du détail. Et puis l'avantage de faire juste une CSS mobile c'est que la transition est transparente, alors qu'un webmaster qui implémenterait une version spéciale sans faire gaffe risque de le faire de façon crade, genre en passant par une url différente ou en hardcodant des user-agents (tiens d'ailleurs c'est quoi la bonne façon de le faire ?)

Je me limitais au cas de yN perso, et je me garderai bien de dériver à d'autres exemples (pas envie de troller pendant 10 pages). Ceci dit, on en revient au débat sur les CSS qui a été soulevé il n'y a pas longtemps dans je ne sais plus sur quel topic : c'est très bien de vouloir alléger visuellement les pages, mais à cause de la mauvaise séparation entre XHTML/CSS, ça ne suffit pas. Il faut aussi revoir le code html pour supprimer tous les éléments inutiles, au lieu de les masquer.

Les signatures sont quand même souvent répétées, et il y a vraiment pas des masses d'infos en dehors du post, donc peut-être qu'on peut gagner 20% avec de la chance (ce qui n'est pas inutile), mais on est loin des 50% dont tu parles.

Tu sembles ne compter que le texte brut. Je parle de la page en entier, et donc avec toutes les balises qui vont avec. Un bref coup d'oeil sur la source d'une page, comme je t'invitais à le faire tout à l'heure, te montrera que le code nécessaire pour afficher toutes ces informations secondaires est (beaucoup) plus lourd que les informations elles-mêmes. Bien sûr que le texte ne doit pas dépasser 20%, mais en comptant tout ce que ça entraine, je pense qu'on y est très largement (je n'ai pas compté, c'est une impression comme ça, à vue de nez).

Pour moi, une solution serait de proposer une skin light plutôt qu'une CSS light, qui soulage à la fois la CSS et le code de la page. Un peu à l'image des fonctions "printer friendly" qu'on voit sur certains sites.

(tiens d'ailleurs c'est quoi la bonne façon de le faire ?)

Si j'ai bien compris, tu demandes comment faire pour que le navigateur mobile utilise la CSS mobile et le navigateur de bureau utilise la CSS normale ?

[code]
<head>
...
<link rel="stylesheet" href="mobile.css" media="handheld" />
<link rel="stylesheet" href="normal.css" media="screen" />
...
</head>
[/code]

mais ça zappe pas le contenu téléchargé et pourtant inutile

et quels navs mobiles respectent vraiment l'attribut media?

popo > les trucs qu'on peut voir, c'est quand il y a beaucoup de liens (sans souris, c'est chiant), quand il y a plusieurs colonnes (typiquement, un menu sur la gauche), mine de rien, tu sens passer le moindre ko supplémentaire sur la page (et les balises de mise en forme, ça prend beaucoup de place, suffit de voir toutes les div imbriquées et toutes les classes CSS), les images pour les liens de navigation, les pubs qui peuvent déformer la mise en page, etc..

Zephyr (./375) :
Je te renvoie à webarchive, qui te rappellera bien mieux que moi que l'interface de yAronet est devenue de plus en plus chargée au fil des années et (peut-être pas à cause de, mais le résultat est là) de l'évolution des connexions. Par ailleurs, yAronet n'est pas spécialement agréable à utiliser avec un 56k, je te laisse imaginer ce que ça donne avec une connexion bien inférieure (ce que j'ai sur mon téléphone portable, par exemple) : c'est lent et assez pénible au final.

Je viens de faire le test et en 2002 les pages étaient un peu plus lourdes qu'avant, aussi bizarre que ça puisse paraître (145k vs 106k non compressé, 16.7k vs 16.4k en gzip)

(bien inférieur à un 56k ? :/ c'est le même débit que le wap ?)

Tu sembles ne compter que le texte brut. Je parle de la page en entier, et donc avec toutes les balises qui vont avec. Un bref coup d'oeil sur la source d'une page, comme je t'invitais à le faire tout à l'heure, te montrera que le code nécessaire pour afficher toutes ces informations secondaires est (beaucoup) plus lourd que les informations elles-mêmes. Bien sûr que le texte ne doit pas dépasser 20%, mais en comptant tout ce que ça entraine, je pense qu'on y est très largement (je n'ai pas compté, c'est une impression comme ça, à vue de nez).

Oui mais toutes ces balises sont quasiment les mêmes d'un post à l'autre, donc ça se compresse bien contrairement au texte. Et je pense qu'en utilisant plus la CSS (il y a encore pas mal d'attributs style qui traînent) et en faisant faire un maximum de choses en JS pour les choses qui nécessitent déjà le JS on peut encore réduire. Bon mais évidemment ce serait un peu mieux avec une skin spéciale, me fais pas dire ce que j'ai pas dit ^^

Yann B (./376) :
Si j'ai bien compris, tu demandes comment faire pour que le navigateur mobile utilise la CSS mobile et le navigateur de bureau utilise la CSS normale ?

[code]
<head>
...
<link rel="stylesheet" href="mobile.css" media="handheld" />
<link rel="stylesheet" href="normal.css" media="screen" />
...
</head>
[/code]

Oui ça c'est côté client pour la CSS, moi je demandais ce qu'il fallait faire pour servir des pages différentes côté serveur...

Pollux (./379) :
Oui ça c'est côté client pour la CSS, moi je demandais ce qu'il fallait faire pour servir des pages différentes côté serveur...

Dans les headers HTTP tu as le type de navigateur. Perso, je m'en sers pour servir une CSS supplémentaire adaptée à chaque navigateur ^^

c'est dans User-Agent ou c'est autre chose ?

vi, je pense

Pollux (./379) :
Je viens de faire le test et en 2002 les pages étaient un peu plus lourdes qu'avant, aussi bizarre que ça puisse paraître (145k vs 106k non compressé, 16.7k vs 16.4k en gzip)

Ah ? Curieux, j'aurais pensé l'inverse; la remarque reste vraie même si on remonte jusqu'en 2002 alors ^^

(bien inférieur à un 56k ? :/ c'est le même débit que le wap ?)

Yep. parfois c'est aussi une connnexion de merde fournie par un mcdo, un hotel, un aéroport, etc... (il y a bien des moments où un 56k m'aurait semblé rapide ^^)

Oui mais toutes ces balises sont quasiment les mêmes d'un post à l'autre, donc ça se compresse bien contrairement au texte. Et je pense qu'en utilisant plus la CSS (il y a encore pas mal d'attributs style qui traînent) et en faisant faire un maximum de choses en JS pour les choses qui nécessitent déjà le JS on peut encore réduire.

Il y a des chances, mais quand je vois la quantité astronomique de <div> imbriqués qui sont utilisés pour des effets dont on pourrait largement se passer, je pense malgré tout que le gain de place serait relativement important. Même si certains de ces <div> sont redondants.

Bon mais évidemment ce serait un peu mieux avec une skin spéciale, me fais pas dire ce que j'ai pas dit ^^

Je ne t'ai rien fait dire du tout, j'ai juste évoqué ce que je pensais être une solution pas trop mauvaise, sans prétendre que tu l'avais jugé mauvaise ^^

squalyl (./377) :
mais ça zappe pas le contenu téléchargé et pourtant inutile

et quels navs mobiles respectent vraiment l'attribut media?

Si ça peut zapper au moins les images par exemple

ok, en fait je parlais de la page html elle même

Ouéééé 76/100 avec la dernière beta de Konqueror (4.0.82). Soit un gain de 1 point.
Genre je vous soûle avec Konqueror... Kevin au moins toi tu me comprends !

Tiens un truc bien sous firefox 3 c'est qu'il retient maintenant le niveau de zoom d'un site (donc j'ai plus besoin de faire Ctrl-+ chaque fois que je viens sur yN et dans tous les onglets ), par ailleurs on peut désactiver l'option qui zoome non seulement le texte mais aussi les images et qui donne des smileys hideux, c'est cool ^^

(bon par contre maintenant si je vais sur yN au taff c'est écrit un peu gros, mais c'est moins gênant que dans l'autre sens, et puis j'ai pas à aller sur yN au taff #ahem#)

(la raison pour laquelle je dois zoomer quand je suis sur l'écran interne du portable est qu'il est à 120 dpi au lieu de 96 pour l'écran externe, et que yN spécifie la taille de la fonte en px et non en pt (!slap yAro))
• Sally slaps yAro)) around a bit with a large trout !

Sasume (./386) :
Ouéééé 76/100 avec la dernière beta de Konqueror (4.0.82). Soit un gain de 1 point.

As-tu mis à jour ta libpcre ou était-ce un correctif dans Konqueror lui-même? Parce qu'il y a un point de plus ou de moins selon la version de la libpcre utilisée.

Mais en tout cas Konqueror rulez!

J'ai mis à jour Konqueror seulement. Je ne sais pas si j'ai la dernière version de libpcre : j'ai la version 7.6-2.

Sally (./387) :
Tiens un truc bien sous firefox 3 c'est qu'il retient maintenant le niveau de zoom d'un site (donc j'ai plus besoin de faire Ctrl-+ chaque fois que je viens sur yN et dans tous les onglets ), par ailleurs on peut désactiver l'option qui zoome non seulement le texte mais aussi les images et qui donne des smileys hideux, c'est cool ^^

c'est pas mal, ça