PHPFrance

[Berzemus]

quel pub ?

[pyxel99]

Bonjour,
je realise depuis 6 mois une statistique precise sur un journal de bord qui note les nojavascript et quelques autres cas particuliers (nocook, mobile, etc...) sur divers petits sites pour 25000 accés. Il en ressort que le javascript est desactivé chez 2% des utilisateurs (volontaires ou accidentels)-statistique tres constante sur les ordinateurs classiques-.
Mais un nouveau phenomene apparait depuis peu en 2008. l'acces internet via les mobiles et il faut noter que 1/3 de ces appareils n'ont pas de javascript. L'usage des mobiles reste encore limité a 2% du total des visiteurs mais ça progresse et cela evoluera encore avec les ameliorations du materiel et il faudra en tenir compte.
Voila une info utile pour les developpeurs.
Pyxel

[AB]

Merci de ces précisions

Pour les mobiles, c'est un autre problème je pense. J'ai lu ici et là que pour être convenablement vu sur un mobile les sites doivent être conçu pour ça. Pour ceux qui s'intéressent à ce marcher cela fait donc deux sites distincts à faire : un pour les grands écrans, un pour les mobiles.

[Victor BRITO]

Pour ceux qui s'intéressent à ce marcher cela fait donc deux sites distincts à faire : un pour les grands écrans, un pour les mobiles.

Pas nécessaire : rien qu'avec les CSS, tu peux cibler le type de support, grâce aux médias CSS (screen pour les écrans d'ordinateur, print pour les versions imprimées, handheld pour les supports qui tiennent dans la main, comme les mobiles et les PDA). Et si l'on intègre des CSS et que l'on a Opera, on peut émuler le rendu d'une feuille de style handheld en sélectionnant Présentation > Petit écran.

[Cyrano]

Et ce sera pas forcément suffisant. Parmi les mobiles, il y a différentes tailles d'écran. Le portable classique, pliant ou non, le BlackBerry avec un écran un peu plus grand ou encore le iPhone.

Je discutais il y a très peu de temps avec un spécialiste dans une entreprise qui fait précisément de la diffusion de sites Internet pour mobiles : c'est pas tout à fait un métier à part, mais ça se traite de manière particulière : on aura en particulier pas tout à fait le même contenu faute de place pour afficher de façon rationnelle le contenu d'un site pour navigateur sur PC.

[AB]

Oui Victor, en théorie c'est possible, mais en pratique faire un site qui pourrait être lu sur n'importe qu'elle taille d'écran restreindrait considérablement le graphisme.
Même à coup de css spécifiques, sauf cas particulier, tu risque d'atteindre un niveau de complexité telle qu'il sera plus rentable et plus optimisé de faire deux sites distincts. D'ailleurs souvent le contenu textuel est également plus condensé pour les mobiles...

Les echos que j'en ai eu rejoignent donc ceux de Cyrano, cela se traite apparemment pour l'instant de manière spécifique.

[Berzemus]

Dire qu'on essaye de nous faire croire que tout ça n'est qu'un problème de vue..

Mais comme victor j'imagine que pour un site assez léger, on doit pouvoir s'en sortir avec du html épuré et du css 'achement blindé, quitte à cacher le contenu inutile pour petits écrans, et offrir plus de facilités pour les grands écrans. ça doit être amusant à réaliser..

[Victor BRITO]

Oui Victor, en théorie c'est possible, mais en pratique faire un site qui pourrait être lu sur n'importe qu'elle taille d'écran restreindrait considérablement le graphisme.
Même à coup de css spécifiques, sauf cas particulier, tu risque d'atteindre un niveau de complexité telle qu'il sera plus rentable et plus optimisé de faire deux sites distincts. D'ailleurs souvent le contenu textuel est également plus condensé pour les mobiles...

Le problème de créer deux sites distincts, selon que l'on utilise un support mobile à écran réduit ou pas, est de s'assurer que les deux soient à jour en même temps. Or, en se basant sur un seul et même site et en jonglant entre les médias en CSS, tu as de quoi garantir que les utilisateurs d'un ordinateur et ceux d'un PDA reçoivent le même contenu, en utilisant le même principe que pour la version imprimée d'une page (où, en CSS, tu masques tout ce qui est inutile à une page imprimée). Pour le graphisme, tu peux en faire, mais à condition de faire du graphisme souple, qui s'adapte parfaitement à des unités relatives, ce qui est possible.

Si, malgré les avantages des CSS, tu tiens à créer deux sites distincts (par exemple, l'un en XHTML, l'autre en WML ou dans un doctype spécifique à un site pour mobile), tu peux (toujours dans l'optique de s'assurer que tout le monde accède au même contenu mis à jour en même temps) stocker ton contenu dans une base de données ou dans des fichiers XML et générer l'affichage adéquat au moyen de feuilles de styles XSLT. Ce peut être une autre solution envisageable.

[zeus]

C'est également dans ce genre d'optique que le MVC deviens encore un peu plus important

Avec un petit système qui détecte si le type de réponse et qui redirige vers les bonnes vues, pas besoin de 2 sites, mais uniquement de 2 jeux de vues

[AB]

... tu peux (toujours dans l'optique de s'assurer que tout le monde accède au même contenu mis à jour en même temps)...

C'est là le problème parce que précisément le contenu, y compris textuel, diffère suivant l'affichage de destination, allant à l'essentiel pour les portables et plus détaillé pour les autres. Ce qui fait qu'in fine, tout est différent.
Maintenant je dis pas que c'est impossible, je dis que d'après ce que j'ai lu, les sites pour portables sont actuellement développés spécifiquement pour cette cible

[BeRoots]

Moi je fais toujours (dans la mesure du possible) une alternative à mes scripts Javascript en PHP. Une solution de remplacement en gros...

Même avec JS de désactivé, tout doit être fonctionnel... Le truc c'est de faire la part des chose entre server et client

Pour moi je ne vois pas de réel rapport avec l'accessibilité ici car c'est plutot coté HTML que cela ce fait.

Sinon, en JS, je fait toujours en sorte d'éviter un max l'utilisation des attribut id et class et de cibler via l'attribut rel. C'est plus simple pour relire
De plus, tout mes script JS sont penser pour s'instancier et completer le html au DOMREADY. De ce fait si JS est coupé, on ne pollue pas le html et rien ne s'execute...

En gros pas de soucis en faisant comme ceci