Série d'articles à propos du JS non intrusif @pompage.net

À noter la parution du premier d'une série de cinq articles concernant le Javascript non-intrusif (ou comment concilier javascript et accessibilité) sur pompage.net.
Modifié par Necromantik (17 Nov 2007 - 18:32)

Mouais, j'ai vu largement mieux comme article

Très clair et très bien documenté. Cela manquait vraiment pour les non anglophones. J'attends la suite avec grand intérêt

Shinuza a écrit :
Mouais, j'ai vu largement mieux comme article

En voilà un avis constructif (désolé, je prends le sujet un peu en retard).

Shinuza a écrit :
Mouais, j'ai vu largement mieux comme article

Il ne faut pas oublier qu'il s'agit du premier d'une série de 5, donc il faut bien commencer par les bases (c'est d'ailleurs ce qui fait bâiller mes étudiants, et pourtant la suite prouve que ce genre d'introduction n'est jamais complètement inutile).

On parle de javascript non intrusif, hors le premier pas vers l'application du paradigme en question est de respecter une sépération des couches.

Les CSS sont un exemple type, donc au même titre qu'en css on n'utilisera pas de style inline, on ne doit pas insérer d'élements relatifs au javascript dans le html.

Et ce d'un point de vu logique, au même titre qu'on ne mettra pas de html dans du php par exemple, on doit appliquer les même règles ici.

Le premier avantage étant d'avoir une règle de dépendances simplifiée (on admet par exemple qu'une feuille de style pourrait dépendre d'une autre feuille de style, au sens ou elle l'étend, mais que cette même feuille de style ne doit dépendre de rien d'autre - je pense notamment aux expression()), ce qui facilite le packaging et la maintenance.

Ce dernier point est particulièrement important, puisque qui dit javascript dans le code html dit formatage du html en fonction du javascript.
Ce qui induit que, si on modifie le html on doit également ajouter des élements qui font réference au javascript. Encore une fois, ce n'est pas le comportement qu'on attend d'une application.

Particulièrement dans le cas du javascript, qui, si on le veut non-instrusif doit être une surcouche du html et donc s'adapter à celui ci, et surtout pas l'inverse.


Donc l'article en question parle de javasript non intrusif en omettant ce point particulierement important (j'espère que ça sera abordé dans un chapitre futur ) donc on y retrouve un bout de code qui est loin d'être non-intrusif, la section qui concerne les globales est tout aussi dénué d'intéret puisque les fonctions données en exemple sont également dans le scope global, en encore une fois, inutile de polluer le dom avec du javascript.

Enfin, encore une fois j'espère que ça sera abordé dans un autre chapitre, mais le bout de code donné pour la validation de formulaire est totalement dépendant de la structure du html, ce qui est mauvais :

-Soit on admet une couche d'abstraction qui prend pour règle :

n élement-html-type traité par du javascript

équivalent à

n instances du code javascript en question dans le cas de données perennes une instance.

ou

1 instance abstraite.

- Soit on admet que l'élement est unique et le restera, donc le on crée une instance abstraite arbitraire.

Dans tous les cas, on passe soit par des identifiants instanciables (donc les class en html/css) soit par des identifiants uniques (donc les id en html/css)

Et ce n'est certainement pas ce qui à été démontré dans l'article, puisqu'en l'occurence il existe des identifiants qui ne sont pas utilisés.


Quelques articles très interessants, il en existe d'autres :
http://www.alistapart.com/articles/behavioralseparation
http://adactio.com/atmedia2005/
Modifié par Shinuza (23 Nov 2007 - 18:05)

Gilles a écrit :
Il ne faut pas oublier qu'il s'agit du premier d'une série de 5

+1

Par contre, bi-mensuellement ça veut dire tous les deux mois?
S'il faut attendre huit mois pour avoir la série complète, ça fait un poil long.

...

Réponse à moi-même: ah non, bi-mensuel c'est deux fois par mois.
Nos amis anglo-saxons disent (entre autres?) «every other fortnight», voire parlent de «fortnight scheduling» si je ne m'abuse.

Pour répondre aux craintes de Shinuza, l'auteur de la version originale en anglais est Christian Heilmann, qui a justement animé à Paris Web 2007 un atelier consacré à l'"unobtrusive javascript"...
Modifié par Gilles (23 Nov 2007 - 19:48)

Ca, j'ai vu, mais j'aurais surement pas commencé par cette partie, ici c'est assez disparate, alors qu'il aurait fallu se concentrer sur la partie évoquée au début, c'est à dire l'abstraction du comportement par rapport à la vue.

(En même temps pompage, ne fait que traduire l'article original)

Voilà la suite:
Javascript non-intrusif, chapitre 2 : comment retrouver les éléments que l’on veut manipuler

var monElement=document.getElementById('nav').firstChild;
if(monElement.nodeType==3)
{
 monElement.data='nouveau texte';
}
if(monElement.nodeType==1)
{
 monElement.firstChild.data='nouveau texte';
}

Non

 if(/roll/.test(imgs[i ].className))
  {
// ajoutons la fonction 'roll' à l'élément parent de cette image
  imgs[i ].parentNode.onmouseover=function(){roll(this);};
  imgs[i ].parentNode.onmouseout=function(){roll(this);};
  imgs[i ].parentNode.onfocus=function(){roll(this);};
  imgs[i ].parentNode.onblur=function(){roll(this);};
  }

Non

function trouveimg()
{
 var imgs,i;
 imgs=document.getElementsByTagName('img');
 for(i in imgs)
  {
  if(/roll/.test(imgs[i].className))
   {
    imgs[ i].style.border='3px dashed #ccc';
   }
  }
}

Et non [/i]

Je ne crois pas que pompage ait choisi le bon article à traduire.

Ps : Pompage est trop étroit, le code est souvent coupé, et les indentations manquent, c'est du à lire. J'enverrais un mail.
Modifié par Shinuza (06 Dec 2007 - 01:26)

a écrit :
Les CSS sont un exemple type, donc au même titre qu'en css on n'utilisera pas de style inline, on ne doit pas insérer d'élements relatifs au javascript dans le html.

Je ne voit pas pourquoi on ne devrais pas inserer d'élement inline dans le html, c'est des fois bien pratique, de même pour le javascript, si on fait un mini script sur deux liens, ça sert a rien de faire une boucle sur tout les liens de la page avec une fonction getbyclass et je ne sais quoi encore.

a écrit :
Particulièrement dans le cas du javascript, qui, si on le veut non-instrusif doit être une surcouche du html et donc s'adapter à celui ci, et surtout pas l'inverse.

C'est pareil, la logique du "doit", s'applique pour une application en ligne, ou une page dhtml complexe, mais des fois il vaut mieux modifier un peu le html que de se taper la tête contre les murs.

a écrit :

var monElement=document.getElementById('nav').firstChild;
if(monElement.nodeType==3)
{
 monElement.data='nouveau texte';
}
if(monElement.nodeType==1)
{
 monElement.firstChild.data='nouveau texte';
}

Non

Pourquoi non? ça dépend des cas, ça peut trés bien marcher dans certaines situations, si il fallait que tout les scripts doivent s'adapter a toutes les situations, on mettrais 15 ans pour chaque fonction, donc des fois il vaut mieux adapter la situation au script, cela peut être plus productif ( oui je sais c'est etrange comme logique, j'appelle ça la programation empirique : on resout le probléme du jour, le reste on verrat demain ). De toute façon il y aurat bien une future situation ou un future projet qui nous donnerat une raison d'améliorer la fonction. Et il est souvent plus rapide de faire un bricolage le jour ou veut améliorer plutôt que de mettre à jour toutes fonctions associés.

Je comprend ton niveau d'exigence mais je crois qu'il est un peu décalé avec le but de cet article, ce n'est pas les mêmes necesitées, de toute façon je doute que quelqu'un de ton niveau ne sache pas que c'est pas bon de mettre des onclick dans le html.
Modifié par matmat (06 Dec 2007 - 06:06)

Shinuza, c'est le deuxième article de la série. Les onclick, ils disparaîtront dans le quatrième... et les createTextNode, ils seront là dans le prochain numéro. Enfin, la stricte séparatation CSS/JavaScript est dans le sixième, pour le moment non prévu à la traduction.

Je suis prof, et je peux te dire que si jamais je m'aventurais à balancer du code JavaScript correctement écrit à mes étudiants dès le premier cours, premièrement ils ne pourraient pas suivre (trop à absorber à la fois), deuxièmement ils en seraient dégoûtés (ce qui ne ferait qu'indirectement les inciter à aller chercher sur le Web des codes tous faits, ce qui est clairement à proscrire ), troisièmement et d'un point de vue tout à fait égoïste, je ne prendrais plus aucun plaisir à les voir comprendre quelque chose progressivement. Je préfère et de loin un groupe de personnes dont la moitié a pu retenir au moins quelques bases, qu'un groupe entier à la ramasse dont seulement quelques-uns auraient compris comment coder proprement.

Ce n'est pas en pratiquant l'élitisme hermétique que l'on peut faire progresser les gens! Il faut les guider progressivement. C'est exactement comme si tu demandais à quelqu'un qui s'est toujours contenté de prendre sa voiture pour aller acheter du pain, de gravir d'un seul coup un 8000... Certains y arriveraient peut-être, mais la majorité va te claquer entre les mains. Il faut commencer par apprendre aux gens à marcher, puis à faire des balades de quelques heures en plaine et en colline, puis faire des randonnées en moyenne montagne, etc. En fixant des objectifs intermédiaires et progressifs, il y a deux avantages : tu peux amener les gens au plus haut niveau de leurs capacités initiales, en améliorant ainsi le niveau moyen de ton public (et ce, même si certains ne sont pas capables de réaliser des performances de "haute volée") et en plus, à chaque réussite intermédiaire, tu les motives et leur montres qu'ils peuvent aller encore plus loin...

C'est de la pédagogie élémentaire, et cette série d'articles y a tout simplement recours...
Modifié par Gilles (06 Dec 2007 - 09:44)

Gilles a écrit :
Shinuza, c'est le deuxième article de la série. Les onclick, ils disparaîtront dans le quatrième... et les createTextNode, ils seront là dans le prochain numéro. Enfin, la stricte séparatation CSS/JavaScript est dans le sixième, pour le moment non prévu à la traduction.

Je suis prof, et je peux te dire que si jamais je m'aventurais à balancer du code JavaScript correctement écrit à mes étudiants dès le premier cours, premièrement ils ne pourraient pas suivre (trop à absorber à la fois), deuxièmement ils en seraient dégoûtés (ce qui ne ferait qu'indirectement les inciter à aller chercher sur le Web des codes tous faits, ce qui est clairement à proscrire ), troisièmement et d'un point de vue tout à fait égoïste, je ne prendrais plus aucun plaisir à les voir comprendre quelque chose progressivement. Je préfère et de loin un groupe de personnes dont la moitié a pu retenir au moins quelques bases, qu'un groupe entier à la ramasse dont seulement quelques-uns auraient compris comment coder proprement.

Ce n'est pas en pratiquant l'élitisme hermétique que l'on peut faire progresser les gens! Il faut les guider progressivement. C'est exactement comme si tu demandais à quelqu'un qui s'est toujours contenté de prendre sa voiture pour aller acheter du pain, de gravir d'un seul coup un 8000... Certains y arriveraient peut-être, mais la majorité va te claquer entre les mains. Il faut commencer par apprendre aux gens à marcher, puis à faire des balades de quelques heures en plaine et en colline, puis faire des randonnées en moyenne montagne, etc. En fixant des objectifs intermédiaires et progressifs, il y a deux avantages : tu peux amener les gens au plus haut niveau de leurs capacités initiales, en améliorant ainsi le niveau moyen de ton public (et ce, même si certains ne sont pas capables de réaliser des performances de "haute volée") et en plus, à chaque réussite intermédiaire, tu les motives et leur montres qu'ils peuvent aller encore plus loin...

C'est de la pédagogie élémentaire, et cette série d'articles y a tout simplement recours...

J'ai aucun soucis avec ça, mais entre écrire du code totalement faux, du code non documenté totalement inutile, et un code simple mais correct y'a une différence.

Ici on manipule le dom, mais le problème c'est que ça demande un minimum de connaissances en javascript. Manipuler une API alors qu'on ne connait pas le langage c'est à mon avis une erreur, d'ailleurs l'auteur s'attends au contraire de la part de ses lecteurs puisqu'il utilise entre autres, des boucles, des regexp, des fonctions, des méthodes, etc...

La première version de trouveimg() est fausse et elle plantera, y'avais aucune raison de l'écrire comme ça, surtout qu'elle est écrire correctement après. C'est censé être de la pédagodie?

Le nombre de tutoriaux en français dont la qualité est médiocre est effarant, il ne faut pas oublier qu'on est sur Internet, et que les gens copient collent betement ce qu'ils voient la majorité du temps.

J'en prends pour témoin :

window.alert("Votre navigateur ne prend pas en charge l'objet XMLHTTPRequest.");

ou les

setTimeout("mafonction()",1000);

Il ne faut pas non plus prendre les gens pour plus bêtes qu'ils ne sont, on peut toujours expliquer pourquoi sans que ça devienne compliqué (typiquement dans ce cas)

Je n'ai jamais compris ce mythe qui dit qu'on doit apprendre à mal coder pour bien coder. Quand j'apprends à des gens je leur montre d'abord la bonne manière et ensuite la mauvaise, et de la je explique pourquoi c'est mauvais.

Le constat est que cet article s'adresse à des gens qui connaissent un minimun javascript (à voir le manque d'explication sur certains élements) et pourtant, il manque d'explications sur l'api (DOM)
Modifié par Shinuza (06 Dec 2007 - 13:47)