Si vous ressentez un petit coup de froid cette nuit, c'est normal, c'est à minuit qu'interviendra le gel du code précédant la sortie de la première béta de Firefox 3.1, Shiretoko pour les intimes. L'occasion de citer en vrac quelques unes de ses nouveautés dont je n'ai pas encore parlé...
Tag - DOM
mardi 30 septembre 2008
Quelques nouveautés de Firefox 3.1...
Par Clochix le mardi 30 septembre 2008, 23:59 - Technoweb
mardi 26 août 2008
Sélectionner des éléments en JavaScript
Par Clochix le mardi 26 août 2008, 08:37 - les petits tutos à toto
Jusqu'à présent, les possibilités de sélectionner directement des élément d'une page web en JavaScript étaient plutôt limitées. On ne disposait que de:
- document.getElementById : en fonction de l'attribut id de l'élément, censé être unique à l'intérieur du document
- document.getElementsByName : en fonction de l'attribut name
- document.getElementsByTagName : en fonction de la balise
- element.getElementsByTagName : retourne les descendants d'un élément en fonction de leur balise.
- document.getElementsByClassName : en fonction de la classe (attention, cette fonction n'a pas encore été normalisée par le W3C, ce n'est qu'une proposition du WHATWG, elle n'est donc peut-ête pas disponible dans tous les navigateurs.)
Et c'est tout. Pour tout le reste, il fallait soit se promener dans le document avec les fonctions de parcours d'arbre du DOM (père, fils, frères), soit utiliser XPath, qui est plus lourd et moins simple à appréhender.
Heureusement, the times they are a-changin', et le W3C travaille en ce moment à l'élaboration d'une spécification permettant de sélectionner des éléments au moyen des sélecteurs CSS, c'est à dire de la syntaxe utilisée pour déterminer à quels éléments s'applique un style[1]. Cette spécification crée deux nouvelles fonctions, applicables soit à l'ensemble du document, soit à un seul élément. La première, querySelector(), ramène le première élément correspondant au sélecteur, dans le document ou parmi les descendants de l'élément à laquelle elle est appliquée. La seconde, querySelectorAll(), ramène tous les éléments. Il devient ainsi aisé de sélectionner des éléments en utilisant de nombreux critères.
WebKit implémente déjà cette interface depuis quelques mois, elle a atterri il y a quelques jours dans Firefox 3.1, Opera est OK aussi et, oh mon Richard, ça sera même dans IE 8, je n'en reviens pas !!! (je n'ai par contre pas trouvé l'info pour W3)
- Oui mais, mes utilisateurs n'utilisent pas de navigateurs modernes,
qu'est que je peux faire ?
- changez d'utilisateurs ! A défaut, la plupart des bibliothèques et des
frameworks javascript implémentent des fonctions similaires... non, oubliez
toutes les librairies et les framework JavaScript, tout cela c'était avant
John Resig, John Resig, l'homme
qui ne dort jamais, qui le vendredi participe au commit du
nouveau compilateur JavaScript à la volée de Firefox, le lundi livre une
nouvelle
version de l'indispensable Firebug, et entre les deux, s'ennuyant sans
doute un peu, écrit Sizzle une nouvelle librairie de quelques centaines de lignes
qui implémente le querySelectorAll dans tous les navigateurs qui ne le
possèdent pas, et avec des performances laissant sur place toutes les
précédentes implémentations. Si la programmation était discipline olympique,
John mériterait assurément plus d'une médaille, mais heureusement nous n'en
sommes pas encore là 
Notes
[1] cf mon rappel sur tous les sélecteurs CSS disponibles
mercredi 30 juillet 2008
Sélecteurs CSS 3 dans Firefox
Par Clochix le mercredi 30 juillet 2008, 02:10 - Technoweb
Dans le flot continue de saloperies toutes plus déprimantes les unes que les autres qui déferlent sans trêve par tous les canaux surnagent quelques îlots de béatitude, quelques raisons d'espérer un avenir radieux. Le flux des commits dans le tronc de Firefox est de ceux-ci. Une première version alpha de Firefox 3.1 vient de sortir, et parmi les nouveautés signalées par Laurent, 2 ont particulièrement retenu mon attention: Firefox implémente à présent complètement un des modules de CSS3, les sélecteurs, et une API permettant de les utiliser pour sélectionner des éléments dans un document. L'occasion de revenir sur ce concept de sélecteurs en résumant (mal) la spec
mercredi 23 juillet 2008
Une gestion d'évènements pas à la hauteur DOM
Par Clochix le mercredi 23 juillet 2008, 01:31 - Technoweb
Le DOM est une méthode pour représenter un document sous forme d'objets arborescents. Cette méthode est par exemple utilisée pour manipuler des documents XML ou des pages web en HTML. Plusieurs spécifications ont défini le modèle, des méthodes pour y accéder, le modifier, etc. L'une d'elles permet de gérer des évènements survenant sur les objets. Malheureusement, j'ai toujours trouvé cette spécification étonnamment incomplète. Elle présente à mon sens 2 lacunes:
- elle ne permet pas de connaître les guetteurs associés à un événement
- elle ne définit pas, ou mal, ce qui doit arriver à ces guetteurs lors de manipulations du document.
La méthode de gestion retenue est en effet de permettre d'attacher à chaque
objet des guetteurs qui seront appelés quand surviendra un événement.
Malheureusement, la spécification ne dit pas ce qui doit arriver à ces
gestionnaires quand l'objet est déplacé, par exemple dans un autre document, ou
dupliqué. Chaque implémentation de la spécification a donc dû décider de
l'attitude à adopter dans ces cas. Dans le cas de Firefox, les guetteurs sont
perdus en cas de déplacement du nœud dans un autre document (par exemple
lorsqu'on essaie d'insérer dans une fenêtre popup des éléments générés dans la
fenêtre mère), ou lorsqu'on le copie (la spécification indique effectivement
quand un objet Node est recopié en utilisant la méthode cloneNode, les
guetteurs EventListener attachés à l'objet Node source ne le sont pas sur
l'objet Node copié
, cf la
définition des guetteurs.
Petit exemple: imaginons que l'on ait besoin de créer dynamiquement un formulaire permettant à l'utilisateur de saisir un nombre quelconque de réponses, chaque réponse étant l'objet d'une validation. Cela pourrait se coder ainsi:
<!-- Création du formulaire -->
<form id="my_form">
<input type="button" id="button_add" value="ajouter" />
</form>
<script type="text/javascript">
function init(){
// on crée une ligne permettant la saisie
var _div = document.createElement("div");
var _input = document.createElement("input");
_input.setAttribute("type", "text");
// on attache un guetteur qui affiche la saisie quand le curseur quitte la zone
_input.addEventListener('blur', function(){alert("la valeur saisie est : " + this.value);}, false);
_div.appendChild(_input);
// on insère la première ligne
document.getElementById("my_form").appendChild(_div);
// chaque pression sur le bouton insérera une nouvelle ligne
document.getElementById("button_add").addEventListener('click', function(){document.getElementById("my_form").appendChild(_div)}, false);
}
</script>
Ce code ne fonctionnera pas. En cliquant sur le bouton "Ajouter", on insère bien une copie de la première ligne, mais le guetteur censé valider la saisie n'a pas été recopié par le cloneNode.
Cet exemple est bien sûr trivial, il suffirait, après le clonage, d'ajouter un nouveau guetteur sur le champs de saisie. Mais cela suppose de connaître tous les guetteurs qui ont été associés, potentiellement par d'autres portions de code, au fragment cloné. En l'absence d'interface pour connaître ces guetteurs. le problème est difficile à résoudre. C'est pour le contourner que je me suis enfin intéressé à XBL, dont je vous parlerai dans les prochains jours (ce billet ne servait qu'à liquider ce problème auquel je me suis heurté vainement pendant pas mal de temps en codant Couac )
(toute ceci ne concerne que Firefox. Il parait que les récentes versions du malware au 'e' bleuté dupliquent les guetteurs lors d'un cloneNode. Je n'ai pas été vérifier)