Aller au contenu

Bobe

Webmaster Régulier
  • Compteur de contenus

    72
  • Inscrit(e) le

  • Dernière visite

Messages postés par Bobe

  1. Je ne comprends pas bien la remarque sur addEventListener qui est référencé comme la méthode à utiliser...

    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 ;-))

    J'ai vu que vous aviez l'air beaucoup plus expérimenté que moi sur ce sujet (la propagation des évenement), peut-être quelques explications serait utiles, pour résoudre l'intéressant probleme de pierre.

    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

    Par contre je ne vois pas le rapport entre la sémantique du modèle de raphael et le probleme de pierre, il est vrai que je n'utiliserais pas ce format pour construire un menu mais les arguments de raphael sont recevables.

    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 :)

    Peut-être qu'avec votre avis éclairé pourrions nous sortir un script propre ?

    je ne suis pas là jusqu'à dimanche, mais je regarderai ensuite si je peux terminer le script que j'avais commencé hier.

  2. 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.

  3. 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.

  4. Oh, il est d'ores et déjà stable. Assez pour que l'équipe pense sortir la version finale dans la première semaine de juillet.

    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).

  5. <div style="text-align:center; vertical-align:middle; widht:100%; height:100;">

    et mon tableau n'a ps de class.

    Ce que je remarque, c'est que vertical-align:middle n'est ps compris et souvent ps pris en compte...

    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.

  6. C'est avec fierté et émotion que je vous présente mon premier site validé en xhtml 1.1.

    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)

  7. Oui. :)

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

    Avec ce sélecteur :

    DIV * P

    on touche les éléments P qui sont les petits-enfants, ou les descendants plus lointains, d'un élément DIV. Noter les blancs facultatifs de chaque côté du "*".

  8. Arf :lol:

    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.

  9. 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".

  10. De la même manière, pour reprendre l'exemple donné par la page que tu cites, les deux formulations suivantes sont équivalentes :

    div * span {background - color: yellow;}
    div span {background - color: yellow;}

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

  11. dsl de pas être très doué mais le lien que tu m'as donné est très intéressant mais je n'ai tjs pas compris pourquoi ça n'allait pas pr mozilla et ce qu'il fallait que je fasse pr que ça fonctionne.

    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é.

  12. on met : em or pour italique ça aurait du être "i".

    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).

×
×
  • Créer...