Reprise du message précédent :
le menu c est ul non ?
il est vide sur firefox donc il faut le machiner comme il faut stou

J'ai pas la barre en question pour ie, mais déja :
 
.menulist li {position:relative;display:block;margin:0;float:left}
 
Et j'ai un peu de mal à comprendre pourquoi le #menuprincipal est en position:absolute

Mets ton ul sur la commode
Si tu débuggues, mets un point d'arrêt dessus, ça sera l'arrêt de ton ul

et évite de l'utiliser sur une machine poussive, c'est un vrai tank ul

 
bah apprenez a vous servir de firebug hein
d apres le dom ok le ul est bien peuplé y a pas de problème mais d apres le flux cet ul est vide
un peu comme si les li flottaient ptet cette position relative degueulasse
la solution de shinuza est bien mais engendrera le meme probleme
il faut un putain de contexte sur cet ul

 
personnelleemnt, il mnque <ul>

Autre chose, l'accueil au dessus de "acualités" a gauche disparait aussi.
Le site est fucké, de rien.
 
Edit : Et mirror à raison, le ul n'a pas le contexte de formattage, donc il est vide, il n'a pas de consistance.

il est pas vide

le position relative ça sert à placer les éventuels sous-sous menus. Le display block c'est parce que je risque de leur foutre des marges ou des paddings (qui s'appliquent seulement sur les éléments bloc) et le margin c'est parce que sinon, un li, ça a une marge par défaut.
pour la position du #menuprincipal, regarde où il est dans le code, et donne-moi une solution pour le foutre en haut alors qu'il est en bas dans le code, ou alors donne-moi une solution pour le mettre par-dessus des anims flash sans le foutre en-dessous de celui-ci dans le code html.

ok, je sais ptet pas m'en servir au-delà de l'inspecteur. Cool. Et maintenant, tu m'expliques ?

en quoi c'est dégueulasse ?

cad ?

ça a été fait à l'arrache en 1/2 journée en attendant une vraie charte graphique, spa étonnant, mais là le menu principal ça a posé un petit problème pour présenter au client

ok, et je fais comment ?

et putain, expliquez-moi pourquoi il est vide alors qu'il y a des éléments dedans !

Si tu inspectes un <a> dans le DOM tu verras qu'il est directement dans "window", il est hors du flux, il est dans rien du tout en fait... si j'ai bien tout compris

Edit: et c'est vrai qu'on lieu de sortir "oué t'es nul tu sais pas te servir de ceci cela" ça serait peut être bien de nous expliquer (enfin même si je pense que sur ce coup là j'ai compris)

j'inspecte un <a> du menu avec firebug ou le dom inspector, il le trouve bien dans le li...

Ben moi si dans Firebug, onglet HTML je fais un clic droit sur le <a> et que je dis "Inspect in DOM Tab", ça me le fout direct dans "window"

Tes li sont floatés, donc ils sortent du flux, si tu ne rétablies pas le flux, le conteneur contient des élements hors du flux, c'est comme si il était vide.
Pour s'en rendre compte il suffit de survoler le ul dans l'inspecteur HTML de firebug, t'auras aucun élement en surbrillance. Donc tu colles un

zoom:1;overflow:hidden;_overflow:visible

sur le conteneur des elements floatés pour forcer sa consistance. (et qu'on vienne pas m'emmerder avec les hacks)
 
De la lecture qu'elle est bien :
http://www.blog-and-blues.org/arti [...] _formatage
 

Et c'est aussi un élement de type block
 
Donc d'une le display:block sur élement de type block ça sert à rien, mais le float fait également passer ton élement en block

J'ai vu ou il est foutu dans le code. C'est justement ce que je comprends pas. Un menu à rien à foutre en dernier dans le flux html.
 
Donc tu le fous au bon endroit dans ton flux, et sur tes anims flash tu mets un wmode="transparent"
Et tout le monde sera content
 

Plus productif que de lire le code généré par GWT qui est obfusqué. Fais-pas ta mishkline.    

quand je clique sur un objet dans la fenetre du bas ca la surligne en bleu
ton li est correct
mais si ton ul etait rempli le fait de cliquer dessus devrait rendre tous les lis bleus
or il ne se passe rien

et ca engendre un paquet de bugs sur ie (d ailleurs sur firefox aussi)

le UL est rempli, mais le fait que tous les éléments qui sont à l'intérieur soient flottés fait que le UL fait 0px de haut.
Un contexte de formatage permettrait au UL de faire la hauteur qu'on lui demande, mais le probleme n'est pas là, il est ailleur.

je sais bien mais souvent ca fait des combos c est ie hein

Sauf que le code JS de google ne vient pas de GWT.

zoom:1;overflow:hidden;_overflow:visible

j'ai testé (appliqué ton truc sur .menulist, .menulist ul), mais non seulement ça change rien sous IE6, mais en plus ça empêche les sous-menus d'apparaître sous FF.
 

sauf qu'à priori ça marche pas systématiquement, sinon j'aurais pas fait un truc horrible comme ça...

Normal, y'a un overflow hidden et donc tous les élements à l'intérieur ne peuvent pas apparaitre en dehors du corps du conteneur. C'était juste un correctif dans le cas d'élement floatés dans un conteneur, en l'ocurrence ça ne changera rien (j'ai essayé) mais ça t'évitera d'empiler les bugs. Par contre dans ton cas précis tu peux remplacer l'overflow hidden par un display table-cell, comme indiqué dans l'article

Jamais eu de soucis avec ça. A mon avis tu t'es pris la tête pour rien.

Juste 18/20 à mon partiel d'html
 
Tout ça parce que j'ai oublié d'interdir le scrolling avec ces putains de frames et que je me suis trompé dans une couleur de la css
 
J'ai mis blue au lieu de navy

Putain le partiel d'enfer. J'aurais écris un gros texte pourquoi les frames c'est naze...

y a encore pas longtemps un type disait qu a la fac on lui apprenait a faire des sites en tableaux alors ....

En 1999 à l'IUT (section programmation) ce qu'on nous apprenait de plus compliqué en html, c'était comment mettre une image avec plusieurs zones cliquable. Et je ne parle pas de la mise en page d'une page, ça, c'était hors court qu'on l'apprenait.
En fait, le jour où les universités seront des références de la création de sites web, je serais à la retraite.

2/20

Ouais avec remarque "on vous demande pas votre avis"

Ca serait pas plutôt avec une remarque du genre "Hors sujet : on est pas en court de littérature"?

 
En même temps dans un cursus informatique, je vois pas trop pourquoi le html serait plus important que les trucs genre vie d'entreprise et autre trucs périphériques

0x90 > En même temps, tant qu'a enseigner une matière/un langage/... autant le faire bien plutôt que de le faire n'importe comment. En 15 heures de court, il y a surement moyen de dépasser le "exercice numéro 8, afficher une image avec une zone cliquable circulaire de telle taille et de centre X,Y et une zone cliquable rectangulaire qui va de telle coordonné à telle autre" sans que les profs ne vérifient quoi que ce soit derrière. En 15 heures, ils ont surement le temps de glisser un mot sur les bonnes pratiques, tu ne penses pas?
En fait, je ne dis pas que l'html devrait avoir une place plus importante que les courts de compta ou les autres courts non informatique (loin de là d'ailleurs même si je ne comprenais rien à la correspondance entre la classification des comptes et les exercices qu'on nous donnait à faire) mais que tel que l'html est visiblement enseigné dans pleins d'endroit, ça ne sert à rien sinon à donner de très mauvaises habitudes en leur faisant croire qu'ils apprennent à faire des sites.

Moutouls §

Comment on putain de fait pour détecter le clic extérieur à un div ?

Genre j'ai une popup, et au prémier clic en dehors, elle se ferme ?

 
event 'click' sur le document, et :
- soit tu fais gaffe de pas avoir d'element dedans qui bloque l'event et qui l'empèche de bubbler
- soit entre ta popup et le reste tu insère un div quasitransparent qui peut chopper l'event plutot que le document, dans ce cas pas de risque de pas recevoir l'event.
 
( Et tu remercie IE pour ne pas implémenter les event phase 1 )

bon les cons, je reviens.
j'ai vaguement survolé la discussion au-dessus, tien compris à l'aspect technique, mais en tout cas les menu hiérarchiques c'est mal (monocline grouping tout ça)

sinon, j'ai une question technique : comment vous layoutez un formulaire bidon avec une colonne pour les label et une colonne pour les champs, alignés comme il faut ? pas en <table> parce que ça fait vomir les barbus.

Comme ça :

Et dans la CSS : largeur fixe pour les label

PS : un coup de fieldset + legend c'est utile aussi

si tu dois avoir des colonnes, fait des tableaux

a moins que tu ne prefere te faire chier avec des span/li/div avec des largeurs calculées au quart de poil près

edit : lu un peu vite, je pensais que tu avaios plus de colonnes que ca

merci.
et maintenant la question qui tue : je la choisis comment la largeur fixe ?

question technique : pourquoi le div dans le form et pas l'inverse (si ça a de l'importance) ?

En table parce que j'emmerde les barbus et que le temps nécessaire pour refaire le layout le jour ou il faudra est inférieur au temps nécessaire pour mettre en place le ONE TRUE MARKUP pour faire tout les layout du monde avec le même code.
Histoire de faire clean je met les labels dans des th et basta.

Et aussi pour ça

bon, ok j'ai la justification sociale que je cherchais.
 
fais chier, je viens de virer le layout auto de struts qui fait justement une table par défaut

 
Pour la largeur ça dépend de ton design par contre
 
Sinon le fait de regrouper un libellé et son champ dans un container ça permet d'ajouter de la sémantique. Ca a un sens de les regrouper ensemble car ils sont liés (et c'est aussi le but de l'attribut for du label, qui permet en cliquant sur le label de donner le focus directement au champ qui a pour id la valeur du for du label).
Ce niveau de regroupement te permettra aussi d'ajouter du sens genre :

 
Sinon le form en lui-même sera souvent dans un container de + haut niveau.

Perso les markup comme celui que j'ai indiqué + haut sont bcp bcp souples (pour faire du multi-colonnes par exemple c'est facile en manipulant avec des floats) qu'un markup avec un tableau

c'est bizarre, dans ma table les labels sont en taille par défaut du navigateur, il respecte pas les 11px que j'ai mis dans body, et pourtant firemachin me raye pas les 11px de body, et personne ne touche à la taille des fonts (d'après firemachin en tout cas).