Reprise du message précédent :
Bien sur qu'il y a des cas où il faut que le site soit lisible sans JS, mais de là à fustiger parce qu'un mec code un site sur on ne sait pas quoi avec des fonctionnalités pas JSless compliant qui ont peut être obligatoirement besoin de JS ... En général faut au moins qu'un minimum soit accessible sans JS, mais de là à chercher un moyen de substituer la moindre fonctionnalité comme le drag&drop sans JS    
 
Ouais j'pense qu'il faudrait que tout le monde se mette au braille, parce que les non voyants ils peuvent pas lire les lettres  
On disait la même chose de l'informatique au départ "c'est naze les non voyants peuvent pas en profiter ..." On trouvera bien un moyen

De là à empêcher les non-voyants d'y accéder alors que le moyen et les solutions existent déjà
Intégrer accessible et coder non-obstrusif (entre autres) facilite la vie aux non-voyants mais aussi à plein d'autres types de handicaps qui représentent une bien plus large population (les vieux pétés de thune, les malvoyants, etc) et y a des chances que ça améliore l'ergonomie pour tout le monde, même si c'est pas forcément lié.
 
Et pour revenir sur une idée reçue : la plupart des non-voyants surfent avec Javascript activé. Ça n'empêche pas que ce dit NazzTazz est parfaitement juste et à faire.

Ah oui sur une grosse appli c'est un tueur ça
 
D'où l'intérêt d'utiliser un framework JS qui fournit une méthode unifiée (vu qu'autrement t'as à gérer 2 appels différents, pour MSIE et pour W3C events)

Ça dépend de ta définition de beaucoup, mais il y en a suffisamment (entre les utilisateurs au JS désactivé ou indisponible et ceux chez qui le JS ne fonctionne ou ne peut fonctionner que partiellement pour des raisons de handicaps)

En même temps, ce que tu penses on a pu déterminer que c'était pas d'un intérêt faramineux…

 
encore une fois, essaye juste d'afficher un site avec un lecteur d'écran , et tu comprendras que le tout js, c'est bien gentil , mais que ça peut atteindre des limites
 
tu t'en fous pour un blog perso, pour un site de sport , ...  
 
mais pour un site de vente ,  ou pour un site d'entreprise, c'est différent

d'ailleurs cdiscount à une version pour épilleptique
 

je suis bien d'accord que ça pose problème, mais je pense que c'est aux lecteurs d'écrans de s'adapter à l'évolution technologique

Y a de plus en plus de JS dans les sites et on ne peut pas toujours proposer une versions sans JS qui soit pratique à utiliser ! D'ailleurs Facebook sans JS ça marche pas / très mal !

 
Si tu considères facebook comme un bon exemple de ce qu'il faut faire sur le web, je crains que tu ne sois sérieusement engagé dans la mauvaise direction.

marrant , je te parle de site pro , tu me répond facebook  
 
nan, mais continue a faire de la merde en te disant que totu le monde est mobile et que tout le monde va bien ( ce qui est l'avenir avec le viellissement des utilsiateurs d'internet )

Perso, même sans parler de lecteurs d'écran, je trouve qu'un site conçu pour être dégradable est beaucoup plus maintenable et stable qu'un sac de Javascript.

Déja, si t'as un bug dans le JS, si le site est pas dégradable il peut facilement être hors-service.

Argument 2 : les moteurs de recherche n'utilisent pas JS.

Argument 3, dans la lignée du 2 : le HTML est un format simple et normalisé et donc beaucoup plus facilement utilisable par des programmes extérieurs : navigateurs (clic molette, prépopulage de formulaires, bookmarks, etc), robots, scripts greasemonkey etc.

De toute façon si tu sais coder la version JSLess est nécessairement "moins soignée", puisque le but du JS c'est d'améliorer l'expérience de l'utilisateur

Mandelbug de merde

C'est l'envoi d'un header Content-Type très classique qui stoppe l'appli. Parfois.

Edit : arf non c'est plus compliqué encore, je continue les recherches
Oui oui, je sais que vous vous en branlez, mais en parler m'aide à réfléchir

What the… I don't even…

Wat ?

Bon, là je m'en remet aux experts si ça vous dit qqch : apparemment la page est bien générée nickel, le script n'est jamais stoppé, mais Apache refuse d'envoyer la réponse et ferme la connection.

Quand je fais un apache_response_headers() j'ai

Et pour headers_list()

Une merde avec Gzip ? (edit : oui, je vire Deflate, ça marche.)

Parce que FB c'est pas un site pro peut-être ?    

non
mais alors clairement non
 
il est fait par des professionnels, c'est sur, mais c'est un site loisir. C'est aps un outil de travail dont dépendent des gens pour commander ou pour travailler

OK j'avais pas la même définition d'un site pro alors.

Question AJAX, à propos de la création locale des objets XMLHttpRequest, je lis dans jQuery:

xhr:function(){
  return window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP" ) : new XMLHttpRequest();
}

qui est un peu différent de la recette à laquelle j'étais habituée qui ressemble plutôt à ceci:

_createXMLHttpRequest: function() {
  try { return new ActiveXObject("Msxml2.XMLHTTP" );    } catch(e) {}
  try { return new ActiveXObject("Microsoft.XMLHTTP" ); } catch(e) {}
  try { return new XMLHttpRequest();                    } catch(e) {}
  _error("Could not create XMLHttpRequest on this browser" );
  return null;
}

Qu'est-ce qui est le mieux et pourquoi? Parce que dans mon expérience, le second code semble plus tolérant que le premier à la configuration d'IE.

On a mis en ligne une version du site récemment et après examen, on avait le second code, on passe au premier, et ça ne marche plus chez certains users, d'où mon interrogation

xhr:function(){
  return window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP" ) : new XMLHttpRequest();
}

_createXMLHttpRequest: function() {
  try { return new ActiveXObject("Msxml2.XMLHTTP" );    } catch(e) {}
  try { return new ActiveXObject("Microsoft.XMLHTTP" ); } catch(e) {}
  try { return new XMLHttpRequest();                    } catch(e) {}
  _error("Could not create XMLHttpRequest on this browser" );
  return null;
}

Un début de réponse ici : http://blogs.msdn.com/xmlteam/arch [...] lorer.aspx ?
 
Et un autre élément de réponse là : http://msdn.microsoft.com/en-us/li [...] S.85).aspx
 
J'aurais tendance à dire que jQuery n'utilise pas forcément la meilleure des solutions d'après l'extrait de code que tu as posté

Comme site pro qui correspond à tes idées, il y a voyage-scnf.fr

En l'occurence celui-là il est pro dans les 2 sens sus-dits
 
Comme quoi, il manque un critère

Merci
 
Le premier lien explique déjà très bien la situation et la conclusion résume très bien le problème:  

 
Si j'avais su ça plus tôt...

symfony  , je veux faire une authentification et un peu de traitement lors de l'identification

j'ai donc suivi avec le doigt la page d'aide de sfguardauth

sauf que checkpassword n'est jamais appelé . A la place, la vérif du login / mot de passe se fait dans sfGuardValidatorUser->doClean()
et myLDAP.class.php  , situé dans apps/frontend/lib/  n'est jamais chargé

edit : j'utilise symfony 1.4

 
il manque le Content-Length, "obligatoire" quand t'es en gzip

Tu peux poser

dans PluginsfGuardUser::checkPassword() ? (c'est ici que le callback est appelé, si tu veux débugger)
(c'est dans /plugins/sfDoctreinGuardPlugin/lib/model/doctrine/PluginsfGuardUser.class.php )

Merci, je testerais ça quand ça recommencera à merder, j'ai rien fait et ça marche à nouveau

edit : ça remarche plus JEdit+FTP m'a dit qu'un fichier était bien enregistré alors qu'il ne l'était pas, vive JEdit+FTP

ça le fait que sur certains browsers si je me souviens bien; et t'as aussi les proxy qui foutent leur merde - tu forces pas le gzip j'espere, tu verifies qu'il est dans l'accept tout de meme ?

This.

cf edit
Sinon je sais pas, c'est pas moi qui ait paramètré ça.

Mais vu le "AddOutputFilterByType DEFLATE text/html" dans httpd.conf, je pense qu'il ne vérifie rien. Mais c'est un autre pb

reddit : ah, ya aussi le problème d'un error handler PHP qui n'est jamais appelé, mais que quand on le vire ça marche Sauf que j'en ai besoin of course.

redddit: marche pas mieux avec Content-Length.

vire le gzip pour voir
edit: Content-Length... du contenu zippé of course

ça commence a me courir

je repars d'un projet vierge ( de toute façon pour l'instant, je joue juste avec )
je génère le projet, puis je génère une app "frontend" et je tombe la dessus

Avec Symfony il faut passer par là

edit : t'as vidé ton /cache ouais ?

edit² : ça marche ton pb de tout à l'heure ?

 
je vais essayer.
 

1/ appli toute neuve , dans un dossier à part  
2/ j'ai essayé de virer le lugin pour le remettre. A priori c'etait pas une bonne idée  

Vu que c'est du tout neuf, est-ce que tu pourrais me lister les commandes que tu as lancées ? (1 pour le projet, 1 pour l'app ?)

j'ai effacé le tout, recrée dans un autre projet et ça marche
 
je pense que je suis surtout bien claqué et que je n'ai plus les yeux en face des trous. Vais faire un peu de rangement plutôt

ouais les aveugles n'ont pas droit aux loisirs  

Fait chier, la seule solution reste donc de patcher jQuery à moins de trouver une lib qui utilise une syntaxe similaire

En même temps jQuery c'est de la merde

Ouais, si on a déjà ce genre d'erreur à si bas niveau, je me pose des questions sur le reste
 
Pourtant j'ai bien aimé développer avec