Le design d’un site web full CSS commence entrer dans les moeurs, mais il reste toujours certaines choses qui semblent un peu plus simples grer avec des tableau. Cet article propose deux mthodes pour concevoir un design CSS fluide avec des bords arr…

Comme ça, il suffit d’ajouter les background multiples pour les navigateurs prenant en charge cette fonctionnalité et les autres feront chauffer le javascript ;) }

j’ai rencontré le pb que tu stipules sur le choc des JS, avec PhP nous pouvons solutionner pas mal de situations.

Pour le moment je surveille ça avec impatience “Telamon is the only WYSIWYG” http://bdn.backbase.com/blog/f.....ax-builder

Néanmoins, je suis convaincu que des exemples en ligne tout frais moulus avec plusieurs scenarios et téléchargement à la clef, reste la solution pour péréniser ta démarche, je construis quelque chose dans ce sens en ce moment.

Parce-que du site qui explique tout ça manque pas, mais des sites qui fournissent tout, ben heu .., y sont pas légion.

Ce n’est que mon avis d’intégrateurautididactchevroné, j’aime quand même beaucoup ta démarche Laurent.

cordialement

@+

Mais bien sûr, ce degré de maitrise n’intéressera que les intégrateurs professionnels, et uniquement dans le cadre de projets qui le méritent. ;)

Déjà, il faut bien comprendre que ces solutions consistent uniquement à générer du balisage HTML (ou plutôt créer des noeuds éléments dans l’arbre DOM du document). Ainsi, pour le deuxième exemple de la solution indiquée le code bla bla est transformé en bla bla. Ce n’est pas forcément problématique, mais il faut bien le garder à l’esprit car dans certains cas ça peut être problématique, surtout si on oublie cette information. Je pense par exemple à l’interaction avec d’autres scripts sur la même page qui seraient censés agir sur les mêmes éléments.

Ensuite, comme on a pu le voir à travers les différentes solutions HTML/CSS évoquées (celle présentée par Bruno, celle indiquée par Guiral, celles que je présente dans mon article…), on est obligé de faire du très spécifique côté balisage HTML afin d’arriver à nos fins. Ce qui signifie que si le design change, il se peut qu’on doive changer le balisage HTML. C’est le même problème avec les scripts JS (qui, je le rappelle, créent ce balisage à la volée): si le design change, il se peut qu’on doive changer le script.

Si on voulait une solution Javascript (ou pas Javascript, d’ailleurs) à l’épreuve des flammes, il faudrait un balisage de fou avec 9 ou 10 éléments (div) imbriqués.

Bref, dans tous les cas c’est compliqué et il y a des limites. Si on part sur un tutoriel ou un script existant, il se peut qu’on se retrouve bloqué car le balisage proposé par le tutoriel ou généré par le script ne répond pas aux besoins du design. À vrai dire, du point de vue de la facilité d’adaptation je crois que c’est le tableau à neuf cellules qui remporte la palme (quoi qu’il ait lui aussi ses limites…).

Cette solution javascript est vraiment intéressante car elle permet d’évacuer du balisage html les balises superflues. Merci pour le lien :) }

La désactivation du javascript par les utilisateurs est de moins en moins courante, il y a a sur la toile pléthore de scripts pour faciliter la tâche. Un exemple parmis tant d’autres: http://www.smart-com.com.mx/De.....ss-et.html

Et puis si le JS est désactivé, tant pis, il y a pleins d’alternatives pour afficher un rendu correct.

On va pas se pendre si une minorité d’oficionados antijavascript n’a pas ses jolis coins arrondis.

@+

Effectivement ta solution et tous les exemples que tu donnent sont très intéressants. Ils me font penser qu’au début on galère pour trouver une solution qui fonctionne sans être difficile sur l’élégance, et puis on se rend compte qu’il existe une foultitude de solutions, assez fines pour parvenir à faire des structures fluides à coins arrondis ;)

J’espère que HTML 5 ne va pas casser cette souplesse que nous procure ce bon vieil XHTML 1.0 ^_^v

Tu disait : “que cette surcharge se fasse avec des DIV ou des TABLE-TR-TD, ça n’a pas une grande importance, si?”

C’est vrai qu’on pourrait se dire que tant qu’à faire des surcharges autant boire le calice jusqu’à la lie et mettre des table tr td… Mais bon, je trouve qu’avec les solutions présentées ici et celles que tu donnes (et celle de Guiral également) il y a pas mal de matière pour s’affranchir des tableaux :)

Pour ma part, je ne suis pas fan non plus de la multiplication des DIV. Mais il faut bien comprendre que tant que nous n’aurons pas la possibilité d’utiliser plusieurs images d’arrière-plan pour un bloc donné (prévu pour CSS3, donc peut-être utilisable en production dans 6-7 ans), il y aura forcément une surchage du balisage HTML.

Maintenant, que cette surcharge se fasse avec des DIV ou des TABLE-TR-TD, ça n’a pas une grande importance, si? À complexité égale, j’utiliserai sans doute des DIV si la solution est robuste… mais si la structure en DIV devient plus complexe que le classique tableau à 9 cellules (ou le tableau simplifié à 4 cellules, d’ailleurs…), j’opterai sans hésiter pour un tableau de mise en forme.

(Juste en passant: le premier qui dit «accessibilité» est invité à réviser ses classiques. ;))

Bruno, j’avais tenté une solution «synthétique» sur ce sujet. Ça t’intéressera peut-être d’y jeter un oeil. http://web.covertprestige.info.....mages.html