Quelle Css pour un mobile ?

(reprise du message précédent)

Pendant Paris Web, il a été question d'utiliser le sous-domaine m.domain.tld, à la manière de wap.domain.tld avec m pour mobile bien entendu. Il me semble que c'était Dom qui en parlait (donc le W3C), après à voir dans quels cas c'est une bonne chose ou pas de séparer les sous-domaines m et www, s'il y a intérêt à payer le .mobi, etc

EDIT: sur les sites web 2.0 hype (pléonasme ), il existe un bouton qui réunit 20 boutons avec toutes les manières de promouvoir un article dans Digg, Fuzz, etc, etc, etc
A quand 2 boutons avec dans l'un le choix de la langue tellement il y en a et dans l'autre le choix de son type de navigateur (j'ai un mobile, le haut débit ou j'arrive à me connecter par satellite depuis un endroit perdu pour 10€/H merci de faire très simple) ?
Modifié par Felipe (31 Dec 2007 - 11:14)

Je ne vois pas trop ce que tu veux dire par modifiable par le navigateur?

par exemple le useragent d'un sonyericsson k800i sera toujours SonyEricssonK800i/blablabla/blablabla

je suppose que le site qui permettre du téléchargement (logos, ringtones, jeux java) sur mobile et qui ont besoin de détecter quel mobile on utilise travaille grâce au useragent non?

Par contre je suis d'accord sur le fait que c'est trop lourd à suivre car il s'en rajoute presque tous les jours.

Plus je m'y intéresse, plus je me rends compte que c'est d'une grande difficulté

quelque chose comme ceci n'est-il pas acceptable?

-http://wap.esato.com/

==> via mobile le choix est wml ou xhtml, via pc le choix est xhtml mobile ou html.




(Je m'intéresse à ceci depuis un court moment car je compte faire un site compatible ordinateur et mobile dans le courant de l'année. )
Modifié par Dindon (02 Jan 2008 - 06:45)

koala64 a écrit :
On connait les problèmes d'une détection de résolution par l'intermédiaire de Javascript: on ne peut compter dessus, ne serait-ce que parce que ce langage n'est pas forcément disponible. (Perso, j'ai dû l'activer sur mon portable; ce n'était pas le cas par défaut)

Oui mais... cette démarche est destinée aux mobiles ne comprenant pas handheld, dont on peut supposer que le nombre va aller en se réduisant. Ne comprendre ni handheld ni javascript ne devrait concerner qu'un nombre de modèles assez restreint ?

koala64 a écrit :
Et puis reconnaitre un quelconque support par l'intermédiaire de JS ou PHP, ce n'est pas fiable... Donc pourquoi ne pas proposer une feuille css adaptée via un styleswitcher ? Ca permettrait de s'affranchir de la détection. (qu'on peut malgré tout ajouter... mais à titre optionnel)

Euh... un styleswitcher requiert ou JS ou PHP, non ?

@Dindon

Se lancer dans une détection d'UA est condamné par avance, autant l'oublier tout de suite. La solution Esato est dérangeante : on revient dix ans en arrière où on devait cliquer en page d'accueil sur IE ou NS

@Felipe

L'idée est d'arriver à ne maintenir qu'un seul site. Est-ce raisonnablement possible, c'est tout l'enjeu de la question.

Meilleurs voeux à tous
Modifié par Arsene (02 Jan 2008 - 12:41)

Salut,

Une petite remontée pour vous montrer la solution que j'ai finalement adoptée sur mon site :

<!--[if IE]>
<style type="text/css" media="screen">
	@import '/dotclear2/themes/lombre/style.css';
</style>
<![ endif ]-->

<!--[if !IE]> <-->
<style type="text/css" media="screen and (min-device-width: 481px)">
@import '/dotclear2/themes/lombre/style.css';
</style>
<!--> <![ endif ]-->
<style type="text/css" media="handheld">
@import '/dotclear2/themes/lombre/handheld.css';
</style>
<style type="text/css" media="print">
@import '/dotclear2/themes/lombre/print.css';
</style>
<style type="text/css" media="only screen and (max-device-width: 480px)">
@import '/dotclear2/themes/lombre/handheld.css';
</style>

Bon c'est peut-être pas très propre, mais comme IE6 bloque sur les medias queries (et pour cause), c'est la seule solution que j'ai trouvé.

Si vous avez des suggestions...
Modifié par Patidou (22 Feb 2008 - 15:24)

c'est pas mal du tout comme solution.
Par contre, tu ne mises que sur les mobile en version wap 2.0 et supérieur
toutes les versions en dessous travaillent en WML par exemple, ne seront pas accéder à ton site.
Il sera aussi impossible de faire des execptions ( et le monde des mobiles en est truffés de partout)

Je me trompe peut-être, mais je persiste à dire qu'il faut travailler en détectant le UA. je n'ai pas dit pour autant que le DB les contenant devait être gérer pour le concepteur du site.


Ceci n'a rien a voir directement, mais j'ai trouvé un cms pour mobile assez sympa ( qui fait de la détection et du rendering) :

-http://www.huria.fr/

qu'en pensez vous?

Effectivement doclear2 ne sort pas (encore?) du wml… Mais bon, si un jour un plugin Dotclear2 sort pour faire du wml, je l'installerai, pas de problème…

Pour ce qui est de hurla, j'ai regardé le code source généré et sans vouloir préjugé des capacités de ce CMS, je n'ai pas trop aimé la mise en page par tableaux.

Mmmh… Pour ce qui est de la détection de l'UA basée le nom de l'agent utilisateur, comme Arsene, je pense que ce n'est pas une bonne idée : tu imagines le nombre de GSM à gérer? Si vraiment détection il devait y avoir, ce serait sur le protocole http pour voir l'UA accepte le wml ou non…

Mais là on s'éloigne du sujet qui est la gestion des CSS sur mobiles…

Entre temps j'ai un peu avancé sur le projet... L'idée (qui relève de la démarche de "discrimination objective" : voir ce post) est de ne pas se sentir obligé de distribuer de contenus identiques mais, en partant d'un contenu unique, de muter celui-ci selon les UA qui auront en charge sa restitution (sur la mutabilité, voir ce post).

Donc maintenant on en est là : selon la taille d'écran/viewport (lire les premiers posts de ce sujet) on affiche au choix :
- la structure Html "classique" (h1, h2, h3, h4, p...) si l'UA est reconnu apte à la faire, ou
- un "menu" à base de <h3> (choix empirique, juste pour tester) qui zappe complètement tout ce qui est "<non-h>" ou "<h inférieur à 3>... et où les <h3> deviennent alors des <li>.
De la sorte, en choisissant la "version pour mobiles", on génère un contenu "light" adapté aux contraintes de taille d'écran, de temps de connexion, de coût de chargement, etc...
La contrainte du coup est de réfléchir aux intitulés de titres/têtes de grandes parties mais c'est plutôt une bonne contrainte puisqu'elle oblige à bien penser les contenus en amont. Le deuxième titre <h3> montre aussi comment on peut par une regex optimiser l'affichage de certains objets si un besoin particulier le nécessite.

Démo : C'est là que ça se passe
Une fois la page affichée, réduisez la fenêtre à 400-500px et rechargez-la : le point 6 (CONSULT) doit proposer un lien vers la version pour mobiles. Cliquez et regardez ce que donne la css active "moobil" (point 1).
Le "contenu unique" : Voir le fichier .txt


<edit1>Pour le moment ça ne fonctionne qu'avec la Css "moobil" mais rien n'empêche d'étendre le dispositif à "handheld", voire même de lui spécifier d'autres règles</edit>

<edit2>Il s'agit d'une technologie serveur, pas d'une astuce CSS qui masquerait par display:none ou visibility:hidden les contenus en question. Passer par Css marche pareil mais contraint au chargement des datas, ce qui n'est pas le but recherché</edit>

<edit3>

Felipe a écrit :
A quand 2 boutons avec (...) le choix de son type de navigateur (j'ai un mobile, le haut débit ou j'arrive à me connecter par satellite depuis un endroit perdu pour 10€/H merci de faire très simple) ?

C'est un peu ça l'idée...</edit>

<edit4>Vite fait sur le gaz une version "bouton pour Felipe" expurgée de tout ce qui ne sert à rien : C'est par ici</edit>
Modifié par Arsene (25 Feb 2008 - 18:54)