probleme de decalage horaire

En France, comme ailleurs, on règle *rarement* son navigateur
correctement.

Quel besoin de régler le navigateur, ça se fait tout seul à
l'installation en fonction des paramètres du système.

J'en doute, en toute généralité, et à moins que le navigateur soit livré
avec une boule de cristal je doute qu'il connaisse la *liste* des langues
qui m'intéressent (puisque la négociation de contenu se base sur une
liste choisie par le client, alors que dans un système d'exploitation il
n'y a qu'une langue à choisir).

Qui plus est on peut avoir des choix différents en local pour le système
et pour les sites web qu'on visite.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

En France, comme ailleurs, on règle *rarement* son navigateur
correctement.

Quel besoin de régler le navigateur, ça se fait tout seul à
l'installation en fonction des paramètres du système.

J'en doute, en toute généralité, et à moins que le navigateur soit livré
avec une boule de cristal je doute qu'il connaisse la *liste* des langues
qui m'intéressent (puisque la négociation de contenu se base sur une
liste choisie par le client, alors que dans un système d'exploitation il
n'y a qu'une langue à choisir).

Le plupart des utilisateurs n'utilisent que la langue par défaut de l'OS
et s'il rajoutent une langue, elle est rarement mise par défaut.

Point besoin de boule de cristal à mon Firefox pour savoir qu'il doit
utiliser fr_FR par défaut que ce soit sous Windows, Linux ou les autres
systèmes.

Il n'y a vraiment que pour ceux qui utilisent KDE en breton que tout ça
pose problème. En général, ils règlent comme second choix le français.

Bonjour,

La, vous demandez une intervention de l'utilisateur,

Non. On laisse la main à l'utilisateur.

Ce que veut l'utilisateur, c'est en faire le moins possible, alors
autant lui facilité la tâche et lui proposer une alternative si le
système s'est trompé.

la manipulation
avec l'objet Date en javascript ne demande aucune intervention de
l'utilisateur.

C'est bien son rôle : le confort de l'internaute.

Donc : on laisse toujours le choix à l'utilisateur de *pouvoir* choisir
son fuseau horaie, sa langue, etc... et on traite donc ça côté serveur.

Je n'ai pas dis qu'on ne pouvait pas utiliser les deux système.

Si on a 10 minutes à ne rien foutre et qu'on veut jouer avec JS, on
essaye de *deviner* côté client ce que l'utilisateur aurait choisi et on
le fait en automatique pour lui, pour son confort. Ca tombe bien, si
l'utilisateur n'a pas JS activé, ou si on s'est planté, non seulement
l'utilisateur peut quand même accéder à ce qui lui convient, mais en
plus on n'a pas une seule ligne de code à changer côté serveur qu'on
décide de faire le JS maintenant ou plus tard.

Il faut arreter de croire que javascript est juste un truc pour
bidouiller pour le confort de l'utilisateur, on est plus en 1995.

Déterminer la timezone en javascript est très fiable puisque basé sur
les réglages de l'OS. Ceux qui la change sont des utilisateurs avancés
et ils savent très bien ce qu'il font.

Javascript est aujourd'hui fiable, il permet de faire beaucoup de choses
et le % d'internautes à le désactiver est très faible ( en général ce
sont les webmasters disant que JS c'est nul d'ailleurs )

C'est exactement comme pour tous les traitements : ça doit fonctionner
sans JS activé (et sans cookies activés),

Ecoutez la bonne parole !!!!
Il faut aussi que sont site soit XHTML strict avec des feuilles de
styles et qu'il réponde au norme WCAG.

Ce n'est pas parce que le site doit fonctionner sans JS et sans Cookies
qu'il faut s'en passer. Le fonctionnement sans ne doit être qu'une
alternative.

Ce n'est pas parce que Lynx ou Links ne savent pas lire les images qu'il
ne faut pas les utiliser.

quitte à ce que l'utilisateur
doive, du coup, faire deux clics de plus, ou arrive dans une "impasse"
de navigation en cas d'erreur de saisie. Mais bon, ça fait des années
qu'on le répète et on le répètera encore dans des années.

Et bien justement, il serait temps d'évoluer un peu.

La notion de (rétro)compatibilité ne passera
jamais dans les moeurs, alors que c'est primordial pour les
utilisateurs.

La demarche est un peu courte je trouve. Si on doit créer une
application qui doit être compatible, ce n'est pas une raison pour
laisser tomber tout le reste. Si on passe par là, on ne fait que du HTML
compatible avec Mosaïc, on ne va pas aller loin.

En fait, c'est le principe du nivellement par le bas.

Ce n'est pas parce que le site doit fonctionner sans JS et sans Cookies
qu'il faut s'en passer. Le fonctionnement sans ne doit être qu'une
alternative.

Ce n'est pas parce que Lynx ou Links ne savent pas lire les images qu'il
ne faut pas les utiliser.

Et quid du javascript pour lynx/links ?

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Le plupart des utilisateurs n'utilisent que la langue par défaut de l'OS
et s'il rajoutent une langue, elle est rarement mise par défaut.

C'est votre vision des choses. Ce n'est pas la mienne.

Il n'y a vraiment que pour ceux qui utilisent KDE en breton que tout ça
pose problème. En général, ils règlent comme second choix le français.

Non. Mon OS ne connait pas ma langue préférée et prend donc la langue par
défaut (anglais) - et c'est fait exprès,
alors que mon navigateur a une *liste* de langues avec français en premier.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

ftc wrote:

Il faut arreter de croire que javascript est juste un truc pour
bidouiller pour le confort de l'utilisateur, on est plus en 1995.

Tu fais quoi d'un utilisateur qui ne peux pas l'activer ? Tu l'envoyes
dans /dev/null ? Comme exemple, je ne sais pas si tu as déjà vu un
aveugle utiliser une tablette braille, je peux t'assurer qu'il ne fait
pas ça avec mozilla/IE... Minorité ? Un des meilleurs du departement
informatique de mon ecole est dans ce cas.

Je n'ai rien contre un control de form en JS (avec le même coté serveur
après hein !), mais il ne faut en aucun cas que cela defigure le site.
Sauf si tu fais un boulot très propre, je doute que ton JS peut rester
totalement transparent. Il faudrait pour cela que tu affiches la date en
brute dans le code html à sa place et que ton code javascript recupere
cette date par parsing, la traite, et la modifie en live. C'est
faisable, peut de personnes feront comme cela.

Déterminer la timezone en javascript est très fiable puisque basé sur
les réglages de l'OS. Ceux qui la change sont des utilisateurs avancés
et ils savent très bien ce qu'il font.

Qu'est ce qui te prouve que la personne à bien régler son OS ?

Dans un cas tu te retrouves avec un site qui fonctionne quoi qu'il
arrive et tes utilisateurs peuvent choisir quel fuseau horraire il
veulent utiliser. (qui te dit qu'en habitant en france, ils ne vivent
pas à l'heure japonaise car leur famille s'y trouve ?)

Javascript est aujourd'hui fiable, il permet de faire beaucoup de choses

Fiable ? Tu parles d'une technologie qui est implantée de plus de façon
qu'il existe d'internautes ? Chaques moteur de rendu utilise sa propre
version. Gecko, Khtml, Ie, la liste est longue.
Entre Javascript, JSscript, ECMA script et j'en passe, chacun y va de
son idee pour ce langage. Comparé au JS, le php est un eden
d'uniformisation.

et le % d'internautes à le désactiver est très faible ( en général ce
sont les webmasters disant que JS c'est nul d'ailleurs )

Trés faible ou inexistant ?
C'est comme dire à une personne en chaise roulante : Désolé, vous ne
pouvez pas acceder à ce musée super connu, des gars comme vous ont en a
que trois par ans, c'est trés faible pour installer une rampe.

Sauf que dans le milieur de l'info ce genre de ségrégation ne gene plus
personnes, c'est presque normal.

C'est exactement comme pour tous les traitements : ça doit fonctionner
sans JS activé (et sans cookies activés),

Ecoutez la bonne parole !!!!

Je suis d'accord avec John, à cela que je nuancerais une chose :

À l'inverse du javascript, les cookies sont une spécificité du protocol
http lui-même. Cela en fait donc quelque chose de bien mieux implanté.

Dans la pluspart des cas, l'utilisation du cookie peut s'éviter avec une
gestion corect des URLS (le premier qui me stocke une info de langue
dans un cookie !)

Il reste cependant le cas de la gestion de session. Dans ce cas là je
suis partagé. Si la personne a désactivé les cookies, c'est qu'elle ne
desire pas être suivie par un quelquonque moyen (gestion de session y
comprit). J'ai toujours pensé que l'on n'avait pas le droit de le suivre
avec un id passé via GET sans son autorisation.

Maitenant il est evident que pour un site où tout le contenu necessite
une session (cas des pannier de vente en ligne), on peux considerer que
si l'utilisateur viens sur ce site, il accepete d'être suivie, d'ou un
passage du session_id par get.

Il faut aussi que sont site soit XHTML strict avec des feuilles de
styles et qu'il réponde au norme WCAG.

Tout à fait d'accord. Maitenant c'est comme le JS, il y a autant de
version du html implantés que de fautes d'orthographes dans les messages
que j'ai écrit sur fclp depuis que j'y suis. (Quoi que non, cela fait
quand même beaucoup). La standardisation de tout cela arrivera, je le
souhaite, mais en attendant, on esseye de faire pour le mieux avec les
donnée actuelles.

Cela n'empeche pas que je suis pour les sites en HTML 4 (XHTML pas
encore implanté et non retro compatible, c'est du XML et non pas du
SGML). Et aussi pour les CSS, même si l'on doit sacrifier un pixel de
décalage sous certains navigateurs.

Ce n'est pas parce que le site doit fonctionner sans JS et sans Cookies
qu'il faut s'en passer. Le fonctionnement sans ne doit être qu'une
alternative.

Ce que tu dit est parfait, sauf qu'il faut le lire dans l'autre sens
(comprandre: le sens opposé, la négation ).

Ce n'est pas parce que Lynx ou Links ne savent pas lire les images qu'il
ne faut pas les utiliser.

Dans ce cas ce n'est pas parce que 90 % des navigateurs du marché ne
lisent pas le SVG, qui est pourtant une technologie formidable, qu'il
faut s'en passé ?

Encore une fois cela depent. Si il s'agit du confort fioritures, aucun
problème, utilise. Si il s'agit du fonctionement vital, POUBELLE !

Maitenant concernant les images, tu as un atribut html bien pratique,
alt, qui est fait pour le cas de Lynx et consort. (Et qui est
obligatoire, et qui meme si il ne l'était pas devrait l'être !)

Et bien justement, il serait temps d'évoluer un peu.

Attention, pikachu evolue ! (Bon, je sais c'est pas possible, il
n'évolue pas de manière imprevisible, on ne peux donc pas être surprit).

L'évolution c'est un bien joli mot.

À une époque il faisait du traitement de texte sur ce qui me fait office
de calculette, 20 Mhz, quelques kilos de ram, un bout de disque. Et cela
fonctionnaist de façon correct. Maitenant les traitements de textes
tiennent sur 2 cds et ont des compagnons 3D qui rebondissent dans tous
les coins pour apporter une aide pour s'y retrouver dans le soft de
traitement de texte qui est aussi capable de traduire/faire le
café/sortir le chien/faire la vaiselle. Cela a-t-il apporter quelque
chose si ce n'est des embetement (je reste poli)

Par contre à une époque on codait tout en assembleur. C'était trés
marrant et je dit bravo à ceux qui on fait cela (d'autre le font
encore...) car das le niveau brain fucking, on ne fait pas mieux.
Maitenant on a le C, presque aussi bas level que l'assembleur, mais
beaucoup plus simple. Et on à le haut level, Python par exemple. Php
pour le web. Ça c'est de l'évolution.

Dans ton discours pour l'évolution, tu confonds deux choses AMHA,
l'évolution utile et l'inutile.

La demarche est un peu courte je trouve. Si on doit créer une
application qui doit être compatible, ce n'est pas une raison pour
laisser tomber tout le reste. Si on passe par là, on ne fait que du HTML
compatible avec Mosaïc, on ne va pas aller loin.

C'est dingue ce besoin de tout dramatiser. Le but n'est pas de revenir
au base de l'internet. Mais qu'il ne faut pas risquer de perdre de la
compatibilité pour l'implantation d'une option qui n'apporte pas grand
chose.

En fait, c'est le principe du nivellement par le bas.

Trés utile des fois. Surtout en informatique. On est encore au tout
début de l'informatique (et surtout en ce qui concerne le web). Il y a
donc des choses qui mettent du temps à se mettre en place et forcement à
des niveaux differents. On ne doit laisser personne derrière (devise des
marines a ce qu'ils disent dans les films d'holywood), alors on marche à
la vitesse des plus lents. Quand ceux-ci auront évolué, alors on
augmentera notre allure.

Merci de m'avoir lu jusque ici. J'ai du m'embrouiller un peu, désolé.

--
Guillaume.

Ce n'est pas parce que le site doit fonctionner sans JS et sans Cookies
qu'il faut s'en passer. Le fonctionnement sans ne doit être qu'une
alternative.

Ce n'est pas parce que Lynx ou Links ne savent pas lire les images qu'il
ne faut pas les utiliser.

Et quid du javascript pour lynx/links ?

Ben c'est dans la phrase juste au dessus:

<<Ce n'est pas parce que le site doit fonctionner sans JS et sans
cookies qu'il faut s'en passer. Le fonctionnement sans ne doit être
qu'une alternative.>>

Le plupart des utilisateurs n'utilisent que la langue par défaut de l'OS
et s'il rajoutent une langue, elle est rarement mise par défaut.

C'est votre vision des choses. Ce n'est pas la mienne.

Ce n'est pas que ma vision des choses,ce sont aussi les réalités
statistiques sur les différents sites web dont je m'occupe, on
faitfacilement un recoupement entre la langue et l'adresse IP du
visiteur ( une fois qu'on abanni les utilisateurs AOL )

Il n'y a vraiment que pour ceux qui utilisent KDE en breton que tout ça
pose problème. En général, ils règlent comme second choix le français.

Non. Mon OS ne connait pas ma langue préférée et prend donc la langue par
défaut (anglais) - et c'est fait exprès,
alors que mon navigateur a une *liste* de langues avec français en premier.

C'est bien ce que je disais un peu avant dans mon messages, vous êtes un
utilisateur avancé et vous savez donc régler la langue de votre OS et
celle de votre navigateur.

Et quid du javascript pour lynx/links ?

Ben c'est dans la phrase juste au dessus:

<<Ce n'est pas parce que le site doit fonctionner sans JS et sans
cookies qu'il faut s'en passer. Le fonctionnement sans ne doit être
qu'une alternative.>>

Vous ne comprennez apparement pas: si vous implémentez votre gestion du
décalage horaire uniquement avec un appel à date en javascript, les
utilisateurs qui ne peuvent ou ne veulent pas utiliser javascript, ils
n'ont pas le droit de choisir leur fuseau horaire ?

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Bonsoir,

Je ne comprends pas vos jacquasseries, quand vous achetez une
application, il y a des prérequis matériels / logiciels auxquels vous vous
conformez pour l'utiliser. Pourquoi serait-ce différent dans le cadre d'une
application web ?
Imposez ou pas comme prérequis les cookies ou javascript c'est un choix
technique qui ne peut se généraliser. D'ailleurs des choix techniques vous
en faites, vous postulez bien que votre client dispose d'un écran permettant
au minimum un affichage en 800x600 et pas là même vous zappez allègrement
tous les utilisateurs de pocket pc et autres appareils mobiles, vous optez
pour un dev en xhtml par exemple mais il faut évidemment que les clients
suivent !!!

Bref les prérequis existent également en web, si vous désirez utiliser
un système de traçage, votre site sera indisponible aux utilisateurs ayant
désactivé les cookies un point c'est tout ! Idem pour le javascript, le
standard html utilisé et touti quanti !!

En aparté, j'ai bossé sur JScript, ECMA Script, ce sont des languages
relativement bien faits suffisamment standardisés pour produire du code
portable. Seuls les accès aux composants externes type XMLDOM, ou XMLHTTP
restent propriétaires. Avec eux d'ailleurs on sort largement du cadre de
l'amélioration ergonomique dans lequel vous semblez vouloir cantonner ce(s)
language(s). Presque tous les navigateurs récents supportent ces technos
(IE, Mozilla, FireFox, Opéra8, Netscape8, K-Meléon, Aol Browser, ... ), vous
feriez peut-être mieux de vous demander pourquoi, plutot que brandir des
principes de développement surannés, peut-être adaptés pour des sites, mais
aujourd'hui pensez-vous que c'est suffisant ?

--
Cléo