http://www.bci-logs.fr/medias/cadre/cadre.htm
 
=> Tout est dans l'url.
 
J'ai un joli truc tout pourrave qui marche bien avec un tableau.
Je veux pareil, mais sans tableau, puisqu'il parait qu'on peut faire (mais moi j'y arrive jamais )

http://www.siteduzero.com/tuto-3-3 [...] #ss_part_1
 
Par exemple...

http://openweb.eu.org/articles/initiation_flux/
tu mets ton beau menu dans un div et voila
pour reproduire exactement le comportement du cadre (c est a dire que ton menu ne bouge pas avec le reste de la frame page) il faudrait par contre qu ie comprenne l attribut fixed  
je sais pas si c est en cours de projet sur ie7 (je l ai toujours pas dl d ailleurs )
 
edit
http://forum.hardware.fr/hardwaref [...] 7190-1.htm
et bien oui le bug est corrigé donc tout est nickel

celui-là ne vas pas. je dois être extensible en hauteur et en largeur. deplus, les bords (pas les coins, les bords) sont impactés aussi par un fond (à cause de la transparence, j'utilise du png32)
 
(le but, c'est de faire un template incluable dans une page, et de taille différente selon là où c'est mis)

je suis sous IE7, mais hors de question d'utiliser des spécificités de l'un ou l'autre des navigateurs.
 
si je veux faire un truc au standard xhtml, c'est pas pour foutre du proprio toutes les deux lignes afin de reproduire correctement un truc faisant en utilisant un plus ancien standard.
 
bref, si y'a pas moyen de faire "proprement", je vais garder ce que j'ai fais. après tout, ça marche, c'est simple, et ça passe au validateur xhtml...

Pour le PNG, je n'ai (malheureusement) jamais trouvé de moyen de les faire passer sur IE s'ils sont placés en background (CSS).

euh position:fixed;
c est du css
donc tout le monde devrait comprendre sauf ie
ce qui est corrigé depuis la version 7
et pour ie < 7 le seul truc que ca fera c est que le menu se deplacera avec ta page si elle a un scroll

IE7 powa

c'est quoi cette histoire de "fixed" ? moi je veux pas fixed mon truc, je veux faire un div avec de jolis contours, comme on peut faire en toute simplcité avec un tableau

je disais ca juste pour reproduire exactement le comportement de la frame
si t as un scroll sur la page principale le menu restera toujours visible
et fixed c est juste un attribut ... pour ton div avec tous les contours que tu veux
lis l article que je t ai donné et apres tu pourras o  a volonté
 
 

mais pkoi vous me parlez de frame ?
 
j'ai pas de frame
 
j'ai juste un tableau, avec des image tout autour de façon à ce qu'il soit "joliement" détouré avec un effet d'ombrage.
 
pour le reste, la page est on ne peut plus normale...

et sinon, ton article ne marche pas dans mon cas : ils ne font que des tableaux de largeur fixe, ou des tableaux de largeur/hauteur variable, mais sans bordures "haut / bas / droite / gauche" (seulement des coins)

t as dit "tout est dans l url"
j ai pas regardé le code et j ai pensé que tu etais en frames stou
 
par contre le "joliment" du biseau trois clics bof

d'où les "
 
moi je suis développeur.
là je m'écrit une lib réutilisable et personnalisable pour mettre de jolies images à la place de mes trucs tout caca

Voilà la version "XHTML" que j'ai pondu.
 
Ca marche parfaitement sous Mozilla, en utilisant la propriété "display" du CSS pour simuler un tableau, mais sous IE... Du moins le 7... C'est, comment dire... Raté.
 
http://magicsite.manga-torii.com/cadre/cadre.htm
 
(je suis en train d'essayer de me dépatouiller pour activer le site... pour le moment il était hébergé sur mon vista béta 2, mais y'a une c**** dans le potage, et du coup ça marche pas -répond au ping, mais ne veut pas répondre sur le port 80-. j'en suis à tenter de remettre en était mon 2k3 serveur, c'est pas gagné, surtout avec les 200 Mo de patchs à dwl depuis que je l'ai éteinds -il était en pré-retraite, faut dire qu'il a un peu 5 ans mon serveur... -)

pourquoi un display en tableau ?
sinon balance ton code on se debrouillera sans le site

Tu peux me dire si tu peux accéder à la page là ?

 
tu l'auras voulu    
 

ok a vue de nez sans les images c est pas evident mais bon
laisse tomber les display:table&co
je te montre vite fait l idee  
 
tu precises un width sur ton div.cadre
donc on va dire que la largeur est fixe sinon je te montrerai comment l elargir dans les deux dimansions
tu n as besoin que de trois images
 
le haut une d une hauteur de 1 ou deux pixels pour le fond du contenu et celle du bas

 
en css tu mets les backgrounds qui vont bien tralala
 

nan, pas possible.
 
j'ai 8 images en tout :
 
4 coins
 
2 images de 1 px de large pour indiquer les bordures haut et bas
2 images de 1 px de haut pour indiquer les bordures droite et gauche
 
je ne dois pas être dépendant de la taille du cadre, ni en largeur, ni en hauteur (sinon ça fait longtemps que ce serait torché... je suis nul en CSS, mais pas à ce point

voilà, mon lien de là-haut marche maintenant
 
comme un con je m'étais planté d'ip sur mon routeur pour l'ouverture du port 80

C'est bien le problème actuel : on continue à rester ancré dans un visuel de tableau... mais sans tableau.
Il va bien falloir comprendre un jour que c'est tout un esprit à changer.
 
Si tu veux "faire du tableau", utilise les tableaux. C'est aussi simple que ça. Et profites-en pour te demander pourquoi tu voudrais t'en passer : par mode ou par réelle philosophie ?
Si un jour tu veux raisonner en éléments (titre, menu, illustration, etc.) et non en cellules et en cloisons, tu auras fait la moitié du travail
 
Bonne chance

Moi on m'a dit, à juste titre, que les <table>, c'était d'un point de vue sémentique, pour afficher des donnés tabulaires.
Moi, je veux afficher une illustration, ce qui n'est en rien une donnée tablulaire.
Par contre, <div> permet de faire des divisions, généralement avec pour objectif de faire de la mise en page d'illustrations.
 
Donc d'un point de vue sémantique, le <table> ici n'a rien à faire.

toujours aussi sage sibelius bonjour    
 
mais bon je lui ai fait sa bidouille me casse pas mon effet  
 

Mouais.
 
Nan, je vais laisser tomber.
Déjà, sous IE7 ça marche pas bien (en bas ça déconne).
 
Mais surtout,j'utilise du PNG32, avec donc de la transparence (et surtout, des dégradés de transparence)
 
Du coup, ça chevauche dans les coins et c'est tout moche

Voilà ce que ça donne (et donc ce que je voulais au départ, avec mon tableau)
 
http://magicsite.manga-torii.com

Je n'ai pas dit le contraire C'est tout à fait exact.
Mais dans ce cas, autant faire la démarche jusqu'au bout et ne plus essayer de "faire des tableaux" sans tableaux.

Je cherche pas à faire des tableaux sans tableau.
 
J'ai une charte graphique et je veux la respecter.
 
Le XHTML + CSS est censé n'avoir aucune régression par rapport au HTML 4, et pour cette raison, je dois m'attendre à pouvoir faire la même mise en page.
 
Hors là ça coince.
 
Je vais pas me mettre à dire à la créa "nan ça on peut pas faire" alors que jusqu'à présent on pouvait le faire... "appelle-moi con" qu'on va me répondre...

Heuuuu par contre les scripts derrière, c'est de toi ? ...  
Parce qu'il y a un beau plantage ...
 
Crée un label .. [mettre à jour] ..  
Puis supprime-le ...
Reload la page du browser .. selon toute logique, il va te dire "la page bla bla bla contient des données envoyées par POST bla bla bla" ..
Si tu fais "ok" tu te chopes une belle exception:
"Exception Details: System.IndexOutOfRangeException: There is no row at position 0."
( accompagné évidemment d'un beau gros pavé genre "tiens prends ça dans les dents" )

Aucune régression en effet... si ce n'est celle des navigateurs.
 
A ce propos, merci de ne pas faire l'amalgame classique "HTML = tableaux" / "XHTML = CSS" : les CSS s'accomodent très bien aussi avec HTML
 
Bref, je ne voudrais pas paraître rude mais je vais te donner mon avis, à prendre ou à laisser mais il n'est pas volontairement prévu de te froisser :
1- les CSS existent depuis bien avant XHTML, mais les navigateurs (dont certains plus que d'autres), ont toujours été à la traîne de ce côté, et le sont encore (suivez mon regard)
2- pour cette raison, les tableaux ont toujours été employés pour faire des sites web. C'était plus facile à faire (surtout en Wysiwyg) et il était plus facile de prendre le média Web pour du média Print, figé... ce qu'il n'est pas
3- "passer de tableaux à CSS" n'est pas seulement changer la balise <table> contre une balise <div>, c'est (beaucoup) plus que ça. C'est surtout ce point qui a du mal à passer : c'est une autre vision à avoir, une autre appréhension du média Web, une autre façon de penser et surtout... un nouvel apprentissage ! Cet apprentissage ne vient pas tout seul, il prend du temps, et un Wysiwig n'est pas capable de penser "sémantique" et de savoir que le contenu de ce <td> est censé être un titre de niveau 1.
 
Bref, sans vouloir vexer personne, je me répète un peu : si ce n'est que par mode ou "parce qu'on m'a dit de changer", tu vas droit dans le mur car tu vas vouloir adapter une façon de penser obsolète (tableaux) à une méthode radicalement différente (sémantique) et qui sont difficilement compatibles.
 
Soit tu prends le temps d'apprendre vraiment comment réaliser un document sémantique (balises bloc/en-ligne, modes de positionnement en flux, hors-flux, modèles de boîtes, incompatibilités navigateurs, etc.), soit tu perdras énormement de temps... pour un résultat final qui va être complexe, incompréhensible, voire complètement raté et pour dire "les div c'est tout pourri, je reviens aux tableaux".

Ouais, c'est normal, c'est en cours de développement
Et là j'utilise un truc un peu très gore pour jouer avec les données dans la base, et c'est pas super au point, je suis à la recherche d'une meilleure technique
 
Pour le moment, quand on est gentil avec ça plante pas, c'est déjà ça

sibelius > tu ne m'apprends rien, je faisais du CSS que tu jouais encore avec ton caca
 
En fait, pour moi (et n'ose pas me dire le contraire avant de réfléchir )
HTML = aucune mise en forme sémantique du document. mise en page avec le code balisé, et quelques fioritures en CSS pour rendre le rendu plus clean.
XHTML = mise en forme des informations du document selon leur sémantique à l'aide du langage balisé. mise en page intégralement faite en CSS.
 
Par conséquent, je maintiens que le risque de régression est présent, indépendement du navigateur, puisque c'est tout la logique comme tu le dis si-bien qui a été changée.
 
Ensuite, une page HTML peut parfaitement passer au validateur XHTML (à quelques corrections près) sans resecter une seconde la norme XHTML. Suffit de voir le nombre de sites qui affichent des listes dans des divs, ou n'utilisent pas les balises Hx, c'est abérant de recevoir des leçons en retour. Je ne parle même pas de la majorité des gens qui ne connaissent pas les balises "dl", "dt" et "dd"...
 
Bref. Dans tous les cas, logique différente ou non, s'il n'y a pas de régression, alors TOUT ce qui était possible de faire en HTML, même de la façon la plus porcine doit être faisable en XHTML en suivant RIGOUREUSEMENT la norme (c'est à dire en respectant aussi la notion de sémantique).
 
Pour avoir ré-écrit 80% des templates de ce site : http://www.elysee.fr qui, au moment de sa mise en prod tout du moins, respectait l'intégralité des normes les plus stricts qui existent, y compris les considération d'accessibilité et cnie, ne m'apprends pas ce qu'est le XHTML, je pense en avoirfait suffisament.
 
Seulement, la mise en page de ce site est absolument pourrie par rapport à ce que faisait ma société de l'époque quand on utilisait des tableaux en DHTML.
Là, j'ai un besoin spécifique, et que je doive penser différement du HTML, je le sais bien, mais c'est pas mon problème. J'ai passé deux demies journées à tenter de le faire en XHTML, et pas moyen, alors qu'en HTML "classique", ça m'a pris 10 minutes (taper sur un clavier de portable, c'est pas rapide)
 
Bref, je suis toujours dans l'attente d'une soluce qui respecterait la norme XHTML dans son intégralité, même si actuellement je m'en sors en foutant à la poubelle la sémantique.

Voilà qui est bien distingué. Mais tu as l'air si sûr de toi.
 
 

Grosse méprise malheureusement. HTML est tout aussi sémantique que XHTML. La norme HTML 4.01 est bien plus stricte qu'un XHTML mal fichu.
Pour rappel, les seules différences fondamentales entre HTML et XHTML sont de l'ordre de la rigueur :
    * Toute balise ouvrante doit être fermée
    * Balises et propriétés en minuscules
    * Valeurs entre quotes (apostrophes) ou double quotes (guillemets)
    * Chaque propriété doit avoir une valeur (pas de propriété vide comme checked, qui doit être écrit checked="checked" )
    * Les balises doivent être correctement imbriquées
 
C'est tout ! Aucune notion de tableaux, de CSS, de sémantique ni d'accessibilité : ces termes et domaines existent déjà en HTML.
 
Autre anecdote : le grand Gourou mondial des CSS, qui intervient directement dans les specs W3C, Eric Meyer a un site en XHTML 4.01... intégralement en CSS bien entendu.
 
Je refuse de véhiculer l'idée fausse que "HTML = pas de sémantique" et "XHTML = CSS". C'est ce genre d'idée qui fait que tout le monde mélange et confond des choses très différentes (par exemple : "les CSS ça rend automatiquement un site plus Accessible", et autres idioties" )
 

Bien entendu : le Validateur W3C, comme tout outil automatique est incapable de juger de la sémantique d'un document.
Il ne peut (et le reconnait) vérifier que des points varifiables automatiquement (imbrications, fermeture, etc.).
De toute façon, passer le Validateur ne doit jamais être un but en soi et une Norme n'assure pas la compatibilité.
 
 

Pire encore : ceux qui les emploient à mauvais escient (et j'avoue que j'y suis indirectement pour quelque chose à cause de quelque tuto obsolète )
 

OK, je traduis par "tout ce qu'on faisait en tableau doit être faisable sans tableaux en utilisant la sémantique des balises".
 
Alors je vais apporter une réponse personnelle de par mon expérience relative :
1- En théorie, il est presque possible de faire en CSS tout ce qu'on pouvait faire avant en tableaux.
 
Je dis bien "en théorie", puisque tout est prévu dans les spec CSS, mais que certains navigateurs (comme IE6) obsolètes n'implémentent pas tout. Notamment le fameux "display : table-cell" qui permettrait un centrage vertical de façon enfantine en CSS. D'autres cas, comme la notion de "colonnes de même hauteur" sont difficiles à gérer en CSS pour ces mêmes raisons (navigateurs obsolètes).
Sans parler bien-sûr des bugs inhérents à chaque navigateurs et qui nécessitent des bidouilles.
 
2- Dans la pratique, les tableaux posent un problème de fond : croire que le Web est un média figé, comme le média Print. Ils permettent d'avoir l'illusion que le web peut être paginé (hauteur de page)... alors que la notion de "page" n'existe pas dans le média Web.
Ce genre d'a priori fait que le webdesigner a souvent envie de faire des choses qui n'ont pas lieu d'être dans le media Web. Les structures en tableaux, ou les outils comme Flash permettent de réaliser ce genre de déviations du média.
Cependant - et c'est là qu'il faut bien comprendre le média - les CSS sont vraiment adaptés à chaque média (screen, print, aural, handheld, etc.) et c'est au webmaster de s'adapter au média Web et non l'inverse.
 

Tout ce qui me chagrine, est de croire que XHTML = CSS, ce qui est faux. Or, le W3C l'affirme lui-même : tous les doctypes depuis HTML 4.01 transitionnel sont parfairement Valides et intégralement aux Normes.
Choisir XHTML strict est un choix valide comme un autre.
 
D'ailleurs, si on voulait aller plus loin sur ce point précis, il vaudrait mieux éviter actuellement XHTML puisque je suppose que tu le sers comme du "text/html" et non comme une application XML, ce qu'il devrait être.
 
Voir :  
http://www.hixie.ch/advocacy/xhtml.fr/
http://forum.alsacreations.com/faq/#item42
 
 

"Foutre à la poubelle la sémantique", c'est utiliser des tableaux ?
Il faut savoir que parfois, la structure tabulaire - bien conçue - est bien plus compréhensible par les agents utilisateurs et les personnes handicapées (non voyants pour ne parler que d'eux).
Les tableaux sont aujourd'hui tellement satanisés qu'ils commencent à poser des problèmes inverses : les personnes handicapées se plaignent que les sites "pensés comme des tableaux, mais réalisés n'importe comment à grands renfors de div imbriqués" leur posent encore plus de problèmes.
 
Le problème, c'est qu'on demande maintenant aux agence de "faire un site sans tableau" (ou pire "faire un site en XHTML" en croyant que c'est la même chose)... parce que ça fait bien.
 
Mais ceci est un autre sujet
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

En fait, si j'ai bien compris, tu voudrais simplement faire un cadre sans tableau ?
 
Je te donne un ancien lien :  
http://www.alsacreations.com/articles/cadre/
 
Mais si tu veux plus récent et conforme, tu devrais trouver ça dans un bon bouquin que je pourrais personnellement te conseiller
 
EDIT : tiens, d'autres façons de procéder :
http://articles.e-t172.net/round/
http://www.html.it/articoli/nifty/index.html

C'est pourtant ce qu'on peut lire sur le site www.w3.org
 
Le HTML dispose de tous les mécanismes et principes de sémantique, séparation de la mise en page et des données et tout.
SAUF que leur application ne fait pas partie de la norme. En résumé, on a un outil, on s'en sert comme on veut, personne ne t'empêche de décapsuler une bière avec un briquet.
 
Le XHTML, quant à lui, et c'est écrit noir sur blanc dans sa définition, impose l'utilisation des outils de sémantique et de séparation des donnés de la mise en page.
 
Comme j'ai dit plus haut, une page qui passe au validateur XHTML n'est pas forcément conforme à la norme (tandis qu'une page HTML validée, même si dedans y'a que de la merde, reste conforme à la norme).

"utilise des tableaux c'est foutre à la poubelle la sémantique", oui, dans ce cas, dans la mesure où je n'affiche pas un tableau, mais un cadre qui englobe une liste.
 
sur la partie droite, j'ai un tableau bien goret, et il ne changera jamais, car sémentiquement c'est un tableau, ce serait une inepte de le transformer en div.
 
mais les contours de mon menu...

 
Voilà exactement ce qu'indiquent les différents doctypes :
 
HTML4.01 transitional
les attributs et éléments de présentation suivants sont autorisés...
 
HTML4.01 strict
les attributs et éléments de présentation précédents ne sont plus autorisés. Ils doivent être remplacés par des styles CSS
 
XHTML1.0 transitional
voir HTML4.01 transitional
 
XHTML1.0 strict
voir HTML4.01 strict
 
En résumé :  
- XHTML n'apporte aucune différence en terme d'obligation de CSS
- XHTML transitionnel accepte très bien les balises et attributs de mise en page
- les tableaux restent bien entendu valides dans les 4 doctypes.
 
Bon allez, c'est le genre de troll sans fin qui ne m'apporte rien à part à perdre du temps sur les fausses idées reçues qui malheureusement embrouillent tout le monde. Mais c'est pas grave, l'estomac est à présent prioritaire dans mon agenda.
 
Bonne chance à toi pour ton projet

dans tous les cas, mon truc ne respecte pas la sémantique, et ça me fait chier
 
sinon, bien noté pour le html 4.01, je n'avais pas connaissance de ce dernier, sorti apparement juste 1 mois avant le xhtml 1.0 d'après les dates de première révisions. (décembre 1999 contre janvier 2000)

Le problème de ces liens (comme tous ceux qui ont été mis dans ce topic depuis le début), c'est qu'ils ne permettent pas de faire ce que je veux faire.
 
Je vais faire un dessin, parceque je crois que je vais jamais m'en sortir sinon... à chaque fois j'ai les mêmes réponses, qui ne résolvent pas du tout mon problème.
 
Je reviens dans quelques minutes, avec un dessin et les explications qui vont bien, car j'ai l'impression que personne ne comprend ce que je veux depuis hier

Voilà, je ne vois pas ce que je pourrais rajouter de plus :