Re...
Florent V. a écrit :
Cette histoire de « plus propre » et « valide » est un peu une hallucination collective d'enthousiastes des standards W3C. 
Si on regarde la spécification HTML ou même XHTML, les iframes sont tout à fait valides... avec un doctype Transitional. Le fait d'utiliser une ou des iframe(s) est justement un motif pertinent d'utilisation d'un doctype Transitional.
Ok, le doctype "Transitional" est donc adapté à l'utilisation des "iframe", c'est une très bonne info, merci !
Au fait, pour être franc, j'ai essayé de me renseigner sur les différents doctypes existants et de leur particularités, mais j'ai le plus grand mal à bien saisir leur différences et l'importance de celles-ci... bref, je pattoge grâve avec ces notions
Florent V. a écrit :
Quant à la notion de propreté, ça ne veut rien dire. On a par contre :
- la lisibilité du code HTML (sympa pour le développeur/intégrateur, et pour sa productivité) ;
- les qualités et défauts des solutions utilisées ;
- la robustesse des solutions utilisées.
Pour ce qui est de la lisibilité du code, je tente de respecter certains principes dont, notamment, l'insertion des commentaires au début de chaque bloc de code, afin de faciliter la comprhéension de leur rôle, et aussi pour me souvenir, plus tard, les raisons de certains choix...
Ceci-dit, il est souvent assez difficile de rester simple et informatif sur des petits commentaires, étant entendu qu'il est déconseillé de surcharger inutilement le poid du fichier avec trop de données "invisibles".
Concernant la qualité et défauts des solutions utilisées, là il n'y a pas de mystère, seules l'expérience et le retour des internautes permettent de faire les bons choix selon ce qu'on cherche à faire et, de ce point de vue, j'avoue que je ne suis pas très bien armé en la matière, c'est pourquoi je me tourne vers des développeurs bien plus expérimentés que moi, en venant vous soliciter ici par exemple...
Enfin, la notion de "robustèsse" est, elle aussi, un peu floue dans mon esprit, car elle sous-entend un aspect d'éfficacité, voire même de performance, en tout cas de fonctionnalité quelque soit le contexte ou, du moins, dans le plus grand nombre des contextes possibles... bref, très difficile, pour ne pas dire problèmatique ou carrément laborieux, de concevoir un site "robuste" lorsqu'on manque d'expérience et de recul sur les différentes techniques existantes...
Florent V. a écrit :
- object c'est plus gratifiant pour l'ego des enthousiastes des standards (qui ne lisent par contre pas les spécifications qui définissent ces standards 
) ;
- iframe c'est aussi bien sur le principe et beaucoup plus utilisable dans la pratique.
On gardera donc des iframes, sans hésiter.
Ok, reçu 5/5
Florent V. a écrit :
Il me semble qu'une solution en Ajax te permettra juste d'inclure du code, pas une page complète.
C'est bien le cas dans ce que je cherche à faire pour l'instant...
Florent V. a écrit :
- une nécessité très forte de ne faire que des rechargements partiels de pages (si c'est juste pour du confort parce que « c'est plus sympa pour le visiteur », oublier cette fausse bonne idée) ;
Oui, c'est exactement la raison qui m'incite à m'intéresser à des solutions d'intégration dynamique des données, sans avoir à recharger toute la page à chaque fois.
Pour être un peu plus concrèt, il se trouve que je développe un squelette pour le
Cms francophone Spip, dont vous pouvez découvrir le site de démo en suivant le lien qui se trouve en bas de ces messages.
En fait, je propose un calendrier avec le squelette, qui regroupe par date l'ensemble des contenus publiés sur le site.
Le problème est que lorqu'on veut naviguer sur les différents mois, précédent ou suivant, toute la page se recharge à chaque fois, ce qui est très lourd et qui empêche d'afficher rapidement le calendrier situé à plusieurs mois d'écart que celui qui est affiché... bref, c'est trop lourdingue
Donc, la solution que j'ai adopté pour l'instant, et que j'ai réussi à mettre en place et à tester dans la version de développement, est l'utilisation d'un "iframe" donc, sauf que, selon le nombre de jours et le début du premier jour du mois, le calendrier peut occuper 5 ou 6 lignes (rangées) et, du coup, comme le "iframe" ne s'adapte pas automatiquement à la dimmension du contenu, il arrive que la date du jours soit masquée sous le "iframe", ce qui est plutôt embêttant...
Voilà pour l'explication du cas concrèt, maintenant il faut que je trouve la meilleure technique possible, "robuste" dirons nous
, pour autoriser une navigation plus souple et rapide dans le calendrier, sans avoir à recharger l'ensemble de la page à chaque fois...
Alors, soit j'adopte une solution JavaScript permettant de redimenssionner dynamiquement le "iframe" selon le contenu, en suivant tes propositions Florent, soit une autre solution JavaScript de type Ajax pour ne changer que le code du calendrier (méthode que j'ai essayé aussi, mais ça pose d'autres problèmes que je n'ai pas réussi à corriger)...
Bref, à moins d'une solution miraculeuse sans JavaScript, je ne sais pas bien comment faire pour faire simple et "robuste" (j'ai décidement bien aimé ce terme
)...
Merci en tout cas pour votre aide, ça m'a déjà permis de mettre un peu d'ordre dans les différentes solutions envisageables, reste à savoir quelle serait la meilleure pour mon cas de figrue...
à+
PS. Oups, je me rends compte que j'ai réussi à faire une belle tartine de blabla... désolé 
