Bobe

Bon, désolé de ne pas m'être manifesté plus tôt J'ai un peu avançé ce soir sur le script que je suis en train de confectionner. J'essaierai de le finir demain et le publierai ici.

Mais qui n'est pas supportée par certain navigateur (<- notez ici l'emploi du singulier) Le modèle d'évènements du W3C a deux atouts majeurs: La capture d'évènements. Elle est encore mal gérée dans les navigateurs modernes (ne parlons pas d'IE) à cause de divers bugs. La possibilité d'enregistrer plusieurs guetteurs sur une cible. exemple: element.onclick = test1; element.onclick = test2; Seule la fonction test2() sera appellée lorsque l'évènement aura lieu. element.addEventListener('click', test1, false); element.addEventListener('click', test2, false); La fonction test1() sera appellée, puis la la fonction test2() sera appellée également. Le DOM 2 Events ne donne aucune indication sur l'ordre d'appel, mais en général, le premier guetteur enregistré est le premier appellé. Edit: IE qui, comme tout un chacun le sait, aime lancer des petits défis à l'esprit logique, déclenche évidemment les guetteurs dans le sens inverse. Dernier enregistré, premier appellé, j'ai fait le test avec l'API propriétaire de Microsoft, attachEvent(). Les évènements capturants n'étant pas vraiment utilisable pour l'instant, à moins que l'on souhaite pouvoir enregistrer plusieurs guetteurs sur une même cible (possibilité essentielle), on utilisera plutôt à l'heure actuelle la syntaxe: element.onevent = [nom de la fonction ou sa déclaration]; (Bon, ceci dit, je suis le premier à utiliser addEventListener, quitte à écrire des scripts de correction style "usine à gaz" pour IE ;-)) Les recommandations du W3C (Technical Report http://www.w3.org/TR/) ont l'inconvénient majeur de s'adresse à deux types de personnes: Celles qui vont utiliser les "outils" décrits et celles qui vont les implémenter, d'où leur coté parfois très technique et abscon. Je fais un exemple en vue simple: document -> html -> body -> div1 -> div2 -> div3 Et les enregistrement d'évènements suivants: div3.addEventListener('click', test, false); div2.addEventListener('click', test, true); div1.addEventListener('click', test, false); body.addEventListener('click', test, true); Premier cas: on clique sur le div3. Le guetteur présent sur le body "capture" l'évènement 'click' et est donc déclenché Le guetteur présent sur le div2 "capture" l'évènement 'click' et est donc déclenché Il n'y a pas d'autres guetteurs capturants en amont du div3, fin de la phase de capture. Le guetteur sur le div3 est donc déclenché (phase "normale", sur la cible). Puis on passe en phase de bouillonnement, l'évènement remonte vers la racine de l'arbre et déclenche le guetteur sur le div1. Deuxième cas: on clique sur le div2 Le guetteur présent sur le body "capture" l'évènement 'click' et est donc déclenché Pas d'autres guetteurs capturants en amont du div2, fin de la phase de capture. Le guetteur enregistré sur le div1 est déclenché (phase sur la cible). Le guetteur du div2 n'a pas été déclenché car il a été enregistré comme étant capturant. Comme aucun évènement de type 'click' n'a été déclenché en aval du div2, le guetteur ne se déclenche pas. Troisième cas: on clique sur le body Rien ne se passe car le guetteur enregistré sur le body est en mode capturant, or, aucun évènement 'click' ne s'est produit en aval du body. Le DOM Level 3 Events, bien que n'étant qu'à l'état de document de travail, dispose d'un schéma graphique assez représentatif du parcours effectué lors des différentes phases de l'évènement au paragraphe 1.2.1: http://www.w3.org/TR/DOM-Level-3-Events/ev...l#Events-phases Le site suivant donne également de bonnes informations. Regardez à la section javascript, le dernier chapitre, "events": http://www.quirksmode.org/sitemap.html La structure n'étant pas correcte, elle devrait être rectifiée, or, le DOM dépendant entièrement de la structure du document, modifier cette structure revient le plus souvent à modifier ses scripts. Autant se baser sur une structure correcte dans ce cas je ne suis pas là jusqu'à dimanche, mais je regarderai ensuite si je peux terminer le script que j'avais commencé hier.

Non, il faut prendre en compte le coefficient de préférence (l'indice q dans les en-têtes http). S'il est présent dans la norme http, ce n'est pas pour rien. L'ordre des différents type mimes listés dans l'en-tête accept n'a pas de particularité, c'est à dire qu'un type mime plus à gauche qu'un autre ne signifie pas que c'est le type mime "préféré". Le seul moyen pour l'agent utilisateur de classer les types mimes supportés par ordre de préférence est d'utiliser le coefficient de préférence. Cela semble peu important dans le cas présent, mais transposons cela sur les préférences de langage: Accept-Language: fr,en,* Quel est le langue préférée de l'utilisateur ? Impossible de savoir. D'où l'utilité du coeff. de préférence: Accept-Language: fr,en;q=0.9,*;q=0.1 Je préfère des documents en français mais si tu n'as pas ce document dans cette langue, j'accepterai un document en anglais. Si tu ne l'as pas non plus en anglais, envoie moi ce que tu as.

Salut, Chez moi, sous Firefox 0.9.3, les sous menus apparaissent bien quand je passe le curseur sur les éléments DT mais disparaissent dés que je ne pointe plus dessus (en voulant pointer sur un item du sous menu). Quoi qu'il en soit, et si je peux me permettre, votre code comporte un certain nombre d'erreurs. Vous détectez le navigateur utilisé à l'aide des propriétés de l'objet navigator, ce qui est une mauvaise idée. Vous devriez plutôt détecter les méthodes et attributs que vous souhaitez utiliser. Par exemple: if( typeof(elem.addEventListener) != 'undefined' ) { // on utilise addEventListener } else { // on utilise autre chose } Vous utilisez la méthode addEventListener alors que celle ci n'apporte rien dans ce contexte. Et comme vous mettez true en troisième argument, l'évènement ne peut se déclencher que si un évènement de même type, mais non capturant, est déclenché en aval de l'arbre. J'étais parti pour proposer une alternative mais la structure du menu étant loin d'être sémantiquement correcte, je n'ai pas poursuivi.

J'en rajoute quelques uns: http://macedition.com/cb/resources/abridgedcsssupport.html (la dernière mise à jour date de quelques mois) Support CSS dans Safari Support CSS dans Opera 7 http://www.designdetector.com/articles/results.html

Xavier: Avec ton code, Opera va recevoir la page en application/xhtml+xml alors qu'il indique sa préférence pour text/html. Il faut tenir compte également du coefficient de préférence présent dans l'en-tête accept.

La version 5.0.0 finale a été publiée dans la soirée Téléchargement:: http://www.php.net/downloads.php#v5 Changelog:: http://www.php.net/ChangeLog-5.php#5.0.0

Ah ouais quand même. Je voyais la version finale plutôt fin aôut ou courant septembre, mais c'était une estimation purement personnelle et grossière (du niveau de l'intuition en quelque sorte).

Rhaa Tu pourrais au moins mettre un doctype xhtml 1.0 quand tu envoies en text/html..

Peux tu fournir un exemple mettant en valeur cet "avantage" ?

Ah bon ? Il me semble pourtant que ce meta a fait l'objet de nombreux abus. Elle est encore prise en compte ? Sans compter que le contenu même de la page constitue déja une liste de mots clés.

Simplement parce que le fonctionnement de vertical-align est souvent mal interprété par les gens. Cette page donne une bonne idée de l'utilisation de vertical-align: http://www.editions-eyrolles.com/css2/tests/vfm/vfm22.htm Seule exception où vertical-align sert à aligner verticalement un contenu dans une boite de type bloc: le contenu des cellules d'un tableau.

Le validateur du W3C me dit le contraire De plus, le XHTML 1.1 ne doit pas être envoyé avec le type de média text/html mais application/xhtml+xml (type que certains navigateurs ne supportent pas encore)

Oui. Nous aurions d'ailleurs pu nous éviter des incompréhensions, je lis à la fin du chapitre 5.5 (les sélecteurs descendants):

Arf Je me fais si mal comprendre que ça ? Alors le même exemple sans les petits raffinements : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en" dir="ltr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-15"> <title>Test</title> <style type="text/css" media="screen"> div * span { background-color: green; } </style> </head> <body> <div> <span>ceci est un test</span> <p> Voici un <span>autre test</span> </p> </div> </body> </html> Cet exemple démontre bien que : div span { ... } et div * span { ... } ne sont pas équivalents. Le premier touchera tous les span descendants d'un div alors que le second touchera tous les span descendant d'un div mais non enfant de ce div.

Désolé d'insister mais <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en" dir="ltr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-15"> <title>Test</title> <style type="text/css" media="screen"> body { background-color: white; } span { background-color: red; } div * span { background-color: green; } </style> </head> <body> <div> <span>ceci est un test</span> <p> Voici un <span>autre test</span> </p> </div> </body> </html> Le premier span, descendant et enfant du div, a un fond rouge tandis que l'autre, descendant mais pas enfant du div, a un fond vert. Le sélecteur universel correspond à "n'importe quel élément", non pas à "n'importe quel élément ou aucun élément".

Non, elles ne sont pas équivalentes. Avec la première, les span enfants du div ne seront pas concernés par la règle.

la propriété href est en lecture seul, ce qui signifie qu'on ne peut pas modifier son contenu. IE et autres navigateurs sont dans l'erreur s'ils permettent de modifier cette propriété.

La propriété href est en lecture seule: http://www.yoyodesign.org/doc/w3c/dom2/sty...pt-binding.html

Non, on met em pour emphase Le fait qu'une emphase en html s'affiche en italique n'est que le type d'affichage par défaut (il fallait bien que ça s'affiche différemment du texte de base).

techniquement, on peut vouloir utiliser un autre langage de script client (et donc indiquer le type de média qui lui est spécifique). Maintenant, dans la pratique...

tu voulais sùrement dire autant de <p> que de paragraphes. ;-)