probleme de decalage horaire

Tu fais quoi d'un utilisateur qui ne peux pas l'activer ? Tu l'envoyes
dans /dev/null ?

As tu lu mes message avant de répondre ?
Je dis que ce n'est pas parce que javascript ne peut pas être utilisé
sur certaines plateformes qu'il faut le laisser tomber. On prévoit en
plus un cas ou il n'est pas activé mais on en fait pas le cas par défaut.

[SNIP] >

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 ?

Rien, d'ailleurs 90% des utilisateurs ne règlent pas leur OS parce
qu'ils ne savent pas le faire et que de toute façon c'est préconfiguré
quand ils achètent la machine.

[SNIP]

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.

Je crois que tu ne connais pas bien Javascript en fait. En respectant
quelques règles simples, on a un code tout à fait portable et
certainement plus que les feuilles de style.

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.

Je me lasse de le répéter, mais c'est pas parce que tu utilises

javascript que tu ne prévoit pas en plus d'autres solutions.

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

De toute façon, dans le milieu de l'info on se fout souvent de
l'utilisateur, la preuve vous n'arretez pas de me critiquer parce que je
dis qu'il faut améliorer le confort de l'utilisateur.

[SNIP]

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.

Et aussi pour les programmes ecrit pour le DOS sans doute. Sous prétexte
de rétro compatibilité ( c'est à la mode ces temps ci ), on ne fait plus
rien évoluer.

J'aimerais quand même te rappeler qu'au début de ton message tu parlede
l'accessibilité, des mal-voyants ... et là, tu parles d'HTML4 qui n'est
absolument pas compatible avec les navigateurs pour mal-voyants et très
loin des standards d'accessibilité. Pour moi, XHTML+CSS signifie séparer
efficacement le contenu et la forme.

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 ).

Donc pour toi, il faut avoir l'interface la plus pauvre possible et si
on a le temps^^^envie on rajoute de la convivialité.

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 !

Tu me fait un peu rire, au debut du message tu te soucies de
l'utilisateur et maintenant tu raisonne en pur développeur, le confort
de l'utilisateur ne serait que pure fioriture. Si les développeurs se
souciant un peu plus de l'ergonomie de leurs apllications, on
arreteraitpeut être d'entendre que l'utilisation d'un micro est compliquée.

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 pour le javascript, tu as noscript il me semble non ?

[SNIP]

À 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)

Tout cela apporte un confort d'utilisation aux utilisateurs novices ou
qui ne sont pas forcément familiarisés avec les arcanes de ces logiciels.

Tu me fais un peu penser quand même au dinos qui veulent à tout pris
rester sous VMS parce qu'on a rien fait de mieux depuis.


[SNIP]


Après la lecture de *l'intégralité* de ton message ( et oui, j'ai eu du
courage ), j'en conclu que nous avons deux visions diamétralements
opposées de l'informatique.

Lorsque je conçoit une application ( qu'elle soit pour le web ou
standard ), je pense avant tout à l'ergonomie et au confort de
l'utilisateur et ensuite je laisse des portes de sortie pour ceux qui ne
disposent pas de telle ou telle fonctionalité, tu penses avant tout
compatibilité et tu laisses tomber une bonne partie du confort utilisateur.

Chaque vision se défend mais je crois que nous n'arriverons pas à nous
mettre d'accord.

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

Je retiens donc : ce n'est pas _votre_ vision des choses, c'est la réalité
mais basée sur _vos_ sites web.

Amusant.

faitfacilement un recoupement entre la langue et l'adresse IP du
visiteur ( une fois qu'on abanni les utilisateurs AOL )

Ah d'accord. Effectivement si vous virez tous ceux qui ne vous plaisent
pas (AOL, NOOS aussi nous, ils passent par un proxy, tout ceux qui
refusent le javascript, etc... etc...) ca doit simplifier la tache.
Mais dites, au final, il reste des gens sur vos sites ?

D'autre part, il n'y a pas de moyen fiable à 100% d'obtenir le pays à
partir d'une IP, sans compter qu'il n'y a pas forcément de corrélation
entre pays et langue (un étranger qui vit en France, peut préférer voir
les sites webs en anglais).

Bref, vos statistiques me paraissent pour le moins biaisées dans leur
calcul et leur interprétation.

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 on en revient à ce que je disais au début: la configuration correcte
de son navigateur, et notamment de ses préférences linguistiques, ne fait
pas partie des choses les mieux réparties. C'est comme ca, il faut
éduquer les gens.
Mais d'un autre côté il y a *très* peu de sites web qui utilisent la
négociation de contenu correctement: en général les contenus dans des
langues différentes sont accessibles à des URLs différentes, ce qui est
l'exact opposé de la négociation de contenu.

--
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>

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 ?

Quand on fait bien les choses, les prérequis sont très bas, donc
n'excluent quasimment personne.
Alors que baser un truc sur javascript, cela élimine tout un tas de cas
de figure, donc c'est loin d'être personne.

Imposez ou pas comme prérequis les cookies ou javascript c'est un choix
technique qui ne peut se généraliser.

S'il manque un que dans votre phrase, je ne suis absolument pas d'accord.

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

Les bons sites n'ont pas de ce genre de prérequis.

et pas là même vous zappez
allègrement tous les utilisateurs de pocket pc et autres appareils
mobiles,

Non, car pour ceux là il faut fournir un contenu différent (WML vs
(X)HTML) donc cela n'a rien à voir.

vous optez pour un dev en xhtml par exemple mais il faut
évidemment que les clients suivent !!!

Pas de problèmes en pratique, même s'il faut parfois faire du text/html
comme content-type.

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 !

Non, car on peut faire un ``tracage'' (j'imagine que vous parlez de
sessions), sans cookies.
Et si on veut vraiment utiliser les cookies et faire les choses
proprement, on implémente un fallback.

En général les gens l'ont bien compris: il y a quelques années, par
exemple, il était impossible d'aller sur le site de la fnac si vous
désactivitiez les cookies, même juste pour regarder, sans acheter.
C'est comme si on vous refusait l'entrée d'un magasin parce que votre
porte-feuille est vide.
Cela a été corrigé, évidemment.

En aparté, j'ai bossé sur JScript, ECMA Script, ce sont des languages
relativement bien faits suffisamment standardisés pour produire du code
portable.

C'est loin d'être ``standardisé'', il y a plus de 10 versions
différentes...

Seuls les accès aux composants externes type XMLDOM, ou
XMLHTTP restent propriétaires.

Non.

--
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>

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 ?

C'est vous qui êtes borné, que veut dire la seconde phrase selon vous ?

Je vais vous faire un cours de français si vous voulez.
"le fonctionnement sans": comprendre le fonctionnement de l'application
sans javascript
"ne doit être qu'une alternative": le fonctionnement par défaut se fait
donc avec avascript avec une autre possibilité pour ceux qui n'ont pas
javascript ou au cas ou le javascript détecterait mal les paramètres.

C'est le fonctonnement normal pour n'importe quelle application,
celle-ci essaie de déterminer les paramètres mais laisse à l'utilisateur
une possibilité de configurer l'application.

Je m'apperçoit qu'il est inutile que je continue plus loin le débat avec
des gens d'aussi mauvaise fois et qui détiennent de toute façon la
vérité absolue.

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

Je retiens donc : ce n'est pas _votre_ vision des choses, c'est la réalité
mais basée sur _vos_ sites web.

Amusant.

Et bien, si c'était *ma* vision des choses, ce serait juste une opinion
que je me serai faite à priori, là c'est une opinion que je me suis
faite à partir de faits statistiques.


Par contre, j'ai bien l'impression que votre vision ne repose sur aucun
fait concret, vous balancer des idées et des vérités sas jamais décrire
la démarche qui vous mène à ces conclusions.

faitfacilement un recoupement entre la langue et l'adresse IP du
visiteur ( une fois qu'on abanni les utilisateurs AOL )

Ah d'accord. Effectivement si vous virez tous ceux qui ne vous plaisent
pas (AOL, NOOS aussi nous, ils passent par un proxy, tout ceux qui
refusent le javascript, etc... etc...) ca doit simplifier la tache.
Mais dites, au final, il reste des gens sur vos sites ?

Vous êtes vraiment d'une mauvaise fois à en faire rougir certains
politiciens.

Je n'élimine pas ceux qui passent par un proxy, j'élimine ceux d'AOL car
ils faussent les stats ( certains AOLien paraissent venir des Etats Unis
alors qu'ils sont en France ), je n'élimine pas non plus ceux qui
utilisent javascript puisque depuis le début de ce fil de discussion, je
suis en train d'expliquer qu'il faut utiliser javascript pour le confort
et l'ergonomie et qu'il faut laisser une possibilité de configuration.

D'autre part, il n'y a pas de moyen fiable à 100% d'obtenir le pays à
partir d'une IP, sans compter qu'il n'y a pas forcément de corrélation
entre pays et langue (un étranger qui vit en France, peut préférer voir
les sites webs en anglais).

Bref, vos statistiques me paraissent pour le moins biaisées dans leur
calcul et leur interprétation.

C'est ça les statistiques, on lisse les données pour éliminer du panel
les cas marginaux et ceux qui ne peuvent rien apporter.

Mais en conjuguant les paramètres poue éviter de trop biaiser les
résultats on arrive à s'en sortir.

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 on en revient à ce que je disais au début: la configuration correcte
de son navigateur, et notamment de ses préférences linguistiques, ne fait
pas partie des choses les mieux réparties. C'est comme ca, il faut
éduquer les gens.

J'ai quand même l'impression que vous prenez les utilisateurs pour des
guignols qui s'amusent à trifouiller les paramètres de leur machine sans
savoir ce qu'il font.

Mais d'un autre côté il y a *très* peu de sites web qui utilisent la
négociation de contenu correctement: en général les contenus dans des
langues différentes sont accessibles à des URLs différentes, ce qui est
l'exact opposé de la négociation de contenu.

De toute façon, on avait bien compris, il n'y a que vous à savoir le
faire de la négociation de contenu.

Personellement, je comprend dans négociation de contenu que le *serveur
web donne à l'utilisateur le contenu approprié* comme le fait Apache,
que ce soit à une URL donnée ou qu'il redirige vers une autre, la
méthode importe peu, c'est le résultat qui compte.

Je tiens quand même à vous préciser que mes clients sont très satisfaits
de mais services, notament en terme d'ergonomie des applications.

J'aimerais quand même te rappeler qu'au début de ton message tu parlede
l'accessibilité, des mal-voyants ... et là, tu parles d'HTML4 qui n'est
absolument pas compatible avec les navigateurs pour mal-voyants et très
loin des standards d'accessibilité. Pour moi, XHTML+CSS signifie séparer
efficacement le contenu et la forme.

Manque de bol, cette phrase prouve que vous avez les idées embrouillées:
on peut *aussi* bien séparer contenu et forme en HTML4 qu'en XHTML.
L'usage d'un de ses deux langages pour décrire une page web, n'a rien à
voir avec les problèmes d'accessibilité ou de sémantique. Ce sont des
considérations orthogonales.

Allez répéter votre paragraphe sur fciwa, vous verrez, vous allez vous
faire épingler !

--
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>

Bonjour, (si, si)

MODE CALME = On
Bien comprendre avant de lire la suite que je ne souhaite pas lancer le
flame war, je rappelle simplement la position que je répète depuis des
années. Si quelqu'un a une question technique concernant ce que j'y dit
(par exemple, sur le fonctionnement des sessions) je suis tout à fait prêt
à y répondre. Tout le reste sera ignoré, je n'ai vraiment pas le temps de
jouer à l'évangeliste, et je ne suis pas payé pour.

Je ne comprends pas vos jacquasseries,
C'est bien ce qu'on vous reproche :-)

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 ?

Parce qu'il est ****DEBILE**** *d'imposer* des pré-requis QUAND ON PEUT NE
PAS LES IMPOSER ET FAIRE LA MEME CHOSE EN FAISANT ***MOINS*** de
développements. Vous pigez ça ? MOINS DE DEV pour PAREIL avec en prime
PLUS de portabilité quand on n'impose pas les techno clientes.

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 !

MDR :-)) Mais non ! Allez apprendre comment fonctionne une session au lieu
de dire des conneries plus grosses que vous. [nb très sérieuse : je veux
bien expliquer pourquoi ceci est une erreur techniquement]

En aparté, j'ai bossé sur JScript, ECMA Script, ce sont des languages
relativement bien faits suffisamment standardisés pour produire du code
portable.

C'est pas le code qui n'est pas portable, ce sont les variantes locales de
tous les interpréteurs qui ne l'implémentent pas de la même manière et qui
ne l'implémenteront *****JAMAIS***** de la même manière (ne serait-ce qu'à
cause de toutes les versions déjà dans la nature). Quand vous effectuez un
traitement côté SERVEUR, vous êtes sûr que ce traitement et le MEME pour
TOUT LE MONDE, ce qui ne sera ****JAMAIS**** le cas avec un traitement
client.

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,

<LOOP : REPETER EN BOUCLE JUSQU'A COMPREHENSION>
Parce que c'est utile pour le confort de l'utilisateur. On ne vous dit pas
de **ne pas utiliser** les techno clientes, on vous dit de NE PAS LES
IMPOSER (i.e. si vous préférez, qu'elles ne soient PAS un prérequis, vu
qu'on peut TRES BIEN s'en passer). Elles doivent être un PLUS et non pas
une BARRIERE.
<END LOOP>

principes de développement surannés, peut-être adaptés pour des sites, mais
aujourd'hui pensez-vous que c'est suffisant ?

Largement pour un fonctionnement normal, même si c'est du coup en mode
dégradé par rapport à l'application.

Donc en ce qui me concerne en tant que contributeur de ce forum, c'est
EOT, on ne fait pas boire un âne qui n'a pas soif.

En tant que *modérateur* maintenant de ce forum, je pense qu'il va
bientôt falloir positionner le fu2 qui va bien s'il y a encore des
contributeurs qui souhaitent "débattre", en ce qui me concerne c'est
/dev/null

JG

Patrick Mevzek wrote:

Mais d'un autre côté il y a *très* peu de sites web qui utilisent la
négociation de contenu correctement: en général les contenus dans des
langues différentes sont accessibles à des URLs différentes, ce qui est
l'exact opposé de la négociation de contenu.

Je pense qu'il faudrait faire comme cela. je ne vois pas pourquoi une
même URL pourrait pointer vers deux langues.

--
Guillaume.

ftc wrote:

As tu lu mes message avant de répondre ?

Oui.

Je dis que ce n'est pas parce que javascript ne peut pas être utilisé
sur certaines plateformes qu'il faut le laisser tomber. On prévoit en
plus un cas ou il n'est pas activé mais on en fait pas le cas par défaut.

Je dit que je pense l'inverse. Il est plus simple de faire par defaut et
d'ajouter des options que de prevoir tous les cas de ratage possible.

Rien, d'ailleurs 90% des utilisateurs ne règlent pas leur OS parce
qu'ils ne savent pas le faire et que de toute façon c'est préconfiguré
quand ils achètent la machine.

Ok.

Je crois que tu ne connais pas bien Javascript en fait.

Je l'admet.

En respectant
quelques règles simples, on a un code tout à fait portable et
certainement plus que les feuilles de style.

Les feuilles de styles ont l'aventage que se degrader en deformant
seulement la presentation. Votre javascript peut se degrader d'une façon
moins sympatique.

Je me lasse de le répéter, mais c'est pas parce que tu utilises
javascript que tu ne prévoit pas en plus d'autres solutions.

Comme dit plus haut je pense qu'il faut voir differament.

De toute façon, dans le milieu de l'info on se fout souvent de
l'utilisateur, la preuve vous n'arretez pas de me critiquer parce que je
dis qu'il faut améliorer le confort de l'utilisateur.

En quoi le confort passe-t-il par du javascript ?

Et aussi pour les programmes ecrit pour le DOS sans doute. Sous prétexte
de rétro compatibilité ( c'est à la mode ces temps ci ), on ne fait plus
rien évoluer.

La difference avec le web c'est que l'on ne maitrise pas la façon dont
le client viendra récuperer le contenu. Alors que l'on peux toujours
demander gentiement à une personne qui fait la demarche d'installer un
logiciel de mettre à jour ces librairies.

Maitenant c'est aussi à cause de raisonement sur l'évolution comme
ceux-ci sur l'on obtient des cas comme celui que j'ai vu chez moi il y a
2 mois, un membre de ma famille à du changer son vieux ordinateur car un
des logiciel utilisé à son travail necessitait de passer de windows 98 à
windows XP pour une seule raison : le toolkit graphite utilisé avait
changer (Pour un soft de transmission de donnée !!!). C'est beau
l'évolution.

J'aimerais quand même te rappeler qu'au début de ton message tu parlede
l'accessibilité, des mal-voyants ... et là, tu parles d'HTML4 qui n'est
absolument pas compatible avec les navigateurs pour mal-voyants et très
loin des standards d'accessibilité.

Je pense que non, à condition de bien développer son html 4. Il est trés
proche du XHTML à la difference de syntaxe SGML/XML.

Pour moi, XHTML+CSS signifie séparer
efficacement le contenu et la forme.

Le html 4 permet aussi cela.

Donc pour toi, il faut avoir l'interface la plus pauvre possible et si
on a le temps^^^envie on rajoute de la convivialité.

Non, juste que la conviviabilité ne doit pas imposer certaines choses.
je reprend mone exemple plus haut, je suis certain que le toolkit de
windows XP est super beau, mais cela presente-t-il un interet considerable.

http://openweb.eu.org/, trés conviviable, bonne dégradation, trés
accessible, aucun javascript.

Trouve moi un exemple de javascript qui améliore tellement la
conviviabilité qu'il est impossible de s'en passer.

Tu me fait un peu rire, au debut du message tu te soucies de
l'utilisateur et maintenant tu raisonne en pur développeur, le confort
de l'utilisateur ne serait que pure fioriture.

Je parlais du confort-fioriture. Celui qui n'apporte pas grand chose
(comme le JS qui verifie le contenu de ton formulaire).

Si les développeurs se
souciant un peu plus de l'ergonomie de leurs apllications, on
arreteraitpeut être d'entendre que l'utilisation d'un micro est compliquée.

Je te suis dans ce sens, c'est pour cela que je ne met pas de javascript
dans les partie vitale de mes applications pour que celle-ci soit
ergonomiques pour que chaques utilisateur puisse l'utilisé sans devoir
s'adapter.

Et pour le javascript, tu as noscript il me semble non ?

Comme si tu fais bien ton dev tu ne fais que des appeles aux script dans
l'entete :

<script type="text/javascript" src="..;"></script>, je ne vois pas ce
que peux changer ta balise noscript dans l'entete.

Tout cela apporte un confort d'utilisation aux utilisateurs novices ou
qui ne sont pas forcément familiarisés avec les arcanes de ces logiciels.

Avoir une interface qui ressemble à un cockpit de mirage, cela apporte
un confort d'utilisation ? Un traitement de texte cela devrait traiter
du texte, pas faire la vaisselle.

Tu me fais un peu penser quand même au dinos qui veulent à tout pris
rester sous VMS parce qu'on a rien fait de mieux depuis.

VMS, connais pas. (j'ai pensé à Vindow Media Senter, mais c'est aps ça...)

Après la lecture de *l'intégralité* de ton message ( et oui, j'ai eu du
courage ),

Bravo ;o)

j'en conclu que nous avons deux visions diamétralements
opposées de l'informatique.

Pas forcement. Notre but est de faire du "qui marche" et du
"ergonomique". on à juste pas la même vision de la façon de le faire.

Lorsque je conçoit une application ( qu'elle soit pour le web ou
standard ), je pense avant tout à l'ergonomie et au confort de
l'utilisateur et ensuite je laisse des portes de sortie pour ceux qui ne
disposent pas de telle ou telle fonctionalité, tu penses avant tout
compatibilité et tu laisses tomber une bonne partie du confort
utilisateur.

Tu preferes que l'on te dise : Désolé, cela ne fonctionne pas comme ceci
mais vous pouvez suivre la procédure suivante, ou que cela fonctionne du
premier coup ? Moi c'est la deuxieme solution.

Chaque vision se défend mais je crois que nous n'arriverons pas à nous
mettre d'accord.

Si on était tous en accord, ce ne serait pas interessant. (Mais des fois
cela éviterais de bonne prise de tete ;o)

--
Guillaume.

cleo wrote:

Bonsoir,

Bonjour.

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 ?

Car c'est dans la philosophie du 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

Moi pas. Je vis sur un ecran en 640*480 chez moi depuis que l'ancien m'a
lacher et mon modeste salaire d'étudiant (chercher l'erreur) ne me
permet pas de changer.

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 !!!

Je fais du HTML.

En aparté, j'ai bossé sur JScript, ECMA Script, ce sont des languages
relativement bien faits suffisamment standardisés pour produire du code
portable.

Portable même sur des plateforme qui ne lisent pas ce genre de code ?

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).

Tu utilises ces langages pour quoi d'autres ? Faire des applications
(dans le vrai sens du terme applications, dynamique, click, ...).

Dans ce cas là, tu fais ce que tu veux sur un intranet sur lequel tu
maitrises les utilisateurs et leur materiel. Dans le cadre du web, ce
genre d'application n'a pas à être.

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 ?

Trés suffisant. hormis dans le cadre *d'application* vu plus haut, je
n'ai jamais ressentit le moindre besoin de faire plus que ce que le html
ne me permet.

--
Guillaume.