methode pour gere css et navigateurs

Olivier Masson :

Laurent vilday :

Olivier Masson :

Avec jquery (et forcément le très puissant prototype), tout cela sur
tous les navigateurs pas trop vieux (IE5 fonctionne la plupart du
temps).

Pour ne parler que des sélecteurs.

Franchement, à part une gestion des events je n'arrive pas à
comprendre à quoi d'autre ça pourrait servir (les sélecteurs CSS),

Alors ? A part associés aux events, à quoi ça sert ?
Si ça ne sert qu'aux events, alors désolé de le redire, il existe des
méthodes plus efficaces qui ne nécessitent pas des tonnes de lignes de
javascript imbitables.

Parce que oui, avec jquery (et les autres) un simple sélecteur c'est du
code javascript avec des tonnes d'eval en cascade qui sont appelés pour
obtenir (en priant pour pas trop se tromper) le tableau des éléments
répondant au sélecteur indiqué.

Non mais sérieusement, à quoi ça sert concrètement les sélecteurs CSS
dans du code JS ?

La question restera donc sans réponse à lire la suite !

Pas trop le temps de polémiquer,

Mouarf, évidemment !

d'autant plus que ça ressemble furieusement au thème "mais à quoi sert un cms ?",

Humm, non, aucun rapport.

Ma question, est et reste : "A quoi servent les sélecteurs CSS dans du
code javascript ?"

"mais à quoi sert le fait de rendre un site compatible sur IE6 alors
que FF c'est tellement mieux ?", etc.

Humm, non, toujours aucun rapport avec ma question.

Je ne doute pas de votre grande connaissance en JS. Un peu plus
de votre expérience de créa de site internet.

Et allez on va encore me mettre sur le dos la condescendance et tout le
reste, mais rien à foutre. Tu sais quoi ... fuck !

Disons que les sélecteurs CSS2.1 et CSS3 ne servent à rien, puique vous
gérez tout avec vos 3 lignes de JS.

Mais qu'est-ce que tu racontes ? Non, faut arrêter de prendre des
drogues, ça t'atteins le cerveau là ! Relis calmement ce dont je parle,
tes excuses seront acceptées ! Sérieux quoi !

Ai-je prétendu que les sélecteurs CSS ne servaient à rien ?
Non !

Ai-je prétendu avoir la solution ultime ?
Non, je suis même ouvert à toute démonstration de mon erreur !

Alors oui, fuck you !

Moi, je me sers beaucoup de sélecteurs.

J'en suis bien aise, je m'en sers aussi ça te fais une belle jambe non ?
Enfin pour les plus compatibles d'entre eux, oui quand il s'agit de les
utiliser dans mes feuilles de style, mais moi ma question n'a *rien* à
voir avec l'utilité avérée ou non des sélecteurs CSS dans du CSS.

Allez, je le répète, histoire d'être certain de pas être mal compris :
"A quoi servent les sélecteurs CSS *dans* du code *javascript* ?"

Pas sélecteur CSS dans CSS. Mais sélecteur CSS dans JS. Tu vois la
subtile différence ? Et prends note aussi, qu'il n'a jamais été question
des librairies JS ici, pas le moins du monde !

Je pense, par manque de temps (mais également de crainte de parler dans
le vide), les autres nombreux avantages de *certaines* bibli JS.

LOL, je n'en doute pas une seconde. Cependant on continue dans le HS, ou
a-t-il été question de l'utilité ou non des librairies JS ? Tu veux
réellement que je reformule plus basiquement ?

OK : Sélecteurs CSS dans JS à quoi ça servir ?

Comme je le disais, et on le voit ici, on se braque sur les bibli JS,
comme on se braque sur Flash, etc. C'est un état d'esprit, c'est comme ça.

Pfff, n'importe quoi.

T'as été mettre ton nez dans ces sacro saintes librairies ? Moi oui et
de mon point de vue, c'est tout pourri je préfère mon code de très loin.

T'as été perdre ton temps à 3 meetings avec le ninja qui a vomi JQuery ?
Moi oui et je le regrette amèrement, ceci dit je sais maintenant à quel
point cet individu ne sait pas de quoi il parle du tout.

Moi, j'utilise ce qui me parait utile, rapide, tout en gardant la notion
de "progressive enhancement", qui est rarement respecté par les codeurs
rebel, rarement sensibilisé à la notion d'accessibilité.

Pareil, j'utilise exactement la même chose, sauf que je connais au
caractère près (enfin presque :) là ou ça chie dans ma librairie
personnelle que je comprends, que je peux maintenir et que je peux faire
évoluer à ma guise. Je doute que tu puisse en dire autant avec tes
JQuery, YUI et autre Prototype !

Tant qu'à la notion de "progressive enhancement", elle n'a *rien* à voir
avec l'utilisation ou non d'une librairie. Soit tu connais ton taf, soit
tu le connais pas, c'est pas une libriairie qui va aider.

Alors soyons d'accord : faisons tous uniquement de l'assembleur et on
sera les meilleurs. Mais faudra bosser pour chaque machine, mais
finalement, on se fout de l'idée d'un truc universel.

Non mais n'importe quoi ! Tu comprends de quoi tu parles ou tu places
juste des mots aléatoirement les uns après les autres ?

Au passage, vive la mauvaise fois, puisque jQuery fait 15kb.

Et encore une fois, rien à voir, quand a-t-il été question de poids dans
l'histoire ?

Current releases :
<http://docs.jquery.com/Downloading_jQuery#Current_Release>

JQuery uncompressed : 97,6 Ko (99 997 octets)
<http://jqueryjs.googlecode.com/files/jquery-1.2.5.js>

JQuery minified : 54,4 Ko (55 715 octets)
<http://jqueryjs.googlecode.com/files/jquery-1.2.5.min.js>

JQuery packed (HORREUR) : 30,2 Ko (30 967 octets)
<http://jqueryjs.googlecode.com/files/jquery-1.2.5.pack.js>

LOL elle fait toujours 15Ko toute mouillée ta librairie chérie, mais qui
donc est de mauvaise fois ici ? Non mais je vous jure !

Sérieux, va apprendre à lire, tu es l'exemple parfait d'individu qui me
fait me taire ici, on peut pas discuter avec toi.

Alors disons que tu as raison et que j'ai 100% tort, woohooo !

--
laurent

Pierre Goiffon :

SAM :

Les images sont disposées n'importe où dans la page, il y en a
plusieurs, on ne peut pas savoir à l'avance où elle sont

Salut Pierre, j'ai bien lu tout ce qui précède et je préfère synthétiser
ici plutôt que de répondre à chaque post. J'espère que tu m'en voudras
pas, n'hésites pas a demander plus d'explications.

Je n'en vois pas trop l'utilité.

:) Pierre t'es déjà donné l'exemple dont j'allais me servir pour montrer
une utilisation possible. C'est une technique que j'utilise pour changer
le contenu d'une barre de status (pas window.status, n'ayez pas peur,
c'est un DIV affiché en bas du navigateur) avec le title des éléments
survolés. Parce que je sais pas pour vous, mais je connais pas beaucoup
de gens (utilisateurs) qui ont conscience du title, ça reste pas affiché
assez longtemps dans la plupart de mes navigateurs, alors qu'une belle
barre dans leurs couleurs préférées toujours au même endroit, ça ils
comprennent.

Un formulaire avec beaucoup de champs
A côté de certaines options on a cette icône permettant d'afficher une
aide contextuelle détaillant les usages...

Ce qui implique beaucoup de listeners attachés à beaucoup d'éléments du
document, au dela de 2 c'est déjà beaucoup trop.

Je t'engage sincèrement à trouver qque mns pour essayer le truc
présenté par Laurent.

Ca n'est pas applicable dans ce cas !

C'est toujours applicable.

Suffit d'avoir d'autres choses à
gérer de ci de là dans la page (menu déroulant, onglets, ...), et le
gestionnaire d'événement va se charger dans des proportions
déraisonnables (en tout cas non maintenables).

Comme Stéphane, je t'encourage a explorer la délégation des events, j'ai
moi aussi plein d'autres choses à gérer de ci de là sur mon application,
et la technique fonctionne à merveille, bien mieux qu'à l'époque ou
j'appliquais individuellement chaque listener sur chaque élément.

Le parent significatif des images impliquées dans ton exemple semble
être un formulaire. C'est donc sur ce formulaire qu'il faudra placer le
listener, et si plusieurs formulaires existent alors il faudra en placer
un sur chacun d'entre eux.

quelque chose comme :

function getTarget(e)
{
// code récurrent déjà fourni maintes fois,
// à placer dans une librairie, parce que oui moi aussi
// j'utilise des librairies dédiées.
// Réécrire les mêmes routines en permanence est stupide
// Mais utiliser du code non maitrisé est suicidaire
}

function showContextualHelp(e)
{
var target = getTarget(e);
if ( target.nodeName == "IMG" && target.title != "" )
{
// je sais bien que c'est pas alert ici, mais tu devrais
// avoir pigé le concept maintenant
alert(target.title);
return false;
}
return true;
}

for ( var i = 0; i < document.forms.length; i++ )
{
document.forms[i].onmousemove = showContextualHelp;
}

A priori (encore) tu ne pourrais pas gérer les events en mode DOM0
(frm.onXXXX), puisque tu as d'autres éléments, qu'à cela ne tienne, la
délégation d'events fonctionne aussi parfaitement bien avec le standard
addEventListener et l'infâme attachEvent de IE.

La seule différence, c'est qu'au lieu des return true/false dans le
listener pour terminer ou pas l'event, il faudra passer par des
event.stopPropagation et consorts, mais le principe reste le même.

Je te propose de nous montrer une page de démo assez complexe (2 images
c'est pas suffisant) utilisant JQuery, je suis sur que Stéphane se fera
une joie de te triturer tout ça pour jouer un peu avec :)

--
laurent

Le 12/6/08 2:30 AM, Laurent vilday a écrit :

Je te propose de nous montrer une page de démo assez complexe (2 images
c'est pas suffisant) utilisant JQuery, je suis sur que Stéphane se fera
une joie de te triturer tout ça pour jouer un peu avec :)

Certainement pas sans ton concours !
(c'est toi qui a les ficèles)

--
sm

Pierre Goiffon a écrit :

SAM wrote:

Au passage, vive la mauvaise fois, puisque jQuery fait 15kb. Mais
bon, SAM a décider que jQuery et consors étaient de la merde, donc
c'est ainsi.

Olivier, rédiger un message sous le coup de la colère ne fait
certainement pas avancer la discussion.

Oui, mais c'est tellement irritant ce petit monde des gens qui ont
forcément raison parce qu'ils ont des connaissances *techniques* ! Comme
je l'ai dit, on nous a servi le même plat il y a 10 ans avec JS.
On entend toujours les mêmes râleurs contre Flash, mais c'est bien grâce
à lui que l'on peut avoir une (absolue ?) compatibilité entre
navigateurs/plateforme. Que certains fassent des sites fullflash de 10Mo
ne vous plait pas ? Et alors ? On s'en fout.
Sur internet, il y a des cons, des faussaires, des mafieux, etc. : c'est
pourri pour autant ?
Si on devait écouter "ce petit monde", on devrait faire des sites d'une
trentaine de ko (pour ne pas froisser les accès RTC), surement utiliser
la palette web-safe, avoir son site compatible NN4, j'en passe.

La version minimale ET gzippée fait 15Ko en effet.
Ensuite sans le gzip mais en minimal c'est un peu plus de 50Ko
Et on peut ajouter aussi tout ce qui est UI... et éventuellement des
plugins !

La "perversion" de ce type de librairie est là et elle est très
prononcée chez jQuery (peut-être chez d'autres aussi, mais pas
prototype) : les plug-ins. Sur le site de jQuery, un grand nombre de
plugins inutiles, lourd, mal foutus, etc.
Dommage qu'il n'y ait pas un système de module comme sur Mootools pour
alléger jQuery. D'autant plus que je doute, comme se le demandais SAM,
qu'un JS puisse être mis en cache pour un site et utilisé par un autre.

Le 12/8/08 2:03 PM, Olivier Masson a écrit :

Pierre Goiffon a écrit :

SAM wrote:

Au passage, vive la mauvaise fois, puisque jQuery fait 15kb. Mais
bon, SAM a décider que jQuery et consors étaient de la merde, donc
c'est ainsi.

Si c'est juste pour attraper des trucs par leur class il me semble que
la méthode évoquée par Laurent n'est peut-être pas si idiote.
Voilà.
Bien sûr NN4 ne va rien y entraver.
Va t-il y comprendre avec jQuery ?

Olivier, rédiger un message sous le coup de la colère ne fait
certainement pas avancer la discussion.

Oui, mais c'est tellement irritant ce petit monde des gens qui ont
forcément raison parce qu'ils ont des connaissances *techniques* ! Comme
je l'ai dit, on nous a servi le même plat il y a 10 ans avec JS.

et ce n'est pas forcément obsolète !

Que certains fassent des sites fullflash de 10Mo ne vous plait pas ?

10Mo la page ?
Ha oui! ça fait beaucoup !

Et alors ? On s'en fout.

"qui" s'en fout ?

Si on devait écouter "ce petit monde", on devrait faire des sites d'une
trentaine de ko (pour ne pas froisser les accès RTC), surement utiliser
la palette web-safe, avoir son site compatible NN4, j'en passe.

Au moins qu'avec ni JS ni CSS ce soit exploitable.
(j'écarte les sites vitrines du propos)

D'autant plus que je doute, comme se le demandais SAM,
qu'un JS puisse être mis en cache pour un site et utilisé par un autre.

Ce serait pourtant ça de gagné.
Suffit que le src du script ne pointe que sur un serveur dédié à la
bibli, et que ce soit employé par tous les utilisateurs de la bibli.

Bon, en cas de surcharge du serveur délivrant la bibli, je ne sais
comment ça se passe (est-ce que celle en cache, si elle y est est, sera
utilisée ?)


--
sm

Olivier Masson a écrit :

Que certains fassent des sites fullflash de 10Mo
ne vous plait pas ? Et alors ? On s'en fout.

Vous avez bien raison. "On" a une connexion 100Mbits/s parce que "on"
habite Paris. Alors 10Mo, franchement, "on" s'en fout. Et tout va bien
dans le meilleur des mondes...

--
Michaël DENIS

Laurent vilday wrote:

Salut Pierre, j'ai bien lu tout ce qui précède et je préfère synthétiser
ici plutôt que de répondre à chaque post

C'est parfait, et merci de la réponse

Comme Stéphane, je t'encourage a explorer la délégation des events, j'ai
moi aussi plein d'autres choses à gérer de ci de là sur mon application,
et la technique fonctionne à merveille, bien mieux qu'à l'époque ou
j'appliquais individuellement chaque listener sur chaque élément.

Il faudrait que je me mette sur un exemple concret pour expérimenter,
parce que pour l'instant dans la théorie je suis assez apeuré de voir
des gestionnaires d'événement qui enflent (if ... else if ...) et qui
contiennent des choses qui devraient normalement être indépendantes.

Bon, en tout cas je note avec attention tes propos (et merci vraiment à
toi et SAM, c'est très intéressant !), je devrais sans aucun doute
m'attaquer à nouveau à du front-end d'ici 1 ou 2 mois, je verrai alors.

Olivier Masson wrote:

Olivier, rédiger un message sous le coup de la colère ne fait
certainement pas avancer la discussion.

Oui, mais c'est tellement irritant ce petit monde des gens qui ont
forcément raison parce qu'ils ont des connaissances *techniques* !

:D
N'approuvez pas si c'est pour renvoyer un autre message énervé derrière :)

On entend toujours les mêmes râleurs contre Flash, mais c'est bien grâce
à lui que l'on peut avoir une (absolue ?) compatibilité entre
navigateurs/plateforme.

Non non et non ! Et c'est bien le problème ! Ok pour la vidéo, pour les
RIA etc, Flash représente disons la "moins pire" des alternatives.

Voilà nous y sommes, c'est bien toute l'essence de la conception de site
Web : les compromis. Il n'y a jamais, et de mon expérience (Goiffon and
Co, depuis 1995) jamais eu de solution miracle, qui fonctionne comme
c'est écrit etc. Les standards sont incomplets, mal implémentés par les
navigateurs, etc etc (...)

Bref le tout n'est pas de savoir ce qui est "bien ou pas" mais d'adopter
ce qui convient le mieux pour ce que l'on souhaite faire. C'est
facile à dire...

La "perversion" de ce type de librairie est là et elle est très
prononcée chez jQuery (peut-être chez d'autres aussi, mais pas
prototype) : les plug-ins. Sur le site de jQuery, un grand nombre de
plugins inutiles, lourd, mal foutus, etc.

Je trouve qu'il y a quand même pas mal de choses dans JQuery UI, et de
ce que j'ai compris ce qui n'y est pas est relativement simple à coder
soit-même donc sans passer par des plugins.

La YUI est beaucoup plus exhaustive... mais ça se paie au prix lourd :
par rare d'avoir plus de 250Ko de JS pour une page (avec des scripts en
version minimale !)

Je trouve que JQuery s'en sort quand même plutôt pas mal du coup...

Le 12/8/08 4:22 PM, Pierre Goiffon a écrit :

Il faudrait que je me mette sur un exemple concret pour expérimenter,
parce que pour l'instant dans la théorie je suis assez apeuré de voir
des gestionnaires d'événement qui enflent (if ... else if ...) et qui
contiennent des choses qui devraient normalement être indépendantes.

Oui, bon, ben, quelques conditions ;-)

Voici un exemple sévi préalablement à l'intervention ici de Laurent
<http://cjoint.com/?mir22JKBrY>
où l'écouteur s'intéresse à 72 tags s'ils sont div ou h3
pour un simple mouseover ('onmouseover' que l'on ne retrouvera donc pas
sur chaque div ni en dur ni via une boucle sur le DOM qui fatigue IE)

Prière de ne pas commenter le graphisme
ni le fonctionnement complètement idiot de l'exemple,
ce n'est pas le sujet.

--
sm

SAM wrote:

Il faudrait que je me mette sur un exemple concret pour expérimenter,
parce que pour l'instant dans la théorie je suis assez apeuré de voir
des gestionnaires d'événement qui enflent (if ... else if ...) et qui
contiennent des choses qui devraient normalement être indépendantes.

<http://cjoint.com/?mir22JKBrY>

Je ne comprend pas bien que l'on surveille les div ET les H3 ?
Et ce gestionnaire d'événement ne fait que 2 tests, ne gère qu'un
déclencheur et qu'un "comportement"... Ce n'est pas l'exemple que
j'imaginais (mais merci en tout cas Stéphane de l'avoir proposé)

En reprenant l'exemple que je donnais précédemment avec mes images
déclenchant des aides contextuelles, on pourrais envisager une page de
formulaire avec :
- des images avec aide contextuelle
- le contrôle de saisie en dynamique (par exemple vérification par
rapport à un pattern)
- un compteur du nb de caractère saisis sur certains champs textes
- un treeview
- un menu contextuel sur certains éléments
- ...
C'est un exemple qui est tout à fait cohérent avec ce que l'on trouve
dans les applications Web maintenant... et on aura aucun mal à ajouter
d'autres choses en plus !

On va pouvoir déléguer à différents niveaux (sur le form, sur body, sur
un input donné, ...). Mais il y a un certain nombre de choses communes
au formulaire, donc on va quand même pouvoir se retrouver avec un
gestionnaire d'événement complexe, donc potentiellement buggy, et quasi
impossible à maintenir non ?