Blog - Britoweb - Tag - javascript

Ce n'est pas bien de mêler code HTML, CSS et JavaScript !

Victor Brito — Mon, 24 Nov 2008 13:17:00 +0100

Bruno Bichet a publié hier sur son blog un billet expliquant pourquoi ce n'est pas une bonne pratique que de mélanger le code HTML, les CSS (à coup d'attributs style) et le JavaScript (à coups d'attributs d'événements de type onnom de l'événement). Il s'agit d'une traduction (Bruno Bichet parle de craduction ) d'un billet de Robert Nyman, en anglais, à ce sujet.

Dans l'ensemble, il n'y a rien à ajouter aux explications de Bruno Bichet, explications qui se doublent d'une démonstration de ce qu'il faut faire si l'on se soucie de bonnes pratiques de codage en CSS et en JavaScript : autrement dit, il faut séparer le contenu (et la structure, de préférence conforme au balisage sémantique, de ce contenu) de sa présentation et des comportements dynamiques qui s'y appliquent. N'oublions pas que c'est pour tendre à cet objectif de séparation que les feuilles de styles sont apparues (pour rappel, il y a bientôt douze ans !) et qu'on a mis au point le concept d'unobstrusive JavaScript (en bon français, le JavaScript non intrusif).

D'ailleurs, à propos de JavaScript, j'ai une remarque à faire concernant la gestion des événements et la résolution des conflits éventuels entre plusieurs gestionnaires d'événement. Il n'est pas nécessaire de recourir à une bibliothèque JavaScript pour faire cohabiter pacifiquement plusieurs gestionnaires d'événements : en effet, la spécification DOM niveau 2 événements du W3C a de quoi suffire, ainsi que la gestion des événements propre à Internet Explorer.

function fnAjaxNews ()
{
  // Get news through Ajax
}

function fnGetNews ()
{
  var oGetNews = document.getElementById ('get-news');
  // For standards-compliant browsers
  if (oGetNews.addEventListener) oGetNews.addEventListener ('click', fnAjaxNews, false);
  // For Internet Explorer
  else if (oGetNews.attachEvent) oGetNews.attachEvent ('onclick', fnAjaxNews);
  // For browsers who do not understand DOM level 2, there is no event
  else return;
}

// Let us load the function above
function fnLoad ()
{
  // For standards-compliant browsers
  if (window.addEventListener) window.addEventListener ('load', fnGetNews, false);
  // For Internet Explorer
  else if (window.attachEvent) window.attachEvent ('onload', fnGetNews);
  // For browsers who do not understand DOM level 2, there is no event
  // (which means these browsers will behave as though JavaScript were deactivated or not supported)
  else return;
}
// Execute
fnLoad ();

Sans doute y a-t-il plus de code à pondre que si l'on utilisait une bibliothèque JavaScript ; mais, ce bout de code a l'avantage d'éviter les conflits (d'autres fichiers JavaScript pourront être appelés qui gèrent les évenements de la sorte) et de ne pas servir de JavaScript (c'est un choix) aux navigateurs incapables d'implémenter l'une des deux méthodes d'ajout d'événement (que ce soit la méthode standard ou la méthode propriétaire d'IE) : pour ces derniers, il y aura donc une dégradation élégante, qui ne sera pas gênante, pourvu que le contenu soit parfaitement accessible sans JavaScript.

Bien développer pour le Web 2.0 de Christophe Porteneuve, deuxième édition : note de lecture

Victor Brito — Sat, 22 Nov 2008 14:48:00 +0100

Les éditions Eyrolles ont publié le mois dernier la deuxième édition de Bien développer pour le Web 2.0 - Bonnes pratiques Ajax, de Christophe Porteneuve.

Le titre du livre en dit assez sur son objectif : inculquer aux développeurs de bonnes pratiques pour mettre en place des applications imprégnées de JavaScript non intrusif, de respect des standards du Web et même d'accessibilité. Même s'il y a beaucoup de matière (pas moins de 674 pages !), les différents chapitres sont d'autant plus agréables à lire que le ton employé n'a absolument rien d'un cours magistral ennuyeux et reflète la passion qui anime l'auteur.

La deuxième édition de ce livre, parue deux ans après la première, tient compte de l'évolution des navigateurs : Internet Explorer 8 est abordé, ainsi que les derniers outils de développement (comme le Dragonfly d'Opera). En outre, cette deuxième édition s'est enrichie d'un chapitre très instructif sur le débogage en JavaScript, ainsi que d'un chapitre sur des APIs tierces comme Google Maps.

Le principal regret, c'est que, pour la couche serveur nécessaire aux requêtes Ajax, l'auteur préfère le langage Ruby à PHP (c'est son droit ) ; nonobstant, ses exemples d'utilisation d'Ajax sont aisément adaptables à PHP. Un autre regret peut aussi venir à l'esprit des inconditionnels de JQuery, en ce sens que l'auteur, parmi les bibliothèques et autres frameworks JavaScript, n'aborde que Prototype et script.aculo.us, se contentant d'indiquer l'existence d'autres bibliothèques (dont JQuery) dans une annexe.

Cela dit, ces regrets n'amoindrissent en rien l'intérêt de lire ce livre. De plus, la plupart des exemples y figurant peuvent être téléchargés sur le site d'Eyrolles, regroupés dans une archive zip.

Internet Explorer 8 et le JavaScript : un détail intriguant

Victor Brito — Tue, 07 Oct 2008 21:19:00 +0200

En parcourant rapidement un billet du blog de MSDN sur les mises à jour d'IE 8 concernant Ajax, je suis tombé sur le bout de code suivant qui m'a particulièrement intrigué : window.attachEvent("onmessage", HandleMessage);.

Ceux qui connaissent bien les gestionnaires d'événements en JavaScript auront vite remarqué que le bout de code en question montre la méthode propriétaire d'IE pour ajouter un événement à un élément. Or, la méthode standard prévue par JavaScript à cet effet est addEventListener. Et le billet en question ne mentionne nulle part un window.addEventListener("message", HandleMessage, false); (l'ajout d'événement tel que le reconnaissent Opera, Firefox, Safari et tous les navigateurs respectueux des standards).

Cela voudrait-il dire qu'au sujet d'IE 8, Microsoft ne tient pas toutes ses promesses en matière de support des standards du Web (et pas seulement des CSS) ?

Internet Explorer 8 fournit un support natif de JSON

Victor Brito — Wed, 10 Sep 2008 21:10:00 +0200

C'est ce qu'annonce, entre autres, le blog de MSDN dans un billet consacré aux nouveautés de JScript (le JavaScript à la sauce IE) dans la bêta 2.

Connaissez-vous les JSSS ?

Victor Brito — Mon, 23 Jun 2008 22:12:00 +0200

En lisant un entretien accordé par Daniel Glazman à Openweb sur les CSS, je suis tombé sur le sigle suivant : JSSS.

J'ai ainsi appris qu'il y a une décennie (ce qui, à l'échelle du Web, veut dire dans l'Antiquité), Netscape mit au point les feuilles de style JavaScript (en anglais JavaScript StyleSheets), qui concurrençaient les CSS.

Si elles pouvaient être puissantes pour des calculs dynamiques hautement complexes ; en revanche, elles se rélévaient bien pauvres à côté des CSS, en ne supportant que le sélecteur d'élément simple. De plus, la syntaxe, issue de JavaScript, était plus verbeuse et sensible à la casse : là où en CSS on écrit h1 { font-size: 20pt; }, en JSSS on écrivait document.tags.H1.fontSize = "20pt";.

Bien que Netscape eût soumis les JSSS au W3C, elles ne furent jamais acceptées comme standard. Qui pis est, elles furent d'autant plus boudées par le marché que le principal concurrent de Netscape, Internet Explorer, n'hésita pas à adopter les CSS comme langage de feuille de style. Seul Netscape 4, sorti en 1997, supportait les JSSS ; mais, très vite, la société Netscape laissa tomber la promotion de ce langage propriétaire pour s'intéresser aux CSS et cessa tout support des JSSS à la sortie de Netscape 6, en 2000.

Pour plus de détails, un article de Wikipédia lui est consacré, qui m'a servi de source pour les propos tenus dans ce billet.