A > nan, c'est mega moche
B > je le fais de temps en temps, mais très rarement ; trop de mélange "données / présentation"
C > j'ai tendance à faire ça, quand mes templates sont en PHP (ça arrive sur certains projets ; sur d'autres, c'est fréquemment du Twig -- là où on te disait "smarty" plus haut, la solution moderne serait plutôt "twig").
Passer par un moteur de templates autre que PHP te rajoutera souvent des features sympa, comme, pour n'en citer que deux :
* Des flags te disant, dans une boucle, si tu es sur la première ou la dernière itération (Twig fait ça, c'est grave pratique dans certains cas)
* De l'échappement HTML automatique -- sur les portions de code que tu as montré, tu devrais t'assurer de passer toi-même par htmlspecialchars() (et ses 3 paramètres, pour aller jusqu'à l'encodage) quasiment à chaque fois que tu veux réaliser une sortie
Donc, version résumée :
* Dans le cas "général" sans contexte ni rien (le cas ici) : Twig comme moteur de template
* Dans le cas de templates en PHP : option C
Godzil (./4) :
D'ailleurs parler d'inclusion d'HTML dans du PHP est conceptuellement faux, on ajoute du PHP dans du HTML
A partir du moment où tu as du PHP à exécuter, le fichier entier passe par l'interpréteur PHP ; donc, conceptuellement, tu fais un peu passer ce que tu veux (ici du HTML) à la moulinette PHP.
flanker (./5) :
D) utiliser un moteur de template comme SmartyE) utiliser Python + Django ou Ruby + Rails
D > En 2014, plutôt que Twig que Smarty (smarty c'était "le" truc dans les années 2000 ; et encore, plus première moitié / milieu que fin -- encore qu'il y a eu du boulot sur smarty 3 qui d'après certains serait pas trop mal... mais absolument jamais utilisé)
E > Ou pour rester sur du PHP, tu peux retrouver pas mal de la logique de Django / RoR dans symfony 2, non ?
Meowcate (./9) :
Mon collègue frontend est partisan du B, quand je suis partisan du C. Quand on travaille sur des projets communs, l'inconvénient est qu'on se retrouve avec des vues qui n'ont pas toutes la même structure, quand ce n'est pas dans une même vue que les deux écoles se mélangent.
A vous de définir une norme de codage et de vous y tenir. Quitte à mettre en place des outils interdisant le commit si le code sur le point d'être commité viole la norme (au début, c'est chiant ; et ensuite tu t'y fais ; et après ça tu configures ton IDE correctement pour que ça soit toujours formaté comme il faut).
Ça peut être une norme "de la communauté" (cf les PSR-2 et 4 je crois, pour PHP ; mais elles ne doivent pas tellement couvrir les vues), la norme "du framework" quand tu en utilise un (comme symfony ou Twig), une norme "entreprise" ou une norme "du projet" ; dans l'ordre décroissant de préférence.
flanker (./11) :
je suis sûr que squalounet pourra te faire un long topo sur PHP Storm
PhpStorm c'est le bien
Pour des vues, encore, c'est pas là que ça apporte le plus de bénéfices ; tu as au moins l'auto-complétion sur HTML (et Twig je crois, maintenant) ; et pour du HTML, tu as bien sûr le support Emmet ( http://docs.emmet.io/ ) \o/
flanker (./11) :
Son avis pourrait être intéressant, vu qu'il fait ça toute l'année.
Je fais peu de front "pur", en fait ; j'en ai même rarement vraiment fait : je suis plus "backend" de cœur ^^
Mais quand j'en fais, ça revient en gros à ce que j'ai résumé ici.
(sujet qui va s'ajouter à mes sujets ; donc je reviendrai par ici s'il y a des questions / commentaire ^^ )