[color=800000]Détection d'écran en JavaScript[/color]Peu importe que l'on soit en conformité XHTML ou HTML... Si les attributs des balises HTML ne sont pas dynamiques, ou sont insuffisants pour un concept visuel donné (ex. trop larges pour un écran 800x600 ou une fenêtre 600x400), alors la page enfreindrait un autre aspect de <I>conformityé</I>: l'utilisabilité. Quand le design visuel impose de telles limites techniques, considérez d'aiguiller sur la bonne page selon que l'on soit en 800x600 ou 1024x768 (on peut raffiner ces fourchettes de résolution) :
<SCRIPT language="JavaScript">
<!--
if ((screen.width>=1024) && (screen.height>=768)) {
window.location="haute_res.html";
}
else {
window.location="basse_res.html";
}
//-->
</SCRIPT>
Pour afficher la résolution dans un pop-up JavaScript:
<A HREF="javascript:alert('Votre resolution est '+screen.width+'x'+screen.height);">Cliquez pour voir votre résolution d'écran</A>
[color=800000]Détection d'écran en PHP et JavaScript[/color]PHP joue le rôle d'un
wrapper, la détection restant le lot de JavaScript. Effectivement, PHP ne peut interagir avec le DOM du navigateur client, et on doit donc passer par JavaScript. L'idée est de lire un cookie contenant la résolution, puis de scripter le reste de la page selon cette résolution (génération dynamique d'HTML). Notons qu'au lieu d'utiliser des cookies, nous pourrions très bien interagir avec une base de données contenant les profils des clients enregistrés au site. Et que chacun d'eux puisse avoir plusieurs résolutions potentielles (format Palm, format bureau en 800x600, format maison en 1024x768, etc.). Mais pour la simplicité de l'exemple, restons en aux cookies...
On doit au préalable vérifier la présence du cookie, et ce n'est que si ce dernier n'est pas présent qu'une fonction JavaScript va l'écrire, pour que par la suite le script se relance lui-même (auquel cas le cookie existe, et la page adéquate est donc générée). Voici le script à sauvegarder dans le fichier
lit_resolution.php (qui pourrait être nommé index.php ou autre, mais il faut alors modifier ce nom dans le script):
<HTML>
<TITLE>Résolution d'écran</TITLE>
<HEAD>
<?php
if(isset($HTTP_COOKIE_VARS["resolution"]))
$res_ecran = $HTTP_COOKIE_VARS["resolution"];
else {
// Le cookie n'est pas trouvé : le créer avec JavaScript
?>
<script language="javascript">
<!--
ecritCookie();
function ecritCookie() {
var aujourdhui = new Date();
var la_date = new Date("December 31, 2023");
// dans ce qui précède, vérifiez l'utilisation du format date
var la_date_cookie = la_date.toGMTString();
var le_cookie = "resolution="+ screen.width +"x"+ screen.height;
var le_cookie = le_cookie + ";expires=" + la_date_cookie;
document.cookie=le_cookie
location = 'lit_resolution.php';
}
//-->
</script>
<?php
}
?>
</HEAD>
<BODY>
<?php
echo "<B>Votre résolution d'écran est ". $res_ecran."</B>";
echo "<BR>Ici vous pouvez faire le traitement de cette résolution afin de générer la page adéquate, avec un SWITCH CASE par exemple, ou une structure if-else-if..";
?>
</BODY>
</HTML>
Question importante : Que ce passe-t-il avec le script PHP précédent (qui s'appelle lui-même), si le navigateur client a les cookie désactivés? Je soupçonne une boucle infinie, sur fond de page Web blanche, comme l'infini... Alors attention, assurez-vous que la lecture des cookies soit activée!!
Si vous faites un site en 800x600, en ce basant sur les stats que j'ai données précédemment, vous répondez aux attentes de 98.3% des visiteurs.
Je suis pour cette approche. Il ne faut JAMAIS assumer un comportement unique des utilisateurs. Imposer une résolution est la chose à éviter lorsqu'on design des pages Web, il vaut mieux "designer par le bas" (concevoir pour 800x600 plutôt que pour 1024x768), ou mieux, utiliser des attributs de balise à dimensions dynamiques plutôt qu'absolues. Les meilleurs exemples selon moi sont tous ces sites qui publient des textes dans des tableaux à largeur fixe... Déplorable, et c'est souvent la démonstration que le prétendu WebMaster se limite à des gabarits de balises pré-fabriqués, ou à un éditeur WYSIWYG. Et si le client du WebMaster <I>insiste</I> pour imposer à ses utilisateurs des limitations techniques, pourtant facilement contournables (dans le design ou dans le code), il devient nécessaire de lui faire "entendre raison"...
de le mettre à jour en lui parlant de l'aspect [color=800000]customer-centric[/color] qu'impose le Web. Pour ma part, si le client continue à faire la sourde oreille malgré les stats et les arguments béton (ce qui ne m'est arrivé qu'une seule fois), je lui dis d'aller voir ailleurs car je ne veux pas mêler mon nom aux insuccès de son site - tout restant relatif bien entendu, que ce soit dans la parole ou dans le geste... ;-)...
pour christophe certain : ne comparons pas des pommes et des oranges, telle une fenêtre de cellulaire versus un écran d'ordinateur! Dans la pluspart des cas, on design un site pour qu'il soit vu sur un écran d'ordinateur, et si ça demande une interface pour les autres bidules Web, on la fait séparément. Donc deux sites, selon le bidule qui accède, et c'est un autre contexte où tout le design de l'architecture Web devient vital (plus que le codage de balises), en prévoyant un design "3-tiers" : processus data (SGBD, structure d'emmagasinage des données et du contenu du site), processus d'affaires (moyens d'échanges des données, fonctionnalités et app Web); processus clients (présentation du contenu).
Au-delà d'utiliser un Environnement technologique de gestion de type multi-développeurs, avec documenation des bugs et tout le reste, le plus important selon moi dans la modélisation des applications Web, d'entreprise, interfaces Web et processus d'affaires, le plus important disais-je est d'utiliser une approche multi-couche, à même le design des codes, des scripts, des modules maisons, etc, garantissant ainsi un niveau adéquat d'assurance qualité des produits, mais aussi (et surtout) des analyses prévisionnelles en termes de coûts, de budgets (et de revenus si on est dans les pieds d'un consultant en TI). Et ceci quelle que soit la technologie de gestion de projet Web ou de développement Web sous-jacente : un plombier équipé d'un pinceau d'artiste peintre, ça ne sert à rien...
Il devient alors aisé dans un tel contexte de prévoir divers processus clients (exprimant le design visuel des interfaces), selon une fourchette de résolution relative à chaque bidule concerné, et à bien moindres coûts. Avantage que l'on retrouve d'ailleurs pour tous les autres aspects du site ainsi modelés (en 3-tiers par exemple, modèle n-tiers), avec un impact majeur sur sa gestion et son cycle de vie..
