methode pour gere css et navigateurs

Laurent vilday wrote:

A quoi peuvent bien servir les sélecteurs CSS dans une librairie JS ?

Franchement, à part une gestion des events je n'arrive pas à comprendre
à quoi d'autre ça pourrait servir (les sélecteurs CSS), hors une fois
qu'on a compris comment marche les events et surtout comment déléguer
(event delegation) je ne vois pas l'intérêt du sélecteur CSS, si ce
n'est d'aller rapidement placer XXX listeners sur XXX éléments, ce qui
est *très* mal.

Laurent, je suis très surpris de ces lignes, pourrais-tu détailler ?

Pour moi (sans doute naïvement ?) le support des sélecteurs permet
d'accéder rapidement à un élément (modification du DOM, ajout
d'événement) sans avoir à m'ennuyer à descendre de childNodes en
childNodes ou à modifier mon HTML pour rajouter des id !

Pierre Goiffon :

Laurent vilday :

A quoi peuvent bien servir les sélecteurs CSS dans une librairie JS ?

Franchement, à part une gestion des events je n'arrive pas à
comprendre à quoi d'autre ça pourrait servir (les sélecteurs CSS),
hors une fois qu'on a compris comment marche les events et surtout
comment déléguer (event delegation) je ne vois pas l'intérêt du
sélecteur CSS, si ce n'est d'aller rapidement placer XXX listeners sur
XXX éléments, ce qui est *très* mal.

Laurent, je suis très surpris de ces lignes, pourrais-tu détailler ?

Houla je peux essayer, mais c'est pas gagné.

Ce qu'il faut voir, c'est qu'utiliser un sélecteur CSS dans du code JS
c'est rien d'autre qu'un wrapper pour éviter de boucler soit même sur
les éléments qui nous intéressent.

Ca n'empêche pas la création de milliers de listeners dans le document
quand un seul serait nécessaire grâce au concept de délégation de
l'évènement ("event delegation"). Hors dès qu'on se met à déléguer les
events, plus besoin des sélecteurs CSS, tout du moins pour moi jusqu'à
présent.

Pour l'instant et à défaut de m'en montrer plus, le seul "intérêt" que
j'arrive à concevoir pour les sélecteurs CSS dans du code javascript
c'est l'application de plusieurs listeners similaires sur des éléments
plus ou moins adjacents (des childs, des siblings, de toute façon il y a
toujours un parentNode sur lequel se baser).

Le plus "simple" (hurmm) c'est de me lancer sur un exemple : soit une
liste (UL) d'éléments (LI) sur lesquels le click doit afficher le
contenu du LI.

Structure :
***********

<ul id="mon_ul">
<li>contenu A</li>
<li>contenu B</li>
<li>contenu C</li>
<li>contenu D</li>
<li>contenu E</li>
</ul>

Application des listeners :
***************************
Il y a 3 (au moins selon les outils à disposition) façons de faire :

* A) méthode classique de boucle sur les childNodes
et application individuelle du listener.

function listener() { alert(this.innerHTML; }
var ul = document.getElementById('ul');
for ( var i = 0; i < ul.childNodes.length; i++ )
{
if ( ul.childNodes[i]
&& ul.childNodes[i].nodeType == 1
&& ul.childNodes[i].nodeName == "LI" )
{
ul.childNodes[i].onclick = listener;
}
}



* B) méthode avec sélecteur CSS (JQuery par exemple)
!! Je ne suis pas un expert de la syntaxe JQuery !!

$('#mon_ul > li').click(function() { alert($(this).html()); });



* C) méthode par délégation de l'événement

function getTarget(e)
{
var
evt = e || window.event,
target = evt.target || evt.srcElement;
return target && target.nodeType == 3 ? target.parentNode : target;
}

function listener(e)
{
var target = getTarget(e);
if ( target && target.nodeName == "LI" )
{
alert(target.innerHTML);
return false;
}
return true;
}
document.getElementById('ul').onclick = listener;


Constat :
*********

Méthode A :
+ simple à comprendre même pour un débutant en js
- fastidieuse boucle sur les childNodes, mais rien n'interdit de créer
un wrapper qui ferait la boucle pour nous
- nb listeners : 5

Méthode B :
+ concis (mais parce que l'exemple A est brut de pomme)
+ boucle de la méthode A disparue au profit d'un wrapper dans JQuery
qui le fait pour nous par le biais des sélecteurs CSS
- JQuery pour commencer, c'est un GROS moins
- perte de lisibilité du code dès que ça dépasse la dizaine de ligne
- difficulté de maintenance liée à la lisibilité
- nb listeners : 5

Méthode C :
+ concis
+ simple à comprendre une fois le concept d'event delegation appréhendé
- euhh, pour ma part pas de points négatifs pour cette méthode
+ nb listeners : 1 seul et unique


En gros, la méthode A est chiante à mourir avec sa boucle sur les
childNodes, ce qui a, je pense, conduit les concepteurs de librairies à
s'orienter vers les sélecteurs CSS afin de "simplifier" ce "travail" de
boucle sur les éléments impliqués.

Mais les events ont la *très* bonne habitude de remonter (bubble) dans
l'arbre du document d'où la méconnue méthode C (google: event
delegation), et dès qu'on a cet outils entre les mains, les milliers de
lignes de codes associées aux sélecteurs CSS deviennent obsolètes. Et le
gros intérêt de cette méthode c'est qu'un seul et unique listener par
parents impliqués est défini, au lieu d'un par childNodes. Ceci dit, je
pense qu'il vaut mieux éviter de pousser à l'extrème en déléguant
jusqu'au <body>, c'est un peu trop IMO.

A moins qu'il n'existe une autre utilisation pour les sélecteurs CSS
dans du code JS (ou plusieurs mais j'en doute, déjà une ce serait pas
mal), je ne vois pas l'intérêt d'aller charger une librairie avec ses
milliers de lignes de code non maitrisé.

Il est fort probable que je me trompes, mais pour l'instant je n'arrive
pas à en comprendre l'utilité profonde, si ce n'est d'être "ulta hype"
et de pouvoir se palucher en prétendant utiliser des sélecteurs CSS-3.

--
laurent

Laurent vilday :

Grrrr ...

<ul id="mon_ul">

[...]

var ul = document.getElementById('ul');

------------------------------------^^
var ul = document.getElementById('mon_ul');

évidemment ...

--
laurent

Le 12/4/08 9:50 AM, Sergio a écrit :

Dans son message précédent, SAM a écrit :

<http://stephane.moriaux.pagesperso-orange.fr/truc/tables_un-sur-deux_rows_fr>

Ta remarque sur IE est injuste : Chez moi, il est aussi rapide que FF3

Fais ajouter 50 tables (ou plus) pour voir là comme ça.
- déjà là FF.3 est bp + rapide
- ensuite essaie de changer l'ordre gris/jaune
Mon IE.6 est bp + lent que FF.3

C'était le but de cette démo, soit dit au passage.
(lenteur relative d'IE avec les tables)

et le survol fonctionne. (IE7 il est vrai)

Tant mieux, parce que mon IE.6 lui n'y arrive pas.

De l'époque de cette démo-test, IE.7 on ne faisait qu'en parler comme
d'un futur inaccessible.

Par contre avec IE7 la première table est moins large que les autres
(alors qu'avec FF, Opera et Safari, elles sont de largeur égales).

Tiens ? oui, de même que dans mon IE.6
No sè que passa ? !

--
sm

Le 12/4/08 2:28 AM, Hugolino a écrit :

Le Mon, 01 Dec 2008 21:42:45 +0100, SAM a écrit:

<http://stephane.moriaux.pagesperso-orange.fr/truc/tables_un-sur-deux_rows_fr>

Mais là, je vois pas. Comment est-il possible que dans cet exemple, la
couleur de fond des lignes paires soit différente de celle des
lignes impaires puisque il n'y a pas de 'class=' pour différencer les
lignes.

Pour sûr, puisque c'est le JavaScript qui distribue ces class.

Quand tu es en mode source-code tu n'as absolument pas besoin de
différencier les rangées :
de ttes façons c'est quasi illisible ;-)

J'ai regardé le source et les lignes sont identiques... ???

Oui, c'est l'intéret de la chose
(séparer la forme du fond poussée au plus possible ;-) )
(alléger au max le poids du fichier ?)

--
sm

Laurent vilday wrote:

A quoi peuvent bien servir les sélecteurs CSS dans une librairie JS ?

(...)

<ul id="mon_ul">
<li>contenu A</li>
<li>contenu B</li>
<li>contenu C</li>
<li>contenu D</li>
<li>contenu E</li>
</ul>

(...)

* C) méthode par délégation de l'événement

function getTarget(e)
{
var
evt = e || window.event,
target = evt.target || evt.srcElement;
return target && target.nodeType == 3 ? target.parentNode : target;
}

function listener(e)
{
var target = getTarget(e);
if ( target && target.nodeName == "LI" )
{
alert(target.innerHTML);
return false;
}
return true;
}
document.getElementById('ul').onclick = listener;


Constat :
*********

(...)

Méthode C :
+ concis
+ simple à comprendre une fois le concept d'event delegation appréhendé
- euhh, pour ma part pas de points négatifs pour cette méthode
+ nb listeners : 1 seul et unique

Merci d'avoir pris le temps de rédiger cet exemple très clair !

Tu donne un exemple simple avec un ul contenant déjà un id... mais ce
n'est pas bien souvent le cas ! Jusqu'ici j'ai souvent été contraint
d'ajouter des id dans mon HTML uniquement pour m'éviter de faire de
parcourir laborieusement le DOM...

Exemple avec des infobulles à afficher avec quelques effets lorsque l'on
survole des icônes identifiées (aide contextuelle). Le contenu à
afficher est en title de chaque image. Soit on ne modifie pas son HTML
et on trouve un moyen de parcourir le DOM (ou le "vieux"
document.images[]) pour récupérer les images... soit on utilise un
sélecteur à la JQuery et c'est plié (sélecteur img avec telle classe et
title non vide).
J'ai eu à traiter ce genre de chose sun paquet de fois et avant de
connaître JQuery c'était assez lourdingue...

Le 12/4/08 5:56 PM, Pierre Goiffon a écrit :

Laurent vilday wrote:

A quoi peuvent bien servir les sélecteurs CSS dans une librairie JS ?

(...)

<ul id="mon_ul">
<li>contenu A</li>
<li>contenu B</li>
<li>contenu C</li>
<li>contenu D</li>
<li>contenu E</li>
</ul>

(...)

* C) méthode par délégation de l'événement

function getTarget(e)
{
var
evt = e || window.event,
target = evt.target || evt.srcElement;
return target && target.nodeType == 3 ? target.parentNode : target;
}

function listener(e)
{
var target = getTarget(e);
if ( target && target.nodeName == "LI" )
{
alert(target.innerHTML);
return false;
}
return true;
}
document.getElementById('ul').onclick = listener;


Constat :
*********

(...)

Méthode C :
+ concis
+ simple à comprendre une fois le concept d'event delegation appréhendé
- euhh, pour ma part pas de points négatifs pour cette méthode
+ nb listeners : 1 seul et unique

Merci d'avoir pris le temps de rédiger cet exemple très clair !

Tu donne un exemple simple avec un ul contenant déjà un id... mais ce
n'est pas bien souvent le cas ! Jusqu'ici j'ai souvent été contraint
d'ajouter des id dans mon HTML uniquement pour m'éviter de faire de
parcourir laborieusement le DOM...

Exemple avec des infobulles à afficher avec quelques effets lorsque l'on
survole des icônes identifiées (aide contextuelle). Le contenu à
afficher est en title de chaque image. Soit on ne modifie pas son HTML
et on trouve un moyen de parcourir le DOM (ou le "vieux"
document.images[]) pour récupérer les images... soit on utilise un
sélecteur à la JQuery et c'est plié (sélecteur img avec telle classe et
title non vide).
J'ai eu à traiter ce genre de chose sun paquet de fois et avant de
connaître JQuery c'était assez lourdingue...

Ou bien je n'ai pas compris ?
Ou bien ton truc n'est pas assez compliqué ?

mais ...

function listener(e)
{
var target = getTarget(e);
if ( target )
{
var t = target.nodeName;
if ( t == "LI" )
{
alert(target.innerHTML);
return false;
}
if ( t == 'IMG' && t.title !='')
{
return infoBul(target);
}
return true;
}
}

Le listener à la Laurent me semble hyper simple à mettre en pratique.

Pour l'avoir un tt petit peu essayé, j'ai été suffoqué de voir à quelle
vitesse ça réagit, en particulier dans IE qui a un peu de mal à looper
dans le DOM.

Je suppose que le if(target.nodeName blabla) reblabla();
doit pouvoir lui-même être une fonction.

Sinon on crée : infoBul(e);
directement comme un listener, non ?

--
sm

SAM avait énoncé :

<http://stephane.moriaux.pagesperso-orange.fr/truc/tables_un-sur-deux_rows_fr>

Ta remarque sur IE est injuste : Chez moi, il est aussi rapide que FF3

Fais ajouter 50 tables (ou plus) pour voir là comme ça.
- déjà là FF.3 est bp + rapide
- ensuite essaie de changer l'ordre gris/jaune
Mon IE.6 est bp + lent que FF.3

Non, ben justement, à peu près à égalité avec FF3 (P4HT 2,8GHz sous
XPSP3), que ce soit IE7, Opera ou Safari (les navigateurs "modernes"
installés sur ma machine).

C'était le but de cette démo, soit dit au passage.
(lenteur relative d'IE avec les tables)

Donc IE7 s'est bien amélioré !

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

Sergio wrote:

Ta remarque sur IE est injuste : Chez moi, il est aussi rapide que FF3

Fais ajouter 50 tables (ou plus) pour voir là comme ça.
- déjà là FF.3 est bp + rapide
- ensuite essaie de changer l'ordre gris/jaune
Mon IE.6 est bp + lent que FF.3

Non, ben justement, à peu près à égalité avec FF3 (P4HT 2,8GHz sous
XPSP3), que ce soit IE7, Opera ou Safari (les navigateurs "modernes"
installés sur ma machine).

Que veux dire le HT derrière le P4 ?
En tout cas il me semble qu'il s'agit d'une bête de course, et que donc
la différence de temps de rendu serait difficilement mesurable car
minime vu la puissance de la machine... non ?

Le 12/5/08 8:54 AM, Sergio a écrit :

SAM avait énoncé :

<http://stephane.moriaux.pagesperso-orange.fr/truc/tables_un-sur-deux_rows_fr>

C'était le but de cette démo, soit dit au passage.
(lenteur relative d'IE avec les tables)

Donc IE7 s'est bien amélioré !

OK, vu.
(me suis décidé à lancer mon émulateur WinXP/IE7)
(j'aime pas trop : il n'a pss d'AV)
--
sm