Bonjour,

Je me pose quelques questions à propos du javascript.

Pour commencer, pour quelle raison les internautes le désactivent-t-ils ?
Est-ce vrai que les moteurs de recherche ne suivent pas les liens javascript ?
Les navigateurs vocaux (et autre système altérnatif au bon vieux navigateur) vont-ils intégrer le javascript dans un futur plus ou moins lointain ?

Comment se passer de toutes les petites fonctionnalités sexy ou très ergonomiques et autres utilités du javascript ?
Comment procédez vous ? Vous prévoyez une alternative non javascript pour chaque script que vous réalisez ? Vous prévoyez une page alternative (détéction si le javascript est actif ou non et redirection en fonction ? Comment ?) ? Ou est-ce que vous supprimer directement tout javascript pour ne pas avoir à vous prendre la tête.

Moi, je dois vous avouez que, plus je m'en sers, plus je le trouve utile... J'amerais bien qu'il soit actif partout.

Bonjour Nissone,

Les moteurs ne suivent en général pas les liens en JavaScript. Seul Google a montré qu'il arrivait à suivre des liens "simples", mais les autres moteurs sont aveugles en ce qui concerne JavaScript.

Certains "power-users" (ou prétendus tels) désactivent JavaScript pour augmenter la sécurité de leur navigateur. Ce faisant ils s'interdisent aussi l'affichage des Google Adsense ou d'autres publicités.
La raison primordiale est je pense de masquer les Google Adsense. Je n'en vois pas d'autre qui tienne la route.

Dan

Les navigateurs oraux sont très généralement de simples lecteurs d'écran avec parfois un accès direct à l'API du navigateur. Si le navigateur sait gérer le javascript (et il le sait vu que c'est quasiment tout le temps MSIE derrière), alors ton navigateur oral gère le javascript.
Le seul point délicat c'est qu'il ne détectera les changements dans la page que suite à un clic ou une action utilisateur. Pas la peine donc de penser à déclencher des choses au survol ou avec des timers complexes.
De ce coté là tu t'en fais pour rien à priori. Même les pda devraient savoir faire du javascript



Javascript est très pratique pour de l'aide utilisateur ou de la présentation. Il permet de rajouter des effets, du comportement. Par contre il est assez rare qu'il soit nécessaire d'utiliser javascript pour proposer une fonctionnalité essentielle.
Pour parler concrêtement, en bas de ce forum c'est un lien "réponse rapide". C'est du javascript, s'il n'est pas là je suppose que la réponse rapide est toujours dépliée. Je perd l'aide utilisateur mais je ne perd aucune fonctionnalité. A l'autre bord certains forums utilisent le javascript pour marquer les messages nouveaux ou anciens. Sans javascript on perd quelque chose d'important pour l'utilisateur, mais on ne perd qu'une aide, le forum reste utilisable.
Tant que tu reste dans la philosophie "javascript est une surcouche pour aider l'utilisateur" et pas "javascript remplace HTML", tu ne devrais pas avoir à trop faire de boulot pour que tout soit accessible sans.

Quant aux raisons de la désactivation : ça fait sauter beaucoup de pub, mais aussi tous les gadgets et scripts inutiles (les bidules qui suivent la souris, les timers qui font des arbres de noel....). Pas mal de geeks se concentrent sur le contenu et acceptent de se passer de pas mal d'aide javascript si ça leur assure de louper aussi tous les gadgets agacants.
Sinon il reste des gens qui ont désactivé le js par erreur ou en lisant un article paranoiaque et qui ne savent pas comment le désactiver. Il y en avait beaucoup il y a un ou deux ans. Maintenant ça devient assez rare, c'est moins à la mode de désactiver js.


Javascript c'est très bien. Tant que tu ne l'utilises pas pour remplacer le navigateur ou le HTML, ça devrait poser très peu de problèmes.

Pour ma part je fait en sorte que l'on puisse utiliser le site sans javascript et que donc cela ne gène pas la navigation.

Par contre dans le back-office j'y ait recourt très souvent afin de rendre les actions répétitives plus rapides (via AJAX) et je laisse un message d'avertissement pour les administrateurs qui n'auraient pas javascript d'activé.

PS:



Bin non, il reste replié, on perd donc une fonctionnalité, mais il serai possible de faire en sorte qu'il reste déplié sans javascript.

Salut
Faisant partie des "désactiveurs de JS", je réponds
Si l'on part du principe que le Javscript est un langage client ne servant qu'à ajouter une petite baleur ajoutée non indispensable à une page, et partant du principe que le client peut le désactiver, alors je me dis:
1) je visite un site bien conçu: le javascript n'y est pas indispensable, je ne perds rien
2) le site est mal conçu: je ne perds rien non plus. Si un site est mal foutu, il ne vaut pas la peine d'être lu (je suis très radical je sais). Et souvent je m'évite par la même occasion les fameux "suiveurs de souris" horripilants, ainsi que les prompts "entrez votre nom ici pour que je sache qui vient sur mon site" qui m'agacent parfaitement (xavfun, si tu m'entends )

D'autres raisons: essaie de visualiser correctement, avec javascript activé, un site hébergé sur Lycos, ou autres hébergeurs gratuits qui mettent de la pub partout. C'est illisible (Lycos reste le meilleur/pire exemple).
Sans javascript, un site hébergé sur Lycos (via les formules gratuites bien sûr) est tout à fait lisible

C'est vrai. Sauf effectivement Google qui en reconnaît certains. Mais aucun ne lit de scripts complets.

Fonctionnalités sexy ou très ergonomiques B) -> de quelles fonctionnalités en particulier parles-tu ? Peux-tu un peu développer ce point STP ?
En tous cas, ma manière de procéder est la suivante: je ne ressens que très rarement le besoin d'user de javascript. Et lorsque l'occasion se présente, je m'en sers tel que son utilisation le veut, i.e que sans javascript, tout reste lisible/cliquable etc..

Pas d'accord avec le chef (non, pas le ceinturon :o). Enfin, en ce qui me concerne en tous cas. Non que j'apprécie particulièrement de cliquer sur les Adsense (les sites qui y font leur pub sont rarements intéressants je trouve des fois ils sont carréments hors-sujet), mais Adsense fait justement partie de ce type de format de pub qui ne gêne pas la lecture d'une page..


Disons aussi qu'il y a très longtemps, çà servait surtout à s'épargner les pop-up. Maintenant, même Explorer peut les bloquer ! et sans toolbar !! (Quelle révolution )


C'est clair que sur des backs-office, voire des intranets (où souvent l'on a affaire à des visiteurs qui ne savent de toutes façons pas désactiver le JS -ce n'est pas péjoratif-), le JS c'est génial. Sans quoi, je le redis, je m'en sers vraiment rarement

edit: Pour utiliser la réponse rapide sans Javascript, cochez la case adéquate dans la partie "Vos Contrôles" en haut à droite

Dudu, l'un des arguments que tu avances, pour désactiver le javascript, ce sont les pubs intrusives.
Bien sûr, en tant qu'internaute, je te comprend de vouloir éviter tout ces désagréments... Mais j'en reviens à ma déconvenue d'il y a quelques temps : la "disparition" des pop-up me désespérait, moi qui les trouve si pratiques quand il ne s'agit pas d'agresser le visiteur avec de la pub ou autre hors-sujet.

Tu avances toi-même comme argument qu'un site mal foutu ne vaut pas le temps qu'on s'y attarde ... ben c'est justement ce que j'ai tendance à penser des sites pleins de pubs intrusives et ce n'est pas parce que certains sites n'ont aucun respect pour leurs visiteurs que je me priverais de javascript ; je préfère me priver de leur site.

Tu me demandes de préciser les fonctionnalités dont je trouverais dommage de devoir se passer (C'est vrai que je passe vite fait sur la question) ... Toi-même, un peu plus loin, tu abondes dans le sens de Country à propos de l'utilité du js dans le back-office ou les intranets ...Je ne serais pas étonnée d'y retrouver ce qui me plaît tant dans le javascript !
En vrac, vite fait : le fait de déplier/replier des blocs (si telle case est cochée, un espace avec des questions s'y raccrochant apparaît), l'apparition de petites bulles d'aide contextuelles, un menu déroulant avec les sous-rubriques, des petites fonctions de calculs ou de comportement automatique en fonction de la saisie...
Je suis sûre que j'en oublie plein !
Le javascript me plaît d'autant plus que je découvre au fur et à mesure toutes les manipulations qu'il peut permettre avec les feuilles de style !!! (Où le style n'apporte pas qu'un look mais aussi une signification, un statut qui a changé (que se soit par une couleur, une bordure, une image de font, etc.)


Si le développeur "perd" la possibilité du javascript parce que les pubs sont trop intrusives ... les pubs trouveront toujours un moyen d'être intrusives ! Il y a un an, je devait probablement aborder le même problème à propos des pop-up !
Dans mon idéal de développeur je voudrais que les gens fassent plutôt le choix de fuir les sites pénibles plutôt que de désactiver une fonction (C'est comme si je retirais mon auto-radio de ma voiture parce que *** passe 10 minutes de pub toutes les trois chansons ! Et les infos-route en temps réel ?! Et la station de musique cubaine que je n'aurais pas pensé à écouter autrement ?! Bon j'arrête.)

Maintenant, s'il faut faire du "javascriptless" parce que les lecteurs vocaux ne savent pas les suivrent ... Bon, je veux bien faire un effort, mais là encore mon idéal de développeur à son idée : que les navigateurs vocaux intéressent suffisement de monde pour qu'on y mette les moyens de les mettre au niveau de n'importe quel navigateur (standard).
Parce que je n'aime pas nivelé par le bas.

Quand aux moteurs, j'ai moi-même posé la question parce que, il ne faut pas être hypocrite, bien sûr que ça m'intéresse, mais je ne souhaite pas non plus devenir "esclave" de mon référencement. Je développe pour mon visiteur et non pas pour Google.

En tout cas, je vous remercie de m'aider à faire avancer ma réflection sur la question et de m'avoir aidé à faire le constat des limites du javascript (face aux outils comme face aux internautes).

Aller ! Soyez gentils ! Dites-moi que d'ici 6 moi la désactivation du javascript ne sera plus qu'une vieille mode ringarde... Hein ?!

Houla, tu m'as l'air bien remontée (je vais me prendre un méchant coup de ceinturon)

Je réponds dans l'ordre:
- le problème des pubs est UN des arguments que j'avance. Mais en aucun cas ce ne sera pour moi l'argument principal. Même un gif animé clignotant à 200 à l'heure ne me gêne pas dans ma lecture (l'intention du webmaster qui l'a mis me gêne, par contre mais c'est un autre débat). J'ai cette chance d'avoir 10 sur 10 à chaque œil, de ne pas souffrir d'épilepsie.. donc les pubs ->
Mais car il y a un 'mais' Lorsque la pub masque clairement le contenu, comme c'est le cas sur Lycos via des e-stickers, là oui çà me gêne.
Mais car il y a un 2ème 'mais', mon propre argument "site mal conçu = merci au revoir" ne tient pas forcément toujours la route. Regarde le nombre de personnes débutant dans la programmation web qui viennent ici demander un avis sur leur premier site. Une majorité ne va pas avoir pris un NDD + un hébergement payant. Va-t-on devoir pour autant quitter leur site en leur disant "ah désolé, il y a de la pub intrusive, je m'en suis allé" ? Non Donc dans ces cas-là, on désactive vite fait le JS, on visite leur site sur Lycos, ensuite on réactive.. ou on ne réactive pas
Pour ce qui se révèle être mon argument principal, c'est tout simplement qu'en tant qu'utilisateur, je n'ai que rarement l'utilité du JS. Ben oui, c'est comme çà. Un exemple sur le Hub: les balises BB Code sont formées à l'aide de Javascript. Oui mais je me sers rarement de ma souris (c'est comme çà aussi, question d'habitude) et je fais tout au clavier. Donc je tape mes balises manuellement; pour moi cela va beaucoup plus vite. Donc je n'ai nul besoin de Javascript.
D'ailleurs le Hub est un mauvais exemple: je surfe souvent ici avec le JS activé ^_^

Ensuite, les fonctionnalités:
*Déplier/Replier des blocs
Certes, le Javascript permet cela. Mais les CSS également (display/visibiliy). Et c'est toute la différence entre un menu de site écrit en JS et un autre menu de site écrit en HTML/CSS: le second fonctionne parfaitement avec le JS désactivé, l'autre nécessite un langage que l'utilisateur peut très bien avoir désactivé pour moultes raisons intéressantes (et il y a autant de raisons que d'utilisateurs qui désactivent le JS)
À noter également qu'un bloc peut très bien, sans JS, être déplié par défaut. Et que le même bloc, avec JS cette fois, pourra être déplié/replié. Il n'y a aucun souci là-dessus
Pour ce qui est des blocs qui se déplient lorsqu'on coche une case (çà ressemble beaucoup à du Google, çà ), là je suis carrément contre cette technique. L'accessibilité en prend un méchant coup

*Menu déroulant
Le langage CSS permet de faire aussi bien, voire carrément mieux. En plus léger, plus accessible, etc etc..

*Petites fonctions de calcul
Voilà typiquement le genre de fonctionnalités que je trouve utiles dans un intranet ou un back-office, mais pas dans un site. Enfin, personnellement, je ne vois pas dans quel contexte je devrais mettre ce genre de choses sur un site
À noter qu'il est possible de faire faire des calculs à PHP

*Comportement automatique en fonction de la saisie
"Voilà typiquement le genre de fonctionnalités que je trouve utiles dans un intranet ou un back-office, mais pas dans un site." (bis)
Si, au boulot, je dois saisir des données dans des formulaires toute la journée, çà peut être utile. Mais je ne mettrais pas ce genre de choses sur un formulaire web, car a priori on ne remplit pas 15 000 formulaires / jour sur un site.
Toutefois, je n'ai rien contre cette technique quand, côté client, je la vois utilisée sur des sites. Mais si elle n'est pas présente pour cause de JS désactivé, çà ne dérange personne.

Voilà. Donc en gros, je ne cherche pas à contrer tous des arguments, mais à les relativiser. Il est toujours possible de rendre le javascript non-indispensable (je sais, la phrase n'est pas très claire)

Quant à la mode, comme toutes les modes, çà s'en va.. çà revient, çà s'en va à nouveau... çà revient...
-> "La mode, c'est ce qui se démode" (Coco Chanel)

Personnellement, en tant que développeur, je vois javascript comme 2 choses :
- la possibilité d'ajouter un petit confort,
- la possibilité de faire des controles avant envoi au serveur.

Pour l'ajout du petit confort supplémentaire, je mettrais en vrac les menus déroulants, les couleurs qui changent en fonction de l'emplacement de la souris, etc..
Ca, je trouve que ca n'est pas indispensable, et j'essaie de m'en passer.

Pour la possibilité de faire des controles avant envoi au serveur, la regle est simple. Javascript ne permet pas de garantir que l'internaute a entré les bonnes données. Il est facile de passer outre javascript, ce qui fait que le formulaire 'remplir toutes les cases' ou tous ces trucs là doivent être de toute facon controlées sur le serveur. Ajouter à ceci le javascript, ca serait alourdir le programme. On me rétorquera que le fait que javascript controle permet d'éviter une surcharge de travail au serveur, mais dans la mesure où ce controle n'est pas fiable, je préfère m'en passer carrément.

Pour moi, javascript n'est pas viable dans le développement d'un site internet pour la simple et bonne raison qu'il n'est pas activé par tous, et qu'il n'est pas sûr.

Pour ce qui est de l'administration, par contre, j'ajoutes des fonctionnalités en javascript. Mais ce ne sont pas des fonctionnalités avancées. Et ca reste des 'effets de style', du 'confort', en aucun cas du 'controle'.

Quant à mon usage personnel, j'ai javascript activé sur IE, et désactivé sur Mozilla. Pourquoi ? Ben.. je sais pas, comme ca

Bonjour,



Ce n'est pas tout à fait juste.

Les lecteurs d'écrans comme jaws, window eyes... et les navigateurs vocaux comme Home page reader, fonctionnent comme une surcouche comme l'à précisé Ganf.
Si l'API du navigateur sait intérpréter javascript et si il est activé tous les scripts et fonctionnalités scriptées seront utilisables.

En revanche des problèmes d'ergonomie et d'utilisabilité peuvent se présenter et il est toujours necessaire de tester la situation que créé une fonctionnalité scriptée particulièrement pour des traitements atypiques.

Dans certains cas, un traitement bien fait peut être facteur d'une meilleure accessibilité.

Pour reprendre l'exemple du controle de formulaire, c'est toujours profitable de doubler le traitement serveur par un pré-controle javascripté qui en évitant un rechargement de page augmentera sensiblement l'utilisabilité et l'accessibilité du formulaire.

Même remarque avec l'utilisation de XMLHttpRequest (AJAX) qui peut rendre de grands services.

De même il n'y à pas à autocensurer des effets scriptés à destination du design si tant est qu'on prenne soin de vérifier qu'ils ne gênent pas.

Les bonnes questions à se poser avant de décider de l'implémentation d'une fonctionnalité scriptés ne concernent pas le support client ou l'utilité, elles concernent l'ergonomie, la méthode et les alternatives.

L'ergonomie et l'alternative sont les deux points essentiels d'un dispositif javascript car cela te forcera à une analyse réelle du processus.

En terme d'ergonomie tu dois t'assurer que le dispositif scripté demeure fonctionnel et produit le résultat attendu dans toutes les situations problématiques, notamment pour les handicaps visuels, moteurs et cognitifs.
Un exemple très simple : un menu déroulant qui n'est implémenté que sur les seuls events souris deviens rédhibitoire pour ceux qui navigue au clavier, il faut donc doubler tous les events souris de leur équivalents claviers (onfocus et/ou onkey...) par exemple.

En terme d'alternative, tu dois t'assurer que la fonctionnalité prise en charge par javascript possède une alternative crédible, efficace et de même nature en terme de logique applicative, ou ce qui reviens au même, que l'absence d'alternative ne constitue pas un problème.
Un exemple très simple : Un diaporama javascripté (images défilantes) où il n'y à pas d'alternative crédible est parfaitement utilisable si tu assures d'y adjoindre des vignettes fixes permettant d'accéder manuellement aux images.

Si tu respectes ces principes, ainsi que des méthodes sures : écriture normalisée, externalisation des scripts, utilisation du DOM ou encore la limitation, autant que faire se peut, des attributs d'evenements (onclick=fonction()) introduite dans le corps HTML au profit d'une affectation au chargement de la page, tu auras résolu l'immense majorité des problèmes.

Du coup le support ou non de javacsript n'est pas un problème car tu te dois d'assurer une alternative, et si le problème demeure c'est que ton procédé est mal conçus et qu'il faut le refaire.

JP

Autrement dit, le javascript assure 2 fois plus de travail

A quoi bon coder en javascript si l'on doit, en même temps, doubler systématiquement tout ?

À s'éviter une surcharge serveur. Quelques requêtes HTTP en moins, ce n'est pas négligeable; c'est vrai que j'utilise le Javascript sur site internet dans ces cas-là.
Quant à assurer 2 fois plus de travail, non pas forcément: un script JS de vérif est un script JS de vérif. On le code une fois, et on s'en sert partout (en modifiant les 2-3 paramètres différents)

D'ailleurs, en quoi n'est-ce pas fiable ? çà l'est la plupart du temps (si le JS est activé, donc, bien sûr)

***

Nissone: je m'aperçois que je n'ai oublié tout à l'heure de répondre concernant les "petites bulles d'aides contextuelles". Je ne sais pas si je te suis bien, mais tu parles des "nicetitles" ? Si oui, la désactivation de Javscript ne nuit pas à l'apparition d'info-bulles. Elles vont juste s'afficher 'normalement', c'est-à-dire avec le temps de latence par défaut, le temps d'affichage par défaut, et le look par défaut...

***

Tiens, j'avais oublié aussi: je fais une utilisation outrancière du JS pour des bookmarklets. C'est super pratique, mais cette utilisation ne se fait ni dans le cadre d'un site, ni d'un back-office... uniquement pour moi en local.
Je m'en sers entre autre pour reconstituer sous Safari les fonctionnalités de l'extension WebDevelopper pour FF, ou pour remonter des répertoires (ouh le vilain), ou encore pour lancer d'autres applications en 1 clic comme iTunes par exemple.
Dans ce genre d'utilisation, le JS c'est génial

Oui et non

Dans le cas d'un controle de fomulaire c'est quand même plus "pratique" de controler les champs avec javascript que d'imposer un aller retour serveur.

Sur ce genre de cas le surcroit de travail n'est pas énorme, ce sont souvent des procédés qui peuvent être généralisés.
Il est par exemple très simple de développer une pseudo classe JS de contrôle d'élements de formulaire qui ne nécessite aucune adaptation et peut prendre en charge des cas multiples (valeur requise, controle de type, de longueur, de caractère interdis...).

Il ne s'agit en aucun cas d'une "validation" qui est réservé au traitement applicatif lui-même mais simplement d'un "filtre" qui permet d'éviter l'aller-retour serveur dans la plupart des cas "simples".

Autre cas : La sélection multiple d'items de listes de résultats, où les solutions classiques sont généralement assez lourdes : fondé sur GET on impose un rechargement de page à chaque sélection et en utilisant POST on impose la gestion d'une multitude de champs de formulaires.
Dans les deux cas l'utilisabilité est médiocre et l'implémentation d'un procédé scripté, bien fait et testé "en situation" apporte une plus-value non négligeable.

En revanche il est vrai que pour des procédés plus complexes cela nécessite souvent de doubler le travail, mais bon, dans la perspective d'une meilleure ergonomie, d'une meilleur utilisabilité et d'une meilleure accessibilité, cela ce justifie pleinement.

JP