-
génial, j'en ai mis partout sur mon blog ! :
87(2.2 %)
-
un outil sympathique :
437(11.3 %)
-
redevenu à la mode avec le web 2.0 :
855(22.1 %)
-
un moyen de faire ramer n'importe quelle machine :
478(12.3 %)
-
pas supporté de la même manière par 2 navigateurs :
654(16.9 %)
-
toujours aussi inutile qu'au début :
171(4.4 %)
-
utile grâce aux libraires protoype & Co :
136(3.5 %)
-
une bouse infame :
818(21.1 %)
-
quoi ? :
235(6.1 %)
Total : 3871 votes
# javascript saibien
Posté par gc (site web personnel) . Évalué à 2.
[^] # Re: javascript saibien
Posté par François B. . Évalué à 4.
Il suffit d'utiliser l'attribut accesskey des balises A, AREA, BUTTON, INPUT, LABEL, LEGEND ou TEXTAREA.
Source : http://www.w3.org/TR/html4/interact/forms.html#adef-accesske(...)
[^] # Re: javascript saibien
Posté par seginus . Évalué à 6.
Par contre, les balise en majuscule, je trouve ça horrible, j'ai des bouquins ou les exemples de codes sont balisés en majuscules, et je trouve ça vraiment désagréable et illisible.
C'est tout ce que j'avais à dire à propos de ça.
[^] # Re: javascript saibien
Posté par Gof (site web personnel) . Évalué à 1.
(mais ça devait être avant l'invention de la coloration syntaxique)
[^] # Re: javascript saibien
Posté par François B. . Évalué à 3.
Sinon, à propos d'une comparaison entre minuscules et majuscules, il faut savoir qu'un flux HTML avec les balises en minuscules se compresse mieux que le même avec des majuscules... à moins d'avoir un site où la majorité du contenu est en majuscules :-/ (désolé, je ne sais plus à quel endroit j'ai vu cette comparaison)
[^] # Re: javascript saibien
Posté par erik_lallemand . Évalué à 2.
...ce qui se comprend au sens d'un codage de Huffman (http://fr.wikipedia.org/wiki/Codage_de_Huffman ) vu que le taux de compression est lié à la fréquence des symboles.
Si un texte contenant toutes les lettres de l'alphabet est essentiellement en minuscules tandis que les balises sont écrites en majuscules, on a une plus grande diversité des symboles et l'information est dispersée. Le taux de compression restera modéré. En revanche, si toute la page web est écrite à l'aide d'un jeu de 10 caractères, le taux de compression sera fabuleux. Il est plus facile de compresser "aaaaaaaaaahhhhhh" que "uejfuqlndgshfrpt" qui pourtant a une longueur identique.
...et sinon... tu codes souvent en te souciant de la compression du flux HTML? si oui, je suis curieux de savoir si c'est dans un but professionnel précis, ou juste par souci de perfection.
[^] # Re: javascript saibien
Posté par François B. . Évalué à 1.
Sinon, pour diminuer la taille des pages, il suffit de supprimer tous les espaces et retours chariot, et ne surtout mettre aucun commentaire ! Un instant... on me souffle dans mon oreillette que j'ai utilisé ça dans un de mes précédents projets pro : une appli J2EE avec un filtre qui supprimait commentaires et blancs. Résultat, c'était la galère quand on devait regarder le source généré pour traquer les bugs. Sans compter que la suppression de certains blancs changeait la mise en forme avec IE. Et non on ne pouvait pas désactiver le filtre, le serveur de dev n'était pas chez nous (mais chez le client) et nous n'avions pas accès ni à la classe du filtre, ni à la config de la webapp.
[^] # Re: javascript saibien
Posté par BlindMan . Évalué à 5.
Le javascript c'est le mal si on récupère plein de scripts buggés du web pour faire tout et n'importe quoi, en dépit du fonctionnement et de l'accessibilité de la page.
[^] # Re: javascript saibien
Posté par Cedric Malherbe (site web personnel) . Évalué à 5.
Et je rajoute, si c'est non obstructif (unobtrusive). C'est a dire si le contenu est toujours accessible, meme sans javascript active.
Il y a encore trop souvent des formulaires dont le bouton submit a ete odieusement supprime en faveur d'un vilain evenement onclick dans le but d'y inclure des verifications de chaine, alors qu'un evenement onsubmit return false applique a la balise form en aurait fait de meme mais en tellement plus propre (oui, ca necessite aussi de verifier les chaines cote serveur, mais ca devrait de toute facon etre le cas).
P.S. desole si mon francais a l'air etrange, ca fait des annees.... et un clavier qwerty sous les mains.
[^] # Re: javascript saibien
Posté par Moogle . Évalué à 3.
Maintenant qu'on a DOM, Ajax et plein de frameworks bien codés, on arrive enfin à faire des choses intéressantes et propres avec, et ça c'est kewl.
[^] # Re: javascript saibien
Posté par deluxe . Évalué à 2.
http://css.alsacreations.com/Tutoriels-JavaScript/bonnes-pra(...)
[^] # Re: javascript saibien
Posté par Matthieu Lemerre . Évalué à 2.
Depuis qu'il y a du javascript partout, je n'utilise plus (trop) emacs-w3m.
D'ailleurs, qu'en est-il de l'accessibilite quand il y a du javascript?
# ça pue c'est pas xhtml1 strict
Posté par Jul (site web personnel) . Évalué à 1.
<SCRIPT LANGUAGE="JavaScript"> function somme_N_entiers (N) { for (i=1,somme=0; i <=N ; somme+=i, document.writeln("Pour i = ", i++, "la somme est " , somme, "") ); return somme } var nombre= prompt("Somme des entiers jusqu'à N = ", 10); document.write("Somme des ", nombre, " premiers entiers = ", somme_N_entiers(nombre) ); < /SCRIPT>[^] # Re: ça pue c'est pas xhtml1 strict
Posté par BlindMan . Évalué à 2.
Il est ainsi possible de générer des solutions évitant l'indexation des adresses mail par des bots mal intentionnés, évitant du même coup le spam qui va avec.
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par François B. . Évalué à 3.
Ce que je fais, c'est coder l'adresse en décimal ou en hexadécimal. J'ai une adresse depuis plusieurs années sur un site relativement bien visité (plusieurs milliers de hits par jour) et je n'ai reçu aucun spam dessus.
Exemple : <a href="mailto:toto@example.com">Ecrivez moi</a>
Pour ceux qui n'auraient pas envie de copier/coller ça dans un éditeur pour l'afficher dans un navigateur, c'est un lien vers "mailto:toto@example.com". Les navigateurs comprennent, mais pas les extracteurs d'adresses.
Je vous laisse en exercice l'écriture du générateur ;-)
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par Mildred (site web personnel) . Évalué à 2.
Ou alors e créer une DTD rien que pour toi dans laquelle tu définit de nouvelles entités. Mais cela ne marche que avec gecko en mode strict.
Exemple :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd" [
<!ENTITY at "@">
]>
...
@at;
...
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par Jonathan Schemoul (site web personnel) . Évalué à 1.
L'idée est de tout faire clean sans JS, puis de l'ajouter par la suite, pour changer les liens par exemple grâce à des selecteurs CSS. Donc, on utilise JS comme du CSS, tout en gardant les contenus dans le xhtml :-)
Pour faire cela, une librairie comme MooTools par exemple a tout ce qu'il faut.
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par Jul (site web personnel) . Évalué à 2.
Faut savoir si le wbe a pour vocation d'etre un outil de partage de la connaissance, ou juste un attrape pigeon pour les entreprise ou le bac a sable des d{veloppeurs.
Ce qui ne m'empeche pas d'apprecier le JS tant qu'il est utilise avec parcimonie...
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par deluxe . Évalué à 0.
<script type="text/javascript"> <!--/*--><![CDATA[//><!-- // *** Ajoute le bouton "Generation du lien" *** function fnAddButton() { // Test des methodes if (!document.getElementById || !document.createElement) { return; } // Creation d'un bouton var oButton = document.createElement('input'); oButton.setAttribute('id', 'copyButton'); oButton.setAttribute('type', 'button'); oButton.setAttribute('value', 'Generation du lien'); oButton.setAttribute('onclick', 'fnCopyUrl()'); // Recuperation du paragraphe du formulaire var oFormP = document.getElementById('formP'); if (!oFormP) { return; } // Ajout du bouton au paragraphe du formulaire oFormP.appendChild(oButton); } // *** Extrait l'url a telecharger du cadre de texte *** function fnExtractUrl() { // Test des methodes if (!document.getElementById) { return; } // Recuperation du cadre de texte var oInputText = document.getElementById('inputUrl'); if (!oInputText) { return; } // Recuperation de la chaine de caracteres correspondant au lien var sInputUrl = oInputText.value; return sInputUrl; } // *** Definit l'url a telecharger dans le lien *** function fnSetUrl(sUrl) { // Test des methodes if (!document.getElementById) { return; } // Recuperation du lien a definir var oLink = document.getElementById('outputLink'); if (!oLink) { return; } // Attribution de la valeur du lien oLink.setAttribute('href', sUrl); } // *** Copie l'url a telecharger du cadre de texte au lien *** function fnCopyUrl() { // Recuperation du lien a copier var sUrl = fnExtractUrl(); // Attribution du lien a copier fnSetUrl(sUrl); } //--><!]]> </script>A noter que les codes de protection sont inutiles si on importe le script via un fichier .js....[^] # Re: ça pue c'est pas xhtml1 strict
Posté par Jean-Philippe (site web personnel) . Évalué à 3.
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par deluxe . Évalué à 1.
CQFD...
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par Toufou (site web personnel) . Évalué à 4.
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par Jul (site web personnel) . Évalué à 1.
Je comprends pas pourquoi peu quelquesoit le langage apprécie la beauté du
for(inits; test ; traitement avec iteration );
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par Guillaume Rossignol . Évalué à 2.
Il y a deja le for que je n'ai jamais trouvé d'une lisibilité formidable (surtout là où la variable testée n'est pas la meme ques la variable incrementé [enfin, je code pas en JS mais je suppose que le somme+=i à le meme sens qu'en C]
Et la post-ecrementation dan la foulé de l'appel d'une fonction... les seuls fois où j'ai ecris du code comme sa, c'etais pour embeter le profs qui venais voir ce qu'on faisait et que sa embetait de mal reussir à relire ^ ^
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par Jul (site web personnel) . Évalué à 3.
je trouve le
init
while (cond ){
traitement
}
toujours plus propre que le faussement concis
for (init; cond; incrementation) {
traitement
}
et j'utilise deux trucs de sagoin pour montrer que le for est moche :
- la possibilité en C, et js, (probablement en java)
de multiplier les opérations à un endroit si on sépare par des virgules
dans
for (i=0, somme=0; ...
les deux init sont fait en même temps
- et la possibilité d'ajouter le traitement dans la partie incrémentation du for.
Le for c'est moche, mangez du while :) que ce soit en js, et perl, en C, en C++ ou en java.
Au final, peut être que la programmation n'est pas foncièrement une question de langage :-)
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 1.
for (i=somme=0; ...
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par Jul (site web personnel) . Évalué à 0.
En ansi C ça n'était pas précisé dans la norme. Donc un même code pouvait marcher différemment selon les compilos. =>
fait on i = somme puis i=0 ou i=0; somme=0
donc à déconseiller :)
Ok pour faire du goret, pas pour faire un générateur d'erreur aléatoire :)
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 1.
Bah, je ne pense pas qu'il y ait un grosse différence sur le coup. Et
foo=bar=42; est parfaitement standard, même qu'on doit le trouver dans le K&R...
[^] # Re: ça pue c'est pas xhtml1 strict
Posté par パパフラクス . Évalué à 2.
En utilisant que la forme la plus simple.
évidemment le must, c'est une collection avec un itérateur.
Le problème avec le while, c'est qu'il y a toujours un zozo pour t'insérer un truc entre l'init, et la boucle. Et après le premier, un autre ce dit pourquoi pas moi...
En plus maintenant, en Java au moins, la boucle for est beaucoup plus jolie que le while.
J'aime bien que mes variable soient déclarée au plus près de l'endroit ou elle sont utilisée.
[^] # Re: while / for
Posté par locke . Évalué à 2.
[^] # J'pinaille
Posté par Anonyme . Évalué à 3.
<script type="text/javascript">
[^] # Re: J'pinaille
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
[^] # Re: J'pinaille
Posté par Anonyme . Évalué à 2.
http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.1
[^] # Re: J'pinaille
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
En ce qui concerne le document normalisant du W3C, on notera que text/javascript est indiqué à titre informatif, et non normalisant, puisque cette normalisation sors du champs d'action de la présente norme.
Un lien (http://annevankesteren.nl/2005/02/javascript-mime-type) qui résume bien la bêtise du Web. Une vraie poubelle ce Web, j'en ai la larme à l'½il.
En fait, le fameux attribut peut contenir n'importe quoi. Il suffit que le navigateur sache le prendre en charge. À quand un navigateur supportant le Tcl (comme mis en avant dans la norme), le Perl, le Lisp, le PHP ( :)) ), le Bash !
[^] # Re: J'pinaille
Posté par Anonyme . Évalué à 1.
L'attribut type renvoi à un type MIME. J'aurais du le préciser. Et comme il s'agit d'une syntaxe HTML et pas Javascript, peut-on dire que ça sort de la présente norme ?
[^] # Re: J'pinaille
Posté par Anonyme . Évalué à 2.
2) Ton lien est cassé :-/
# XForms
Posté par nodens . Évalué à 3.
Mais heureusement il y a xforms (éventuellement avec un transcodeur pour générer du javascript pour les navigateurs qui ne le gèrent pas...) ;)
-> http://www.w3.org/MarkUp/Forms/
-> http://www.mozilla.org/projects/xforms/
[^] # Re: XForms
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
# Pour des applications
Posté par Greg (site web personnel) . Évalué à 1.
Meme si personnelement développer du html/javascript et tout se qui va avec me gonfle terriblement !
# Bench pour pc ?
Posté par Julien Chipster (site web personnel) . Évalué à 4.
Quand on voit la lourdeur de FF (firefox) dont l'interface graphique est en JS, on peut se demander légitimement l'utilité d'un tel langage quand on voit (d'une manière générale) la surconsommation abusive de mémoire. Avant avec un 166MHz et 256Mo de RAM il était possible d'aller sur le net et de faire pleins de chose. Maintenant avec des 4GHz On a quoi de mieux ?
Des langages qui mangent une mémoire pas possible ?
Des programmes concu avec les pieds ?
Dans 10 ans pourrais-je toujours aller sur internet sans être obligé d'avoir 5Go de RAM, 20GHz en CPU et 30Go d'espace disque minimum ?
[^] # Re: Bench pour pc ?
Posté par seginus . Évalué à 4.
La technologie évolue, l'ergonomie en profite et évolue avec.
En effet on pourrait faire des sites n'affichant que du texte qui tournerait sur un 486. Mais quel intérêt ?
Aujourd'hui, on a des ordinateurs qui n'ont rien à voir avec ceux que l'on avait il y a dix ans, autant en profiter.
Alors est-ce que dans dix ans, ils faudra 5Go de RAM pour naviguer ? c'est possible, mais ce jour là, les ordinateurs premiers prix seront livrés avec 1To de RAM et ça n'aura aucune importance.
[^] # Re: Bench pour pc ?
Posté par CyrrusSmith (site web personnel) . Évalué à 3.
Pas sùr.
1°) La loi de croissance des composants semble toucher ses limites
2°) La disponibilité en éléments chimiques nécessaires pour doper le silicium et autre procédés de fabrication des puces éléctronique peut diminuer pour certains d'entre eux.
Le nombre d'utilisateurs d'ordinateurs et de composanst électroniques augmente, pas la planète.
3°) Il est dommage de jeter du matériel polluant qui pourrait en core servir. Changer d'ordi tout les 18 mois, ce n'est pas ce que j'apelle du développement durable.
http://www.lesdeveloppementsdurables.com/
[^] # Re: Bench pour pc ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Faux. L'interface graphique est en XUL, et scripté en JS.
M'enfin la (relative) lourdeur de FF n'est pas du qu'à JS, fort heureusement... spidermonkey, l'interpreteur JS, est l'un des plus performant qui existe.
Ce qui est lent dans Gecko, ce n'est pas JS, mais les manipulations DOM (il y a un mapping assez lourd entre les objets DOM C++ et leur representation javascript...).
[^] # Re: Bench pour pc ?
Posté par taratatatata . Évalué à 2.
http://kmeleon.sourceforge.net/
J'aimerais bien un programme aussi bon sous linux, Epiphany n'est pas vraiment un démon de vitesse.. (la faute à GTK?)
# Ca raaaame (enfin ça dépend).
Posté par Christie Poutrelle (site web personnel) . Évalué à 0.
Mais sinon, j'dois avouer que c'est parfois super pratique, et incontournable pour résoudre certains problèmes de dynamisme quand on fait du web!
Bref, c'est une infame bouse à coder, et à débugguer aussi, mais bon, y'a rien d'autre pour faire la même chose malheureusement, alors tant qu'on le fait fonctionner pourquoi pas...
Ceci dit faudrait que j'aille faire un tour du côté des framework googles et autre frameworks plus libre, y'a l'air d'y avoir des choses sympa à exploiter :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.