un fichier php comprenant du html est systématiquement bordélique.

Comme je l'ai dit juste au dessus, je ne suis pas d'accord

C'est vrai, j'approuve, surtout quand on y rajoute une once de javascript :

Et comme ça :

<?php
  $prix_max = ($_POST[prix_max_bar])? $_POST[prix_max_bar] : "Prix max"
?>
<input type="text" name="prix_max_bar" value="<?= $prix_max ?>" onFocus="if(this.value=='Prix max') this.value='';" onBlur="if(this.value=='') this.value='Prix max';" size="7"> &euro;

Mais comme le soulève naholyr, je préfère un fichier quelque peu bordélique mais avec une coloration syntaxique à peu près correcte plutot qu'un

echo "<option value="$r[id_secteur]">";

qui te dégage toute différenciation entre les éléments, les attributs, les valeurs et les variables php... et en plus il faut échapper toutes les quotes, génial ...

Tu aborde un autre problème : extraire les variables des chaines

Là ça en devient du masochisme
entre

echo "<option value=\"" . $r[id_secteur] . "\">" . $r[secteur] . "</option>";

et

?>
<option value="<?=$r[id_secteur] ?>"><?=$r[secteur] ?></option>
<?

mon choix est vite fait

C'est vrai, j'approuve, surtout quand on y rajoute une once de javascript :

Et comme ça :

<?php
  $prix_max = ($_POST[prix_max_bar])? $_POST[prix_max_bar] : "Prix max"
?>
<input type="text" name="prix_max_bar" value="<?= $prix_max ?>" onFocus="if(this.value=='Prix max') this.value='';" onBlur="if(this.value=='') this.value='Prix max';" size="7"> &euro;

Le javascript reste quand même quelque chose d'assez indigeste à partir du moment où il transforme une balise HTML relativement courte et lisible en un truc monstrueux qui fait parfois (trop souvent) quelque chose de deux lignes.

à moins là aussi d'externaliser le code javascript, mais là à mon avis ça revient à couper les cheveux en quatre... c'est vrai qu'il est plus "propre" de différencier les balises qu'on doit "javascripter" et de leur rajouter des gestionnaires d'évenements une fois que la page est chargée, moi je ne suis pas fan de cette méthode à moins qu'on ait vraiment besoin d'une fonction qui ne peut pas tenir en une ligne...
Et puis là aussi il y a plusieurs façons de faire :
soit quelque chose du type onclick="mafonction();", soit comme je l'ai dit plus haut faire une fonction sur le body onload qui se charge des eventhandlers...
Et si le code propre n'était pas si différent que ça de l'usine à gaz?

c'est vrai qu'il est plus "propre" de différencier les balises qu'on doit "javascripter" et de leur rajouter des gestionnaires d'évenements

En parlant de ça, n'est-il pas possible d'intégrer du javascript via du CSS ?
Bon ok, c'est plus vraiment du CSS dans ce cas là, mais l'objectif aurait le même résultat : supprimer tous les attributs de la balise html pour les intégrer dans le fichier "CSS" grâce à leur classe ou leur ID.
Ca serait l'idéal pour alléger le code en terme de lisibilité (bon, par contre, ça faciliterait pas la compréhension du code si le javascript fait des trucs délicats).

Un code propre et portable, selon moi, est un code où chaque langage est séparé proprement. Donc, effectivement, je suis partisant de créer des fonctions JS et des eventHandlers pour diminuer l'imbrication HTML/JS

C'est quoi que vous appelez les eventHandlers ?

euh, mettre du code javascript directement dans le css je ne pense pas que ce soit possible... encore heureux, mes feuillles de style sont les seules choses propres de mes sites
Par contre voici le principe pour "faire comme si" (j'ai plus le code sous la main, mais j'avais utilisé quelque chose comme ça...):
tu parcours tous les tags de ton document et quand le tag a une classe particulière tu lui appliques un gestionnaire d'évenements ou n'importe quoi d'autre
C'est propre mais c'est lourd : le top serait d'avoir une fonction getElementByClassName similaire à l'actuelle getElementByTagName, mais libre à toi de l'implémenter

Edit : Les eventHandler sont littéralement des "gestionnaires d'évenements", c'est à dire onclick, onmouseover, onfocus...

Je pense que c'est une mauvais idée de gérer le CSS avec du JS tout simplement parce que tu ne vois pas quel est le style de ta page tant qu'elle n'est pas générée.

Je ne pense pas que mettre des classes dans le code HTML allourdisse vraiement le code. Au contraire, ça permet de s'y retrouver un peu.

Sinon, un eventHandler, c'est un écouteur d'événement.

Au chargement de la page, tu dit à JS "Dès qu'un clic/survol/... sur une balise TD ... dès qu'un clic/survol/... sur un id untel"

C'est comme si tu faisais un onClick/onMouseOver/... sur toutes les balises TD, sur les id untel, mais généré au chargement de la page et sans alourdir le code.

Mais c'est plus compliqué à coder

c'est vrai qu'il est plus "propre" de différencier les balises qu'on doit "javascripter" et de leur rajouter des gestionnaires d'évenements

En parlant de ça, n'est-il pas possible d'intégrer du javascript via du CSS ?
Bon ok, c'est plus vraiment du CSS dans ce cas là, mais l'objectif aurait le même résultat : supprimer tous les attributs de la balise html pour les intégrer dans le fichier "CSS" grâce à leur classe ou leur ID.
Ca serait l'idéal pour alléger le code en terme de lisibilité (bon, par contre, ça faciliterait pas la compréhension du code si le javascript fait des trucs délicats).

MERCI !!!
À moi aussi ça me parait absolument naturel d'avoir une syntaxe "css-style" pour indiquer les comportements.
Par exemple on pourrait avoir Et ben ça existe : ça s'appelle les "behaviours" (comportements). J'ai pris une librairie qui faisait ça très bien mais uniquement sur les id et classes, j'ai pris une librairie qui parsait très bien le css (qui demandait 2-3 corrections, et à laquelle j'ai ajouté la gestion des expressions régulières dans les valeurs d'attribut, ce qui n'existe pas en css mais qui est bien sympa), j'ai mixé les deux, et ça marche très bien

http://naholyr.free.fr/labo/behaviour/
Dans cette page d'exemple il n'y a pas une once de javascript dans la page elle-même, il n'y a que la déclaration des comportements au début de la page (avec des Behaviour.register comme ci-dessous). L'idéal pour faire du javascript non-intrusif.

La syntaxe exacte pour l'exemple du a.popup serait

J'aime beaucoup ton truc naholyr, c'est ce genre de choses que je voulais voir apparaître dans cette discussion : les trucs de chacun.
Je vais me pencher sur ta solution et la tester un peu.

Par contre sur ta page d'exemple, quelle est la différence entre les deux formulaires ?

Si tu cliques sur un champ du premier formulaire, il se vide. Si tu quittes ce champ sans l'avoir modifié il se remplit à nouveau avec sa valeur d'origine (sauf dans le cas du mot de passe, pour éviter les confusions).

Le second formulaire n'a aucun comportement associé.

Note : pour getElementsByClassName j'ai l'habitude de l'implémenter ainsi Ainsi tout élément de la classe Node (ce qui inclut bien sûr document) gagne une méthode "getElementsByClassName" à qui on peut passer simplement un nom de classe, ou bien un sélecteur de la forme "TAG.CLASSE" pour filtrer également par tagName.
Par exemple document.getElementsByClassName("ul.menu").

Pour ma part j'ai opté pour un mini moteur de template que j'utilises et que j'améliore au fur et à mesure, cela me permet de me concentrer uniquement sur la programmation, laissant le soin au designer de faire sa part de travail sans se soucier d'implenter du code php incompréhensible pour lui (ou eux).
Les possiblités sont infinies; inclusion à la volé de portion de fichier html, changement en cascade, boucle, condition, et cela avec un code allégé et ultra simplifié, par exemple: la valeur assigné à VALEUR (un tableau) sera lu jusqu'à la fin de ce dit tableau.
Ou bien incluera la portion définie entre 'tag' du fichier fichier.tpl.

C'est une solution que je trouve, en ce qui me concerne, pratique; gain de temps de développement, le code html n'est plus ambriqué entre "" et les antislashs aux oubliettes...

Voilà, voilà.
Néanmoins, pour un projet de moindre envergure, la mixité est possible.

Low

Ahah, quand j'ai vu le sujet posté, j'attendais avec impatience le débat
C'est dommage, ça aurait pu devenir un vrai recueil des bonnes habitudes à avoir, mais ça a dérivé.

Vous avez passé beaucoup de temps à parler de l'indentation : des tas d'éditeurs permettent de reformater le code proprement, suivant ses envies (ex : Eclipse)
Donc bon, l'indentation c'est pas le plus important, c'est surtout important pour soit, pour avoir où on en est quand on code à mon avis

Et ce genre de trucs :

while (true == false) {
?>
<option>
<?php
}
?>

beaucoup, dont moi, trouvent ça complètement illisible, tout ça pour gagner quelques millièmes

A mon avis donc, un vrai code maintenable, ça passe donc par une structuration de son code (fichiers séparés suivant le contenu, fonctions, POO...) plutôt que par des petits gadgets de ce genre.

A mon avis donc, un vrai code maintenable, ça passe donc par une structuration de son code (fichiers séparés suivant le contenu, fonctions, POO...) plutôt que par des petits gadgets de ce genre.

tout a fait d'accords,
il est vrai q'une certaine rigueur dans le code permet d'ameliorer la lisibilité
mais le point essentiel reste l'architecture et les regles de nommages
il suffit de bien découper les taches que ce soit avec un MVC ou un systeme plus simple(2 -couches)