Afficher masquer div

Code:

onmouseout="cache(Div1')"

Il manque une quote.

 

Dans ma grande indulgence j'invoque donc le pal ... a moins que certains préfèrent l'emmurement

 

http://fr.wikipedia.org/wiki/Supplice_du_pal un peut de culture sur cette antique pratique.

Bon déjà faut pas doubler les fonctions et quitte a leur passer un paramètre il faut l'utiliser donc :

<script>
function affiche(id){
document.getElementById(id).style.display='block';
}
function cache(id){
document.getElementById(id).style.display='none';
}
</script>

Et ensuite je ne voie pas mis a part la répétition ce qui empêche ton code de répondre à ta demande.

 

ensuite c'est souvent plus propre de compacter une action :
<script>
function swicht(id){
obj = document.getElementById(id);
if(obj.style.display=='block'){obj.style.display='none';}else{obj.style.display='block'}
}
</script>

ce qui te permet d'invoquer via : onmouseover="swicht('Div2');swicht('Div1');" onmouseout="swicht('Div1');swicht('Div2');"

 

Meuh non c'est ça le supplice du pal (pov bêtes ^^)

 

Non ça c'est "en plus" en attendant le pal ... :lol:

 

je te conseille JQUERY: avec JQUERY, plus de soucis

 

Mouais entre apprendre a utiliser une bibliothèque et apprendre a en utiliser une autre il est vrai que c'est forcement plus simple.

Maintenant si il faut coller un JS de 10 tonnes minifié sur une page pour cacher une div ou la faire apparaitre en fondu la ou 20 lignes de code suffises oui peut être ...

Ou alors c'est pour faire du copier coller plus facile ... car a la base les gars qui dev sur ce framework ils ont pas de souci avec javascript ... Faut donc peut être pas mettre la charrue avant les bœufs.

Mon vieux père disait au temps ou j'étais un jeune con (ma femme dit que j'ai juste vieilli, mais pour le reste ... :lol: ), bref il disait que pour faire de l'informatique il fallait que je fasse avant de l'électronique pour comprendre comment ça marche (ce en quoi il avait partiellement raison). On peut mettre l'image au gout du jour et dire qu'un bon pilote automobile (pas monsieur tous le monde) doit être mécano avant tout pour sentir sa mécanique.

Je pense que ça s'applique bien là. Je le voie a toutes les session d'exam codeur que je dois évaluer. soit le gars a les bases en code et il s'amuse avec un framework sans problème et effectivement il sort des trucs très bien soit il a pas la base et c'est soit du copié collé soit de la m*rd* mais en aucun cas il fait du bon travail.

Après il faut extrapoler et penser éco-responsabilité. Imagine deux seconde en grossissant le traie que tu as un souci pour adapter un design a une version de navigateur Mac ou Linux. tu fait quoi avec cette logique ? tu propose le download de virtualbox et tu lui fait installer une image XP ou Seven dedans pour profiter de IE qui va bien avec ton design ?

Sinon si effectivement il travaille sur un projet qui a la base comporte ce framework c'est criminel de pas utiliser ... Mais faut pas oublier non plu que la créativité et l'innovation en prend un coup au passage car on fini par les voir a 100m ces sites "JQuerysés"

edit -> pas de panique c'est mon coup de gueule habituel sur les surcouches logiciel ...

 

jquery est très très simple à utiliser et à apprendre

tu peut utiliser les librairies jquery hébergé sur google: http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js

tu prend le problème à l'envers, jquery et autres librairies te font gagner du temps, un temps fou même car elles sont cross-browser, tu n'a jamais galérer à rendre 5 lignes de codes compatible sur tout les navigateurs???

en partie d'accord avec toi mais pour faire des truc propres et maintenable les surcouches logiciels sont indispensables...

 

javascript aussi

ça change quoi côté client ? ... (le problème c'est pas d'avoir ça sur son serveur ou un autre c'est de faire transiter sans cesse des tonnes de truc et le cache je veux bien mais bon c'est pas une généralité)

Oui, mais ... Quand on connais JS, c'est même pas une question qu'on se pose car quand tu as écarté les deux trois fonctionnalités qui coincent car spécifiques a une plateforme tu n'as aucun problème de compatibilité. De plus tu va avoir des galères (c'est générique) sur tout système mal maitrisé. Qu'est que ça change de les affronter vis a vis d'un langage ou un framework ?
Après faut être objectif, JS se résume a afficher 3 popup, vérifier des champs, faire apparaitre ou disparaitre deux trois trucs avec plus ou moins de style dans 90% des cas. Bref quand tu prend en main un tuto et que tu te fixe ces cas d'école avec JS tu en a au pire pour une semaine a comprendre et c'est fini pour la vie. Avoir les mêmes truc en JQuery te prendra le même temps (si tu fouille un peu pour comprendre sinon en copiant / collant ....)

Ensuite mais ça personne n'en parle on en arrive a faire des scripts pour que toutes ces bibliothèques de code soit compatibles entre elles ou pire compatible entre version ... (on a déporté le problème mdr ...)

Alors là !? sur "propre" a la rigueur, car les ajout CSS fait par des pro sur ce framework sont effectivement très bien ce que ne sera pas capable de faire un codeur pur il est vrai mais "maintenable" pas vraiment car
1/ si tu as une merde avec cette bibliothèque (ça m'est arrivé) tu ne peut rien faire dedans.
2/ plus tu as de code plus la maintenance deviens lourde et plus tu as de faille possible.

Avant la maintenance faut penser debug et avec ces framework c'est pas forcement plus clair.

Enfin moi ce que j'en dit c'est basé sur l'utilisation et le dev avec les deux principes natif / framework, sur les inconditionnels des framework javascript ici combien peuvent dire qu'ils dev avec les deux (je parle de dev et création pas de copier coller ou 4 lignes) ? 10 sur tout WRI ?

Ne te méprend pas j'aime bien cet outil mais là sur l'exemple du sujet c'est totalement abusé de préconiser JQuery pour un problème de div tu me voie tu me voie plu (il y a un sujet je sais plus ou sur WRI ou on a un membre qui propose ça pour mettre un lien aussi ).

 

Je pense pas qu'ils aient la même philosophie a Hiroshima :wink: un peut rapide ton raccourci

 

ah ba voila...

Code:

$('#id_de_ta_div').hide();
$('#id_de_ta_div').show();

$('.class_de_ta_div').hide();
$('.class_de_ta_div').show();


// lire la doc sur toggle également

une ligne suffit donc...plus simple non ?

 

Le pire, c'est d'utiliser un framework pour si peu.
Je pense que les framework ont un réel intérêt, c'est indéniable. Mais il faut que ce soit justifié.
De plus, l'utilisation d'un framework ne permet certainement pas de s’affranchir de l'apprentissage du langage de base, ici le JavaScript. C'est tout de même incroyable le nombre de personne utilisant un framework sans connaitre JavaScript.

Quand c'est possible, il existe des petites bibliothèques qui peuvent rendre bien des services sans devoir utiliser un bazooka. Par exemple, pour faire des animations, il y a moo.fx qui est utilisé par Mootools.

Et pourquoi jQuery ? Moi je préfère Mootools.

 

Tu ne compte pas les lignes de JQuery bref tu compare des choux et des patates. C'est de la pure mauvaise foi.

+1 Blount mais bon :cry: ... va faire comprendre que l'art est une question de maîtrise et pas une question de moyens.

 

c'est assez marrant de voir des personnes qui demandent, après avoir utilisé yslow, comment ils peuvent gagner quelques centaines d'octets sur leurs css en supprimant les espaces et, de l'autre côté, incorporer des js de plusieurs centaines de ko alors qu'ils n'ont besoin que de quelques fonctions qui ne prendraient que 1 ou 2 ko en les codant à la main en js

70,5 ko de fichier sur un ndd externe (qui va appeler lui-même d'autres fichiers externes, qui, eux-même, vont appeler des fichiers externes,...), alors que yslow recommande d'utiliser le moins possible de ndd différents pour télécharger les fichiers utilisés dans une page (images, api, js, css,...)