Reprise du message précédent :

Va styler des <legend> Avec un span dedans on y arrive, mais y'a toujours IE qui rajoute 6 ou 7 pixels de décalage. Du coup je peux styler les legend comme je veux : http://milleniumstar.tv/candidates/creation.html

autant utiliser des hack CSS
 
 
.maclasse {
   height:300px; /* all */
   //height:300px; /* IE6 et IE7 */
   _height:300px; /* IE6 */
}

... Mouais That's teh mightey hasque

 
ah non....on peut pas dire que ce soit propre...devoir détecter la plateforme dans une techno qui est a priori une abstraction standard de la plateforme, je trouve ça tout sauf propre...
 
c'est bien ce que je déteste dans la prog web : le tout semble être un énorme contournement, on attend toujours les solutions propres...les CSS, le JS, le méchanisme des sessions et tout le bordel que ca génère, je suis désolé, mais c'est pas "propre"...

C'est effectivement pas propre, dans l'absolu. Maintenant de toutes les solutions pour hacker ça, je trouve que c'est la moins moche. J'aime pas trop les hacks, que je trouve assez dangereux car on pourrait très bien se retrouver avec un navigateur qui aurait un bug et s'amuserait à utiliser ce que l'on ne veut pas qu'il utilise...
 
Au moins les commentaires conditionnels sont fiables

+1 pour les commentaires conditionnels

Ouais, mais la faut mettre en cause les clients - IE et consort-, pas la techno.
 
Si tous les navigos étaient au niveau de ff en js et de s3 en css, on ferait des sites deux fois plus pointus

Yo, pb dans le même genre qu'hier, mais pas pareil :
 
J'ai un script vachement long, qui copie plein de fichiers et tout, donc je compte désactiver le timeout php dans le script, et le timeout Apache à la main...
Mais c'est pas dangereux ?
En fait ma vraie question c'est : le bouton "Arrêter" du navigateur arrête bien le script coté serveur hein ?

Quand j'avais pas xDebug et que j'avais une boucle infinie à un endroit, tous les boutons "arrêter" du monde ne suffisaient pas à stopper le script infernal

C'est balot, surtout que dans mon cas, sait-on jamais, ya un risque de saturer le disque dur

Maintenant ça dépend le script et ce qu'il est en train de faire... A essayer en conditions réelles

A partir du moment où ton script est exécuté parce que t'as envoyé la requête HTTP ad hoc, il ira au bout, même si t'es plus là pour écouter la réponse, à ma connaissance.

Je vais mettre 900 secondes en timeout apache déja ça suffira...

Ben, par définition mieux vaut s'attendre au pire, et dans un script qui manipule de gros fichiers...

Ok donc timeout obligatoire.

Normalement, un script PHP est interompu. Lorsqu'on clique sur arrêter, l'agent-utilisateur coupe la connexion avec le serveur. Apache capte, et arrête d'envoyer le reste de la page.
 
Côté PHP, si tu tente un echo(), ça va foirer, et PHP devrait s'arrêter. Maintenant si tu n'affiche rien pendant ton traitement, le script va tourner jusqu'au bout.
 
On peut tester si la connection est coupée avec la fonction connection_aborted(). Mais comme dit, faut d'abord faire un echo sinon pouet...

Ah ok
Dans un truc bien fait, il y aura raisage d'une exception

 
Je préfère les commentaires conditionnels, plus propre et plus facile à maintenir selon moi.
 

 
Bof, dans 95% des sites que je fais il me faut de toute façon une feuille de style en plus pour d'autres problèmes, donc bon.
 

 
Mouais, super maintenable. Et le jour où t'as une nouvelle version qui comprend les choses différemment tu t'amuses super bien \o/

Chacun son avis. Perso je suis plutôt partisans des hacks montrés par Gatsu, et je ne trouve pas que ce soit moins maintenable que d'avoir 1 CSS par browser. Au moins tout est au même endroit et on économise des  requêtes HTTP.

Je répète, ça dépend de la taille du site (donc directement de la taille de la css, si on part du principe qu'un gros site contient plus de templates), et du traffic (auquel cas, économiser les hits est mandatory)

 
Et si on comparait la durée moyenne de vie d'un design de site internet avec l'intervalle de sortie entre 2 versions d'IE ?

Bah tu sais pas faire de CSS, c'est pas ta faute

 
Bah une version de IE tous les 10 ans ca rulez, nan ?
Sachant qu'il n'y a que IE qui a besoin de hack et encore, les hacks sont réfléchis et on sait qu'on doit les utiliser d'avances
Bien entendu quand on sait faire des CSS  

Mouaip... enfin chacun son truc, je préfère la feuille externe, meme si y'a 2 bricoles dedans

pour ma part j'ai juste un div concerné, donc je me vois pas faire une CSS pour ça, je préfere scinder suivant le role de la CSS, par exemple:
- base.css
- form.css
- menu.css

bah SimpleTest a l'air plus complet que phpUnit, mais bon, c'est pas un choix super déterminant.

D'après les docs, les deux fonts des mocks, phpUnit fait des stubs, SimpleTest aussi sûrement.

Mais bon, choisir l'une ou l'autre ne devrait pas impacter ton dev. Il faut juste être a l'aise avec sa lib de test.
Après l'un ou l'autre a pi être des features sympa comme lancer que les tests unitaires ou fonctionnels, ou monter/demonter une base dans un setUp/tearDown, etc

prototype JS sapuduku et c'est pas nouveau
[blabla]
methode each  tousssa toussa
[/blabla]
edit:
Bon ben j'ai dit de la mairde, c'est juste que prototype fait des trucs alambiqués et completement inutiles au niveau du code \/ et donc parfois c'est une grosse merde à comprendre

jQuery rulez

jQuery c'est pour les paydays
Mootools rulez

>> Question con <<
C'est quoi les étapes de conception d'un site web chez vous ? (et leur ordre ! )

Jamais utilisé Mootools, tu lui trouves quoi de bien ?

- super légère (42Ko sous packer) ,  
- super modulaire, genre tu peux configurer ta propre version de mootools et donc ne prendre que 16ko au lieu de 42ko
ya tout dedans pour faire une une appli
Si tu vires tout ce qui est graphique tu tombes à 30ko je crois
- plus complete que Prototype sur certains points (domReady par exemple)
- très rapide.
- facile de coder avec, écriture légère :  
    Mootools :  
    $(monelm).addEvent('click', function() { blabla.. })
    Prototype :  
    Event.observe(monelm, 'click', function() {blabla})

Donc Mootools c'est pour les paydays aussi, vu que ca fait la même chose que jQuery quasiment ( bon sauf pour la modularité, jQuery vient d'un seul bloc, mais t'as le système des plugins qui permet quand même d'ajouter pleins de trucs )

OUais mais t'a rien au niveau grapghique et c'est juste une horreur au niveau de code

 
1- cahier des charges / besoins du client
2- choix de la techno ( langage ,mais aussi besoin ou non d'une BDD )
3- etablissement d'un devis
4- modifier le cahier des charges au fur et a mesure des demandes du client
5- livrer un produit totalement différent du point 1  
6- facturer les correction de bug au prix de nouveaux développement

et au niveau de la conception en elle même ?
Modélisation / graphisme / etc ...

1- Story Board de la page sous Power point (consultant/market)
  - Validation par le client
2 - Montage PSD de la page (Photoshop) (Crea)
   - Validation par le client (consultant qui envoi la page)
3 - Montage HTML (moi)
  - Validation par le client (consultant qui envoi la page)

Sachant que l'étape 2 n'est valable que pour les premières pages du site ou des pages super custom.
Mais lorsque ce sont des pages qui réutilise à 99% des éléments HTML/Graphiques existants, pas la peine de repasser par un maquettage PSD de la page

La 1.6 de Prototype est bcp + souple (par exemple ce que tu montre pour Mootools pour associer un gestionnaire d'événement à un node, ils le font de la même manière maintenant en 1.6).

 
je ne m'en occupe pas ,  je suis une bite en graphisme ( c'est a dire que je peux prendre un psd et l'intégrer, mais surement pas pondre une UI tout seul ). En plus,mon domain, c'est plus les intranet, donc peu de graphisme , mais pas mal de code coté serveur, avec des grosses requetes
 
donc +1 pour gatsu

okay et quand tu repars de ton psd pour le montage html, tu utilises quoi ? Dreamweaver ?

A mon avis il fait "à la main" son code HTML. Il doit faire les découpes des images avec Photoshop ou ImageReady et ensuite à la mimine

ouch, c'est pas un peu chiant ?