Et enfin, pour Firefox, je ne vois pas en quoi le fait de cliquer sur le champ et que ça ouvre le finder (ou l'explorateur, bref), est anti-W3C ?! C'est un comportement presque normal … Safari fait la même chose et il me semble qu'Opera également.

Bah non
je vient de refaire des test sous tout navigateur et je confirme:

- IE, FF2, Opera n'ouvre pas la fenêtre de choix de fichier lors d'un clique sur le champ (bien sur il y à la bouton à coté).
- Par contre FF3 nous re-invente la roue ce coup-ci lors d'un clique sur le champ, il ouvre la fenêtre "parcourir" et de plus, pas moyen de lui faire manger des width sur la taille du champ de type file, coté CSS

Si c'est pas du non W3C ce bazard.....


Enfin bon, je vais voir pour leur laisser un message afin d'espérer une mise à jour là dessus...

Si tu regardais attentivement la spécification du W3C sur le file select, tu lirais

This control type allows the user to select files so that their contents may be submitted with a form. The INPUT element is used to create a file select control.

et un peu plus bas

The control type defined by the input element depends on the value of the type attribute :
[…]
file Creates a file select control. User agents may use the value of the value attribute as the initial file name.

Même si on trouve l'attribut style sur tous les éléments input, l'apparence des formulaires est laissée au bon vouloir des navigateurs.
Donc ce n'est pas anti-W3C comme tu peux le dire. Il faut considérer un input type file comme un seul élément (champ + bouton compris), comme une checkbox, ou autre chose.

Pour rappel, Safari fait comme Firefox actuellement (ou Firefox fait comme Safari plutôt, car Safari le faisait avant).

Je te signale aussi que ça ne sert à rien d'essayer de styliser les formulaires avec du CSS. Pour le positionnement, oui, pour le style, non. Je te redirige sur un article d'Alsacréations : Comment ne pas styler les éléments de formulaire, telle est la question .

Édite rapide : juste pour donner un autre exemple. Safari ajoute le redimensionnement manuel des textarea, et c'est pas anti-W3C. Il respecte les attributs cols, rows, et style, mais tu peux redimensionner ton textarea comme bon te semble. C'est un plus pour les utilisateurs.

Même si on trouve l'attribut style sur tous les éléments input,

[...]

Je te signale aussi que ça ne sert à rien d'essayer de styliser les formulaires avec du CSS. Pour le positionnement, oui, pour le style, non. Je te redirige sur un article d'Alsacréations : Comment ne pas styler les éléments de formulaire, telle est la question .

J'ajouterais que c'est tout particulièrement vrai pour l'input type file. J'avais fait des expériences dans ce sens sur la plupart des navigateurs répandus et il en ressortait que c'est le plus capricieux et le plus variable d'un navigateur à un autre. Et effectivement, le fait qu'il se présente sous la forme d'un champ texte et d'un bouton est simplement une nécessité imposée par les systèmes d'exploitation actuels, mais n'est en rien une norme sur laquelle on peut s'appuyer (ceci expliquant en partie cela). Ce n'est donc pas la peine de brailler si on ne peut pas agir sur son apparence à sa convenance, cela n'est pas normé.

merci pour les infos

C'est vrai que mon expression anti-W3C n'est pas adapter en faite... ?:

Moi dans mon optique je conçoit quand même que le champs de type file devrai permettre à l'utilisateur de rentrer lui même à la main le chemin vers son fichier. De plus définit une longeur pour ce type de champ devrai être possible comme pour les "select" et autre "input"

Enfin bon, moi ce que je constate c'est que sous opera et IE, on peut le faire alors que sur FF3 on est coincer... Sinon on à l'attribut size cote html mais bon, c'est bizad qu'ils aient pas suivit le principe des input type text,...

vivement une uniformisation de cette gestion de input... J'ai quand même poser la question chez mozilla pour voir ce qu'ils en pensent... Je vous tiendrai informer

ok le bug etait dejà declarer chez mozilla et est en court de traitement...

Sinon je voulai savoir pour le traitement d'un image uploadé, comment faire en sorte de verifier via getimagesize(); si le fichier est bien une image, sans avoir l'erreur de type E_WARNING

J'ai bien une idée mais je ne suis pas sur de la syntaxe

if(is_array(@getimagesize($image)))

si quelqu'un peut me confirmer
merci d'avance.

Amuse toi avec set_error_handler() et restore_error_handler() .

oki merci

Sinon comment fait on pour intercepter l'erreur de depasement de taille du fichier au vis à vis de <input type="hidden" name="MAX_FILE_SIZE" value="3145728" />

Quand je soumet un fichier de bonne taille, mon formulaire part bien. Ma value post sur le bouton envoi du formulaire est détecter... Par contre si je soumet un fichier trop grand, ma page se recharge mais POST et FILES ne me renvoie rien Je trouve rien non plus dans les en-têtes...
(Sous opera, plantage...)
voici mon script simplifier:

<?php

if(isset($_POST['envoi']))
{
   echo 'coucou'; // lorsque je soumet un grand fichier, je rentre pas ici
}

?>
<html>
<body>
<form method="POST" action="30.php" enctype="multipart/form-data">
<input type="hidden" name="MAX_FILE_SIZE" value="500000" />
<fieldset>
<legend>Envoi de fichiers</legend>
<label for="photo">Photo :</label><input type="file" name="photo" />
<input type="submit" name="envoi" value="Envoyer les fichiers" />
</legend>
</fieldset>
</form>
</body>
</html>

Si quelqu'un peut me dire comment faire pour que je puisse traiter cette erreur et afficher un avertisement comme quoi le fichier est trop grand?

Merci d'avance

Pour ta question je ne sais pas encore. En revanche, attention, tu fermes deux fois la balise <legend> (après le input type submit).

oki c'est corriger

par contre ce que je constate, c'est que PHP via la variable $_FILES gere normalement cette erreur cf ceci

alors pourquoi POST me retourne un tableau vide à soumission du formulaire ???

Si quelqu'un peut m'aider

Il existe un tout petit paragraphe là dessus dans la doc :
http://fr.php.net/manual/fr/ini.core.ph ... t-max-size

Dans le cas où la taille des données reçues par la méthode POST est plus grande que post_max_size , les superglobales $_POST et $_FILES seront vides. Ceci peut être surveillé de différentes façons, e.g. en passant une variable $_GET au script qui traite les données, i.e. <form action="edit.php?processed=1">, et ainsi vérifier si $_GET['processed'] est défini.

oki merci

j'ai du sauter un chapitre...
Par contre ce qui est donnage c'est que l'on perdent toutes les valeurs de POST... l'utilisateur devra donc ce retaper toutes les infos du formulaire...

je vais voir si possible de definir le form à GET tout en ayant un input type file car il me semble que l'on est restraint à POST...

Ya pas de quoi, c'était quand même bien caché !

J'ai essayer via un FORM à GET mais pas moyen car le type file est apparament restreint à POST sinon il ne tient pas compte de MAX_FILE_SIZE....

Si au cas ou quelqu'un à une idée à soumettre pour pouvoir conserver les autres saisi de mon formulaire ?

Je crois que tu n'as pas compris que Savageman essayait de te dire.
La méthode de ton formulaire reste à post mais dans l'action, tu ajoutes une variable get : Et ton code PHP : Note que c'est un peu bête, car c'est facilement crackable. En revanche, si tu envoies en input type hidden la valeur de MAX_FILE_SIZE, elle apparaîtra forcément dans le tableau $_POST, et le test reviendrait au même (mais moins facilement crackable).