Reprise du message précédent :
atom.

pls justify yr choice

RSS = fudging mess
ATOM = clear spec, unambiguous content model, not shit timestamps

et la compatibilité ?

Pas entendu parler d'incompatibilités de clients avec atom récemment.

 
J'aurais dit RSS 2.0, tous les readers savent gérer ça.
Edit: ceci est un point de vue de (l)user. Pour un point de vue de dév, Machine a l'air plus compétent que moi.

Tu as des readers qui comprennent pas atom sous la main?

 
Mes collègues ?  

 
Je le rappelle d'être tombé sur un cas, mais je me rappelle plus lequel (maintenant j'utilise netvibes). C'était un client lourd sous windows.

Javascript APIs suck balls, example #42: tu peux pas splicer un array dans un autre directement, t'es obligé de passer par apply et de faire des concaténation d'array pourrites  

 
Overgeneralization, fig 1.

wat

Tiens gatsu, si j'ai 2 blocs je peux utiliser inline-block sur le second pour les mettre sur la même ligne (tant qu'il y a la place) mais le second va pas s'étendre à toute la ligne. En théorie j'ai aussi run-in sur le premier mais s'pas supporté par FF. T'as un moyen dans un coin?

edit: ah fuck run-in marche pas non plus, il transforme vraiment complètement l'élément en inline ton les trucs genre text-align s'appliquent dessus. Fuck.

tu peux appliquer du contexte de formatage sur le block et ensutie ajouter un trick de nicole qu'elle utilise dans oocss :

Le :after avec son content:"x x x x x x x x"; est un trick qui force le display:table à prendre la largeur de son contenu, mais comme le contenu est très long, l'élément arrive au bout mais ne vas pas plus loin (comportement du table en général).

Pour le display:inline-block, je ne suis pas du tout fan, car si les éléments sont en inline/inline-block, il y a forcément un espacement qui correspond au caractère espace entre les 2 éléments. C'est pour cela que je privilégie toujours le float:left;

SPAM ne clickez pas.

 
Un lien skyblog en citation? Sur HFR? Seriously?  
Sont cons ces spammeurs...

Mais crève sous-merde
 
Et en plus ce con a pollué quasiment tout le forum

CSS Multi-column Layout Module = fucking glorious

vous savez si y'a moyen de faire faire des warnings à pycharm sur des appels de fonction ?
 
dans intellij, y' aune catégorie d'inspection "code maturity" et dedans il va mettre des warnings sur Sytem.out etc.
 
là je voudrais des warnings sur print de python et console.log() de JS, parce que j'en oublie régulièrement et ça pète tout en prod.

Je sais pas trop comment c'est possible, mais j'ai le haut de ma page de coupé à l'affichage (le code est bien présent) si j'affiche la page en plein milieu (à l'aide d'une ancre) à cause de mon astuce dégueulasse pour avoir un bloc qui s'étend verticalement jusqu'au bas de son parent (padding-bottom: 2000px; margin-bottom: -2000px; )

Ben c'est normal car un contenu qui est dans un element avec scroll va être scrollé, c'est pour ça que l'astuce padding-bottom/margin-bottom est a proscrire. Et seule la solution à coup de JS ou de display:table/table-cell fonctionne (mais pas sous IE). Il n'y a pas de miracle. C'est comme les gens qui me certifie que l'alignement en hauteur c'est possible en pure CSS, la dernière fois qu'on ma l'a dit, j'ai dit : Je vous mets au défie de faire ce que moi je fais en JS.

 
 
       
 
 
 
Par contre j'ai pas trop pigé le passage sur les Whitespace nodes  

 
J'ai ma réponse : j'utilise modernizr, il me suffit alors de rajouter un nouveau sélecteur commençant par : .no-fontface.

je sais que y'a des pros du JS ici.. qqun peut me donner son avis sur des scripts JS en MP svp ?

ouais

function messageActionAlerte(){
    var actionAlerte=document.forms[0].actionAlerte.value;
    var msg=document.forms[0].message.value;
 
    if(actionAlerte != null && actionAlerte.length > 0){
        if(actionAlerte == "Reserver" ){
            msg=document.forms[0].messageReserver.value;
            }
        else if(actionAlerte == "MettreEnAttente" ){
            msg=document.forms[0].messageMettreEnAttente.value;
            }
        else if(actionAlerte == "Liberer" ){
            msg=document.forms[0].messageLiberer.value;
            }
        else if(actionAlerte == "Deverrouiller" ){
            msg=document.forms[0].messageDeverrouiller.value;
            }
    }
    return msg;
}

Switch case ?
Mais je dois avouer que ce code est quand même dégueulasse

Sérieusement chaque fois que je regarde du code JS dans l'application, j'ai l'impression de remonter dans le temps à une époque où il était certain que Harko n'était le père de personne

Le problème c'est que bien de trop souvent les gens conservent une manière dégueulasse de coder.
Exemple con :  
- la répétition du  document.forms[0]
- l'utilisation du document.forms[0]
- l'accès aux champs par leurs name via notation pointée dégueulasse au lieu de passer par l'id
- code bizarre dans la fonction.

function messageActionAlerte() {
    var form = document.forms[0],
        actionAlerte = form.actionAlerte.value;
    if(actionAlerte) {
        return form["message"+actionAlerte].value;
    }
    return form.message.value;
}

wheeee

function messageActionAlerte() {
    var form = document.forms[0],
        actionAlerte = form.actionAlerte.value;
    if(actionAlerte) {
        return form["message"+actionAlerte].value;
    }
    return form.message.value;
}

Ouais bon chui un peu fatigué hein

J'ai besoin d'un avis d'expert. Question organisation JS. C'est quoi votre politique quand à l'emplacement de votre code JS ?
 
Tout sans exception dans dans des fichiers .js ou pour certains bouts de codes vous tolérez en JS "inline" dans un tag "script" ?
 
Par exemples du code utilisé sur une unique page HTML (et qui éventuellement ne prend sens que sur cette page vu qu'il tape sur des éléments du DOM présent seulement sur cette unique page)

https://groups.google.com/forum/#!t [...] NCZeL1eWq8

ohsnap (Barton est le lead dev actuel de Firebug)

 
Tout dans des fichiers .js chargés après le html. Ca permet au html de se charger vite (et donc la page de s'afficher de suite).
Les scripts inline forcent le navigateur à freezer à cet endroit là.

Scripts inline en bas de page. Parce que faire un fichier .js géant plein de code JS non réutilisable (parce que spécifique à telle ou telle page) c'est pas forcément bien et que faire x fichiers .js est pas bien non plus (augmente le nombre de requêtes HTTP)

 
Faire plein de fichier js ça veut pas dire en charger plein. Il suffit de copier tous les fichiers js dans un seul fichier que le serveur va servir contenant les bons scripts par page, en le minifiant et compressant.

et comme ça , tu n'as pas de mise en cache  
 
super

 
Ah bon, et pourquoi donc?
 

Si t'as un fichier différent sur chaque page (parce que tu cat + mini que les scripts de cette page), tu vas devoir cacher un fichier par page. Si t'as 3 pages très visitées (genre HFR avec liste des cats, liste des topics et contenu du topic) ça peut le faire, mais en général c'est une stratégie franchement pourrie.

Donc pour la majorité des définitions de "bien", non ça fonctionne pas "bien".

 
Pour parler précisément on utilise une librairie js (dojo) +  une palanquée de fichiers js customisés  par page. On sert séparément dojo+la partie qui change jamais (1 fichier minifié) et les fichiers custom (1 fichier minifié). La majorité est mise en cache comme elle devrait, l'autre ne l'est jamais, mais au vu de la volumétrie ça le fait quand même.
 
Bref dire que le cache marche pas c'est faux, dire que l'utilité de ce setup dépend de la tronche du site c'est vrai.

sauf que ce n'est pas la solution que tu as décris un peu plus haut

là, tu en as deux ( dojo et le reste )

Quand a servir un fichier custom par page, ce n'est pas mieux que le code js en bas de page