Reprise du message précédent :

 
 
.text{
font-family: Arial, Helvetica, sans-serif;
}
 
.blue{
color:blue;
}
 
.red{
color:red
}
 
<p class ="text blue">smrigjomhr</p>

on commence par déjà pas foutre des noms de couleurs dans ses noms de classes

Dans l'idée, il a pas tord :
Mais :

• le design en absolute simplifie quand meme la vie dans certains cas, meme si un design fluide est a preférer quand c'est possible
• les hacks sont stupide : ils ont été inventé pourquoi si ils ne servent a rien ?
• on evite de faire des classes de styles qui s'appellent bleu ou rouge . Parceque si par la suite on souhaite changer le bleu par du vert ou va avoir .bleu{color :green} .  

 
bref, très bon conseil dans l'absolu, mais pas forcement appliquable au monde réel

Les hacks servent à avoir des pages exactement identiques d'un navigateur à l'autre, ce qui n'est pas forcément un bon objectif.

explique ca a un client , qui arrive avec son psd et qui dit "il n'y a plus qu'a mettre ca en ligne"

Je dirai que le gars c'est un rigolo sur les hacks.
 
Ok, j'arrive a faire une putain de mise en page tordu sans hack (des systèmes de boites, de blocks et autres tralala exotiques).
Donc je fais ma tambouille sous FF, ca fonctionne parfaitement.
Je la teste sous Safari et Opera, Et ho miracle ca fonctionne aussi parfaitement.
Le seul IE c'est IE , tu es obligé de faires des hacks, à la fois pour le problème du (height, minheight), à la fois pour le problème du haslayout, et aussi pour l'appplication du contexte de formatage.
 
IE

si il y avait minwidth , minheight , ... sous IE, ça simplifierai mes mise en page

le problème étant que lorsqu'un client veut voir une charte intégrée, il s'attend à ce que ça fasse pareil sur son IE4 sur mac os 8, sans que t'aies à lui expliquer pourquoi tu peux pas....
le top étant bien évidemment d'avoir un graphiste qui connaît bien les contraintes du web, mais si ça poussait sur les arbres, ça se saurait.

 
Je cherche du boulot pour debut juin, si vous entendez parler d'un truc...
 
(XHTML, CSS, XML, Javascript, "Ajax", PHP (MVC), Flash, Actionscript, Photoshop,Illustrator,Inkscape)

Ben par chez moi dans ma boite
cf le post que j'avais ecrit il y a quelque temps

Bosser avec Gatsu35
 
Mais c'est début juin hein

Les commentaires conditionnels pour IE devraient suffire à éviter les hacks dans une grande quantité de cas, non ?

T'inkiete dans ma boite ca embaucje toujours

Gérer 2 feuilles de style est quand même plus chiant que d'en avoir qu'une seul avec le hack placé au bon endroit.

 
Hum, ça se discute. D'abord les hacks ne sont pas forcément évidents ou bien documentés, puis sont plus susceptibles de "casser" avec une mise à jour du navigateur. Par ailleurs, la feuille de style complémentaire devrait se réduire au strict minimum.

Ben ouais, quand on fait des CSS proprement et intelligement pensées, on a pas besoin de hacks. Sauf pour IE

En général la feuille IE est très courte, elle représente même pas 10% de la feuille principale.
Mais c'est surtout la conception initiale qui fera la décision (éviter de compter sur la largeur des blocs pour leur placement par exemple).

Je suis pas d'accord
 
C'est surtout qu'il y a des éléments de design ou des conceptions qui demandent un positionnement absolu, c'est un outil comme un autre qui a parfaitement sa place dans un design fluide (idem pour fixed)  

Parce qu'on avait pas mieux

De mon point de vue, c'est surtout parce que ça n'aide pas à comprendre le rôle de l'élément
 
Et qu'on peut se retrouver avec des modifications ayant des impacts imprévus parce que la distribution et la hiérarchie des classes est mauvaise

Tu lui expliques pas que tu peux pas, tu lui expliques que c'est pas le même prix.
 
Tarif de base pour les navigateurs modernes (IE6+, Firefox 1.0+, Safari 2.0+, Opera 9+), +50% pour IE5/Win, +60% pour IE5/Mac, +75% (du prix augmenté précédent) pour IE4/NS4, après si il veut il peut, mais c'est pas gratuit  
 
Et c'est le genre de trucs qu'il faut spécifier dans le contrat, la scope du projet initial et les suppléments

Bon, les experts en formulaires, un truc à la con.  
 
Le but du jeu c'est de faire un formulaire en plusieurs étapes (plusieurs pages de saisie qui se suivent), avec validation et écriture dans la base uniquement à la fin.
 
A chaque étape, on peut revenir en arrière, et retrouver sa saisie précédente, et la modifier.
 
Dans certains écrans, on a des textarea "libres" qui ne sont limités que par la taille.
 
Problème : comment gérer proprement à la fois le réaffichage et l'insertion dans la base de données?
 
Cas concret : dans un textarea a été saisi (par exemple) un "é". Au retour en arrière vers cet écran, pour éviter tout soucis, on fait un htmlentites, ce qui donne dans le source "&eacute;". Si l'utilisateur revalide, pouf, je n'ai plus "é" dans ma variable de session, mais "&eacute;"...
Ma solution actuelle : html_entity_decode obligatoire sur ces champs au moment de la validation pour insertion dans la base...
 
 
Il y aurait pas une méthode plus simple que je n'aurais pas vue?

on fait moins les malins!
...bon finalement je vais mettre en session un html_entity_decode de la saisie, et puis c'est tout...

 
T'as pas l'impression que ces deux parties sont un peu opposee?

re bonjour
j'aimerais savoir s'il est possible d'optimiser le code suivant (javascript de moi, patapé)

Tu utilises l'UTF-8 et paf ya tout qui marche  
 
 

Je trouve pas. Avoir une feuille de style propre est quand-même beaucoup plus simple et facile à lire. Avoir une autre feuille de style pour IE (au pire une pour chaque version), c'est nettement plus lisible. Ca t'oblige juste à ouvrir deux fichiers (omg).

 
Oui, enfin si tu modifies le "é" de l'exemple par une fermeture de ton input/textarea tu vois le problème...

Euh oué mais non non, je vais pas en plus m'amuser avec ça...

Je construirais un tableau de pattern en dehors de la boucle array pour eviter d'avoir à les ré-instancier à chaque boucle sur array ( et du coup faire un pattern[j].exec(array[i]) ).
Et perso (bien que ça change rien) j'ai tendance à préférer le string.match(regex) au regex.exec(string)

ok, mais ça m'oblige à faire une autre boucle (en dehors certes) pour construire ce tableau de pattern.
quel est le problème de ré instancier les patterns à chaque boucle?

J'ai une petite question, concernant le tableau $_FILES[].
 
Dans le type, c'est inhérent au navigateur et non pas au serveur, right?
 
Parce que sous IE j'ai image/pjpeg, alors que FF me sors image/jpeg

 
C'est probablement coûteux.

Bin dans un cas tu instancies j objets regex, dans l'autre i*j ...

je viens juste de le comprendre.
merci beaucoup

d'ailleurs si tu veux pas faire une boucle "en dehors" il suffit juste d'inverser les boucles i et j pour arriver au même résultat.

strip_tags

oui  
==> ne pas lui faire confiance ( aps plus qu'a l'extension du fichier )

Ca c'est clair (bon c'est pour un back office interne, mais bon), y'a moyen d'analyser l'entête du fichier?
 
De toute façon, il me semble que le type est défini par le navigateur grace à l'extension  

en voilà un qui a bien lu le problème, tiens.

 
en php il y a une fonction mimetype  
 
mais la encore , ca marche moyen ( certains ppt sont reconnus comme des word )  
 
J'ai pas encore trouvé de solution miracle

Ça marche pas pour enlever les </textarea> ?

fopen + fread pour lire le contenu du fichier
 
imagecreatefromstring pour parser le fichier en tant qu'image via GD, GD détecte automatiquement le type de l'image
 
image_type_to_mime_type sur l'image récupérée pour obtenir le MIME, si imagecreatefromstring renvoie FALSE alors l'image n'a pas pu être parsée (format non reconnu, image corrompue, type d'image non supporté)
 
Faire gaffe à ce que ton build PHP/GD gère bien tous les types d'images dont tu as besoin (surtout JPG)