Blog Alsacréations

• août 2008
• juillet 2008
• juin 2008
• mai 2008
• avril 2008
• mars 2008
• février 2008
• janvier 2008
• décembre 2007
• novembre 2007
• octobre 2007
• septembre 2007
• août 2007
• juillet 2007
• juin 2007
• mai 2007
• avril 2007
• mars 2007
• février 2007
• janvier 2007
• décembre 2006
• novembre 2006
• octobre 2006
• septembre 2006
• août 2006
• juillet 2006
• juin 2006
• mai 2006
• avril 2006
• mars 2006
• février 2006
• janvier 2006
• décembre 2005
• novembre 2005
• octobre 2005
• septembre 2005
• août 2005
• juillet 2005
• juin 2005
• mai 2005
• avril 2005
• mars 2005
• février 2005
• janvier 2005
• décembre 2004
• novembre 2004
• octobre 2004
• septembre 2004
• août 2004
• juillet 2004
• juin 2004
• mai 2004

Le vendredi 6 août 2004 à 12:49, par ElMoustiko :: site :: #

Pour ce qui est du menu vertical (le 1er), il doit manquer quelque chose, rien ne se passe... je n'ai pas regardé la source, pas vraiment assez reveillé pour étudier tout ça de près !

Sinon belle adaptation en roll over, perso je préfère le "onclick" comme ça l'un complète l'autre

Je ne suis toujours pas satisfait pas mon script javascript et la technique utilisée, ça n'est pas assez automatisé, je potasse sur une solution, nous verrons bien !

@++

Le vendredi 6 août 2004 à 12:55, par ElMoustiko :: site :: #

Ouuuppss, je l'avais dit que je n'était pas reveillé ! En fait il est onclick le premier ! Mais c'est le principe de fonctionnement qui m'as dérouté... le premier menu fermant les autres et ne dévoilant aucun sous menu et les autre s'ouvrant en fermant les autre... je ne suis pas certain de la viabilité du principe...

En tout cas la solution "onmouseover" pour ce genre de menu n'est pas vraiment indiqué selon moi, puisque l'ouverture/fermeture est souvent trop rapide (instantanée) et créee souvent une fermeture intempestive lorsque les sous menu sont trop petit. Enfin je m'exprime pas très bien, mais le problème que j'ai avec ce principe est difficile à expliquer.

Donc à mon avis, conserve le comportement onclick pour cette version (le probleme ne se pose pas pour les autres versions, les sous menu etant sur le coté) mais revois peut etre le principe... ou renomme le 1er menu 'Fermer les menus' ...

@++

Le vendredi 6 août 2004 à 13:34, par Sibelius :: site :: #

@ElMoustiko : "Ouuuppss, je l'avais dit que je n'était pas reveillé ! En fait il est onclick le premier ! Mais c'est le principe de fonctionnement qui m'as dérouté... le premier menu fermant les autres et ne dévoilant aucun sous menu et les autre s'ouvrant en fermant les autre..."

>> En fait, l'idée m'est venue d'une demande d'un client : il voulait un menu avec certaines parties déroulantes et d'autres non (simples liens)... et comme ce n'était pas possible avec ta version, j'ai adapté.

Il me semble pourtant expliquer plusieurs fois cette particularité dans le tuto :
- "Nous voyons qu'il y'a 4 menu prévus. Chaque menu parent possède des sous-menus, sauf le premier (il n'aura pas de sous-menus mais un lien direct vers une page). Mais tout est configurable selon vos souhaits, naturellement."
- "Si aucun sous-menu n'est indiqué (cas du premier menu), alors le comportement sera simplement de fermer les sous-menus actuellement ouverts"
- "Lorsque la fonction est appelée à l'aide du "onclick", voici le déroulement : pour commencer, tous les sous-menus se ferment (display: none), puis, le sous-menu indiqué dans le "onclick" s'affiche (display: block).
Si aucun sous-menu n'est spécifié (cas du menu 1), seule la première phase a lieu : tous les sous-menus affichés se ferment."

Pour ce qui est de ta proposition ( 'Fermer les menus' ) : je préfère ne pas avoir plusieurs fonctions : avec une seule fonction, il est possible de tout faire. Je pensais l'avoir expliqué clairement dans le tuto; Ce n'est peut-être pas le cas... ou alors tu as lu entre les lignes !

Le vendredi 6 août 2004 à 14:41, par ElMoustiko :: site :: #

Euh je confesse, j'ai pas lu du tout !!!!! Ca m'apprendra a parler pour ne rien dire... je vais faire mes devoirs !

Le vendredi 6 août 2004 à 14:54, par ElMoustiko :: site :: #

AHhhaahah, j'ai décelé une vraie erreur (à mon avis) cette fois ci ! (yippeee ! ) J'ai désactivé le JavaScript, résultat, les sous menus sont inaccéssible (logique puisque tu les caches dans le code css), ainsi ta page n'est pas fonctionnelle à 100%, puisqu'aucun lien vers le menu général (dt) n'est présent, le menu est donc tout simplement inaccéssible aux utilisateurs ayant désactivés JavaScript, un mauvais point ! C'est entre autre pour cela que j'avais implémenté la fonction hideOnLoad() dans ma version et je la réutilisé ensuite dans le script. Si tu désactive le JavaScript dans mon exemple tu verras que le menu est tout de même accéssible. Je pense que tu seras d'accord avec moi sur le fait qu'il faille prendre en compte les utilisateurs ayant désactivés le JavaScript.

Sinon c'est vraiment bien clair et assez facile à comprendre.
@++

ps : désolé de remplir cet article d'autant de commentaires inutiles...

Le vendredi 6 août 2004 à 17:34, par Sibelius :: site :: #

Pour le javascript, c'est effectivement ennuyeux.
Je vais sans-doute devoir utiliser ta fonction au chargement de la page, même si ça m'ennuye parce que ça rajoute du code.
D'ailleurs, l'ancienne version du tuto fonctionnait également exclusivement avec javascript actif, mais personne ne m'avait fait la reflexion

Le vendredi 6 août 2004 à 19:07, par jep :: site :: #

Hello !

J'ai quelques remarque concernant les menu utilisant les evenements onrollover et onrollout

Concernant : le Menu horizontal déroulant c'est assez problématique de ne pas prévoir la fermeture des menus quand on ne les survoles plus ... non ?

Concernant : Le Menu vertical déroulant avec les navigateur Gecko (Mozilla/Firefox), il y a des quelques bug d'affichage (scintillement du menu et problème de fermeture aléatoire lorsque on quitte le survol). J'en reviens a ce que je disait dans un article précedement du blog : avec ces navigateurs, s'il faut gérer des evenements de type rollover, il vaut mieux privilégier l'utilisation de la pseudo class css :hover.
Seul IE ne comprend pas cette pseudo classe, donc, il est le seul a vraiment avoir besoin de JS. Comme je l'ai montré dans cet article :
www.ibilab.net/webdev/ind...

Concernant la desactivation du JS, la solution consistant à utiliser un fonction du style hideOnLoad() est interressant, mais peut parfois poser des problèmes du point de vu de la gestion graphique. Personellement, je préfére mettre un lien sur tous les item ouvrant un sous menu, ce lien pointant vers une page avec un contenue par defaut et permettant d'aller vers les item présent dans les sous-menu qui ne sont pas accessibles.

Le vendredi 6 août 2004 à 20:14, par Sibelius :: site :: #

@Jep :

- "J'ai quelques remarque concernant les menu utilisant les evenements onrollover et onrollout "
>> Tu parles de tutos d'Alsa? Je n'utilise pas ces événements (je ne les connais d'ailleurs pas)

- "Concernant : le Menu horizontal déroulant c'est assez problématique de ne pas prévoir la fermeture des menus quand on ne les survoles plus ... non ?"
>> C'est aussi ce que je croyais, mais en pratique c'est différent : lorsque tu survoles un menu, c'est pour choisir l'un des éléments qui le compose. Sinon, tu cherches ailleurs, en survolant un autre menu et dans ce cas, l'ancien sous-menu s'efface.
Mais si tu le veux, il est simple de rajouter un onmouseout='javascript:montre();' pour effacer les sous menus en le quittant.

- "Concernant : Le Menu vertical déroulant avec les navigateur Gecko (Mozilla/Firefox), il y a des quelques bug d'affichage (scintillement du menu et problème de fermeture aléatoire lorsque on quitte le survol)"
>> Etonnant, j'ai pourtant testé sur plusieurs geckos et je n'ai détecté aucun problème. Quelle version as-tu ?

- "Seul IE ne comprend pas cette pseudo classe, donc, il est le seul a vraiment avoir besoin de JS."
>> Certes, mais faire un site qui ne fonctionne pas sous IE est un peu suicidaire et surtout un peu stupide : IE a le monopole, il ne faut pas s'obscurcir les yeux derrière les Standards

- "mais peut parfois poser des problèmes du point de vu de la gestion graphique."
>> Des précisions ?

- "Personellement, je préfére mettre un lien sur tous les item ouvrant un sous menu, ce lien pointant vers une page avec un contenue par defaut"
>> Oui pourquoi pas en effet, mais ça revient à faire des pages supplémentaires qui ne sont pas obligatoirement pertinentes et peuvent même prêter à confusion.

Bref, il y'a toujours du pour et du contre.

Sinon, j'ai bien aimé ton menu en cascade, qui utilise aussi js mais d'une autre façon moins "imbriquée". Par contre j'ai une petite question. N'étant pas spécialiste je ne suis pas sûr de poser une question bête, mais je me lance : par rapport à des détecteurs comme "UL = obj.getElementsByTagName('ul');", que se passe-t-il si la page (chose courante) contient D'AUTRES listes (ul) que celles du menu ?

Dans tous les cas, j'ai bien l'impression que le sous-menu parfait n'est pas encore de notre monde... on trouvera toujours des traces de js quelque part, même avec le fameux hack "IE7"

Le vendredi 6 août 2004 à 20:55, par ElMoustiko :: site :: #

Alors pour repondre à jep sur le place que peux prendre un menu complètement déroulé, ce qui peux poser des problemes graphiques, je me suis posé ce probleme aussi et je me dit, les webnautes ayants desactivé le JS sont peu nombreux, il faut pourtant s'en occuper et donc, leur permettre l'acces au menu, l'affichage peut s'en trouver altéré mais ça reste très utilisable et à toi webmaster de t'arranger pour que ça soit le moins catastrophique possible !

Sinon pour ce qui est de l'ajout de la fonction hideOnLoad, c'est 3 lignes de codes... peut on réellement dire que c'est beaucoup ? !

Mais le menu dynamique parfait (mais avec JS, donc pas encore absolument parfait, mais la perfection n'existe pas parait-il) est en cours de réalisation !!!!! Bon j'avance pas fort en ce moment, mais vraiment je suis persuadé que mon idée est réalisable au vue de ma source d'insipiration.

Pour revenir a l'ajout de page avec lien sur le titre de menu (et oui pour suivre ElMoustiko il faut le vouloir), tu proscrit donc l'utilisation du onclick, puisque le onclick t'emmenerais vers la page et n'ouvrirais pas le menu, et tu rajoutes quand meme bon nombre de morceau de page inutile alors que quelques lignes de JS suffisent amplement.

Pour ce qui est du obj.getElementByTagName('ul'), obj est une variable renvoyant à document.getElementById(idmenu) à tout les coup, donc obj.get..... ne renvoi qu'aux ul contenu dans #idmenu. C'est d'ailleur une partie de la technique mise en oeuvre dans la version parfaite qui est à l'étude, mais il y a d'autres choses fantasmagorique cachées dérrières aussi !

@++

Le vendredi 6 août 2004 à 21:25, par jep :: site :: #

"J'ai quelques remarque concernant les menu utilisant les evenements onrollover et onrollout "
>> Oups... autant pour moi ! je voulais dire "onmouseover" et "onmouseout"

"lorsque tu survoles un menu, c'est pour choisir l'un des éléments qui le compose. Sinon, tu cherches ailleurs, en survolant un autre menu et dans ce cas, l'ancien sous-menu s'efface."
>> Oui, tout a fait d'accord. C'est juste que j'ai l'habitude de fournir à mes clients des interface dont le comportement ce rapproche des application "traditionnelle", d'ou la fermeture des menu ouvert au moment ou on les quittes ! Maintenant, chacun fait bien comme il veux du moment que ça marche et que le client est contemps !

"Etonnant, j'ai pourtant testé sur plusieurs geckos et je n'ai détecté aucun problème. Quelle version as-tu ?"
>> Firefox 0.9.2 / Mozilla 1.6 sous Win98

"Oui pourquoi pas en effet, mais ça revient à faire des pages supplémentaires qui ne sont pas obligatoirement pertinentes et peuvent même prêter à confusion."
>> Certe, en ce qui me concerne, je m'arrange toujours pour que les contenues de ses pages soit pertinent (Merci PHP pour la gestion des contenues !)... sachant que de toutes façon, ces pages ne sont destinées "à priori" qu'au personnes ayant désactivé JS... De toutes façon, j'évite la plus part du temps de faire des menu déroulant !


"Certes, mais faire un site qui ne fonctionne pas sous IE est un peu suicidaire et surtout un peu stupide : IE a le monopole, il ne faut pas s'obscurcir les yeux derrière les Standards"
>> Visiblement, on arrive pas à ce comprendre sur ce point ! Ce que je veux dire c'est que j'utilise JS, mais seulement pour émuler le comportement :hover avec IE... donc, ça marche sous IE et avec les autres navigateurs !

"Sinon, j'ai bien aimé ton menu en cascade, qui utilise aussi js mais d'une autre façon moins "imbriquée"."
>> ça, c'est mon cheval de bataille du moment : totalement extraire le JS de la source HTML pour accroitre la lisibilité, l'adaptabilité et la portabilité du code.

"les webnautes ayants desactivé le JS sont peu nombreux, il faut pourtant s'en occuper et donc, leur permettre l'acces au menu, l'affichage peut s'en trouver altéré mais ça reste très utilisable et à toi webmaster de t'arranger pour que ça soit le moins catastrophique possible !"
>> Exactement !

"Mais le menu dynamique parfait (mais avec JS, donc pas encore absolument parfait, mais la perfection n'existe pas parait-il) est en cours de réalisation !!!!! Bon j'avance pas fort en ce moment, mais vraiment je suis persuadé que mon idée est réalisable au vue de ma source d'insipiration."
>> Ben... en fait, ce qui est difficile c'est d'obtenirs un menu parfait "multibrowser" car des solutions parfaites pour IE (VBScript/JScript + ASP.NET) ou Gecko (Xul) existent... mais le meilleurs des deux monde, c'est pas pour demain !

"donc obj.get..... ne renvoi qu'aux ul contenu dans #idmenu."
>> tout a fait... ce qui est plus délicat, c'est de faire la différence entre les "profondeur" auquelles se trouvent les différente balises !

"mais il y a d'autres choses fantasmagorique cachées dérrières aussi !"
>> Lesquelles ?


Et pour finir :
"Bref, il y'a toujours du pour et du contre."
Auquel je rajouterai :
Chacun à ses methodes et ses préférences de travail aucune n'est meilleur que l'autres... l'important c'est que ça marche ! (et de préférence respéctueux des standard )

Le vendredi 6 août 2004 à 21:36, par ElMoustiko :: site :: #

Je vais repondre a 2 de tes questions a la fois jep (si si je te jure ! !!) : l'une des autres fonctionnalités que je cherche a mettre en place c'est l'extraction complete du js de la source (1ere reponse) et c'est possible (ma souce d'inspi le prouve ! ) (2eme "question"), mais je lutte a moitié quand meme !

Pour différencier la profondeur, le mieux est d'utiliser lastChild tu verifies la "profondeur" avec ca.

@++

Le vendredi 6 août 2004 à 21:37, par ElMoustiko :: site :: #

oupss j'ai ENCORE zappé un truc !, lastChild.tagName ^^

Le vendredi 6 août 2004 à 21:46, par Sibelius :: site :: #

En tout cas, cette discution a eu quelques effets sur le tuto :
- j'ai modifié le masquage initial en rajoutant un simple body onload="javascript:montre();" et en expliquant le pourquoi du comment
- j'évoque la technique de Jep dans l'introduction

Merci pour ce genre de débats... le menu déroulant soulève toujours beaucoup d'émois

Le vendredi 6 août 2004 à 21:51, par ElMoustiko :: site :: #

Oui voila qui est mieux, mais tu peux faire encore mieux ! plutot que de mettre le javascript dans la balise body (moins il y a de JS dans la page, mieux c'est ! enfin selon moi), tu appelles dans ton script la fonction montre() au chargement de la page, comme ca aucune manip de l'utilisateur (webmaster) et ca simplifie la mise en place (moins il y a d'endroit et de choses a modifier mieux c'est, et ca j'en suis sur ! )
Donc pour l'appel de la fonction au chargement : window.onload=montre;

Voila @++

Le vendredi 6 août 2004 à 23:32, par Sibelius :: site :: #

@ElMoustiko > Ok pour window.onload=montre; (tel quel ? c'est compatible et compris partout ?)

Le samedi 7 août 2004 à 10:12, par ElMoustiko :: site :: #

Oui à ma connaissance, ça fonctionne partout, en tout cas, FF, moz, IE 6.0, opera 7.23, ca fonctionne.

@++

Le samedi 7 août 2004 à 10:27, par Sibelius :: site :: #

Bien, je vais donc conserver cette méthode pour l'instant, car il me semble qu'elle a le meileur rapport qualité / facilité à comprendre pour un novice.
J'avoue que la technique de Jep est séduisante, mais nécessite des notions avancées en javascript que tout le monde (dont moi) n'a pas... or les CSS sont déjà assez ardues au départ pour les débutants

Le samedi 7 août 2004 à 10:57, par ElMoustiko :: site :: #

Oui mais si personne ne leur apprend, comment pourront ils avancer ? ! Nan j'exagere un peu sur ce coup la, c'est vrai que trop d'un coup ca n'est pas bon, mais je me souviens apres 2 semaines d'apprentissage du html, je voulais faire un menu deroulant, et j'ai manipuler un peu trop le javascript, et je ne connaissais rien aux "pouvoirs magiques" des css et de la structure de page "divisionnelle", j'etais tranquillement avec mes tables imbriquées (sans editeur WYSIWYG en plus ^^) et je n'arrivais a rien ou a des trucs vraiment lourd et impossible a mettre en place, incompatible avec certains navigateurs ... et quand je voyais les script de menu deroulant sur les sites JS je me disais, Wow c'est n'importe quoi le html ! Il aparait donc important d'indiquer une methode surement un peu technique au départ mais au final plus simple que de laisser ces maudits script JS à gogo. Parceque je doute d'etre le seul a avoir été debutant et vouloir faire un truc assez poussé !

Enfin encore une fois, point de vue discutable j'en conviens ! Mais tes talents de pedagogue devraient faire passer cet ecueil !

@++

Le samedi 7 août 2004 à 13:11, par Sibelius :: site :: #

ElMoustiko : "mais au final plus simple que de laisser ces maudits script JS à gogo"
>> Attention à bien mettre les choses au point avant de céder au fanatisme anti-javascript :
Les CSS ne sont prévus QUE pour la mise en page (position, couleurs, etc.) et c'est le Javascript qui est conseillé (oui, oui, ECMAScript conseillé par le W3C) pour tout ce qui est du domaine du dynamisme.

En fait, les normes prévoient :
- HTML pour la scructure
- CSS pour la mise en forme
- Javascript (ECMAscript) pour les effets

Il est parfois bon de rappeler que javascript est conseillé et fait partie des Normes. Bien sûr il est vivement souhaitable qu'il n'empêche pas la navigation aux personnes qui ne possèdent pas js.

La question qui pose souvent débat est l'utilisation de la pseudo-classe CSS :hover qui fait un peu la liaison entre la mise en forme (CSS) et le dynamisme (js) car elle permet des effets en CSS qui devraient être réservés à javascript.

Personnellement, je ne suis pas (comme les fanatiques anti-tableaux) de ceux qui rejettent à tout prix le javascript.

Le samedi 7 août 2004 à 13:20, par Laurent Denis :: #

Raphael, tu ne serais pas un peu fanatique, là, quand tu te demandes s'il est bien légitime d'utiliser :hover pour un effet dynamique :))) ?

Que peux-ton bien trouver à redire à l'utilisation d'un effet CSS parfaitement conforme à sa spécification ?

Le samedi 7 août 2004 à 13:55, par Xavier :: site :: #

Allusion a été faite dans la discussion à IE7 ( dean.edwards.name/IE7/ ) l'excellent travail de Dean Ewards. Ne pensez-vous pas que le pure CSS avec IE7 ne constitue pas une implémentation bien plus simple (et limitant les risques de bug) du menu déroulant ?
Autres avantages, IE7 apporte une compatibilité de IE sur bon nombre de points CSS2 (sélecteurs, transparence png...), et n'est pas chargé par les autres navigateurs. Ainsi les navigateurs bien nés surfent dans la légèreté (sans script).
A quand un tutorial en français sur l’installation et l’utilisation de IE7 ?
A noter également le travail de Peter Nederlof ( www.xs4all.nl/~peterned/c... Le principe est le même que IE7, mais au périmètre restreint à :hover donc plus léger.

Le samedi 7 août 2004 à 13:55, par Sibelius :: site :: #

@Laurent Denis > Disons que ça m'a titillé depuis que Eric Meyer s'est lui-même posé la question dans son dernier bouquin (son projet de menu déroulant où il utilise le hack IE7) et qu'il disait que la question soulevait un grand débat actuellement.
Je ne trouve rien à redire sur le comportement en lui-même : hover indique un effet au survol de l'élément.
Ce qui me gêne c'est que :hover se trouve sur une frontière : celle de la mise en forme (CSS) et celle du dynamisme (JS, ECMA).
Personnellement, je trouve qu'il n'est pas conforme d'utiliser hover pour des effets DHTML comme l'apparition/disparition d'autres éléments (appelons ces éléments "calques").

Bien sûr, rien n'indique le contraire dans les spécifications, mais je pense que le rôle de chacun doit être préservé : les CSS pour la mise en forme, les scripts pour les effets DHTML.

PS : content de te revoir

Le samedi 7 août 2004 à 13:58, par Sibelius :: site :: #

@Xavier > le hack IE7 n'est qu'une transformation en javascript des comportements CSS que devrait avoir IE. En clair : tout repose sur javascript pour fonctionner.

Le samedi 7 août 2004 à 22:55, par ElMoustiko :: site :: #

Je n'ai pas du tout dit qu'il fallait proscrire le JS, j'ai dit que le JS a gogo n'etait pas la solution, je suis au contraire pour l'utilisation partielle du JS qui permet de grandes choses tout de meme, cessez de deformez mes propos ^^

@++

Le dimanche 8 août 2004 à 15:22, par Franz :: #

On a adapté ce menu déroulant vertical dynamique pour notre site, et c'est vrai que sous FireFox 0.9 il y a scintillement. Cela vient à tous les coups du double appel du javascript dans les balises <dt> et <dl> : tu lui dis affiche-cache-affiche, et l'inverse quand tu sors du menu, d'où le scintillement.

Sur ton exemple ça ne se voit pas parcequ'il y a un fond blanc derrière, mais avec du texte c'est nettement plus visible. Il faudrait une fonction JS pour gérer tout ça, et une seule. J'ai cherché, mais j'ai pas encore trouvé.

En tout cas merci pour les sources !

Le dimanche 8 août 2004 à 15:50, par Sibelius :: site :: #

@Franz > je ne comprends pas ce que tu veux dire. Il n'y a qu'un seul appel à la foncton : uniquement lors du clic sur un menu (dt).
Et la fonction fait ceci : "cache tous les sous-menus" et "affiche le sous-menu désiré". C'est tout.
Je veux bien croire que cela pose un problème, mais dans la forme tout me paraît propre et logique.

D'ailleurs, tu veux bien me montrer l'url de ton essai, histoire que je voie ce qui buggue? Jep et Moustiko vont peut-être nous venir en aide et arranger tout ça...

Le lundi 9 août 2004 à 16:00, par xavier :: site :: #

Je reviens sur IE7;

Je suis d'accord avec toi Sibelius sur le fait qu'il faut toujours du javascript pour obtenir des menus déroulants sur IE. Mais quitte à avoir du javascript, IE7 me parait la meilleure solution :

1/ le développeur produit un code plus synthétique avec moins de risque de bug (voir la remarque de Franz et toutes les corrections que tu as du apporter depuis le début)

2/ les navigateurs autres que IE fonctionnent proprement sans javascript (moins lourd, moins de bugs..)
En fait ce qui m'étonne c'est ta volonté de vouloir implémenter une nouvelle fois des fonctionnalités qui sont déjà existantes, au travers de IE7 pour IE, et mieux au travers des standards pour les autres navigateurs.

Et je me disais que ce serait sympa d'avoir un tutorial sur IE7 qui apporte beaucoup plus que le simple :hover.

Enfin j'ai du mal à comprendre ton sentiment relativement à :hover (effet dynamique) qui n'aurait pas sa place dans les CSS. Est-ce que par exemple tu utilises un javascript pour tous tes liens lorsque tu veux gérer un soulignement sur ces liens ? Il me semble que :hover c'est super pratique et très simple, alors pourquoi le contourner ?

Le lundi 9 août 2004 à 16:22, par Sibelius :: site :: #

@xavier >
C'est vrai que IE7 est une solution apparemment très intéressante. Ce qui me gêne, c'est peut-être simplement qu'il s'agit d'un hack et que je les évite autant que possible.
Tant qu'une autorité n'a pas donné l'aval sur une méthode, je m'en méfie. Personne n'assure que tous les navigateurs vont interprêter ce hack correctement. Le javascript, quant à lui est conventionné et conforme à des normes : si le code est correct et valide, il fonctionne (normalement) partout correctement.

C'est vrai que l'avantage est que ce hack n'impose le javascript QUE pour IE et laisse (tous?) les autres navigateurs standards utiliser les CSS normalement.

PS : pour le bug de Franz, j'ai trouvé la solution : elle n'est pas dans le javascript mais dans la façon de positionner les éléments du site. Un collègue m'a confirmé que le positionnement flottant par exemple provoquait ces scintillements.


Ne me fais pas dire ce que je n'ai pas dit : Hover a tout à fait sa place dans les CSS tant qu'il reste dans le rôle qui est imparti aux CSS, à savoir la mise en forme.
Comme je l'ai dit à Laurent : Ce qui me gêne (et je ne suis pas le seul) c'est que :hover se trouve sur une frontière : celle de la mise en forme (CSS) et celle du dynamisme (JS, ECMA).
Personnellement, je trouve qu'il n'est pas conforme d'utiliser hover pour des effets DHTML comme l'apparition/disparition d'autres éléments (appelons ces éléments "calques") par contre pour un soulignement au survol (donc de la mise en forme), cela me paraît tout à fait approprié !

Le lundi 9 août 2004 à 18:40, par xavier :: site :: #

@Sibelius >
j'ai peut être quelques éléments à apporter concernant certains points que tu évoques.

1/IE7
On est d'accord ce n'est qu'un palliatif. Et comme tu l'as dit ce n'est finalement que du javascript. Il ne règle pas tous les pb, il se peut même qu'il en ajoute parfois. Mais comment se faire une opinion sans l'essayer ? Pourquoi ce javascript serait-il moins bon qu'un autre ?
Je peux te rassurer complètement : le javascript de IE7 ne peut être lu par aucun autre navigateur : son auteur propose en effet de l'insérer dans des "commentaires propriétaires Microsoft". En clair tous les navigateurs voient son appel comme un commentaire (et ne chargent pas les fichiers), tous les IE de versions inférieures ou égale à 6 chargent le hack.

2/ scintillement
La cause du scintillement n'est pas liée aux éléments flottants (même si retirer les éléments flottant règle le pb). Le scintillement a 2 sources :
- un "bug logique" (qui peut arriver en CSS aussi bien qu'en javascript) et qui consiste à donner des ordres contradictoires : lorsque je suis dans un état A le code conduit à l'état B, et lorsque je suis dans l'état B (apparition ou disparition d'éléments par rapport à A) le code conduit à l'état A. En gros il s'agit d'une boucle infinie (qui peut d'ailleurs mettre plus de 2 états en jeux). C'est assez sournois car on n'est pas dans la tête du navigateur et donc on a pas tout le détail de ce qu'il considère comme les états A et B.
- un bug IE lorsque l'on utilise des images : ce pauvre navigateur fait une requête http pour récupérer l'image à chaque changement d'état ce qui introduit un temps de latence et un certain effet de scintillement. On peut corriger ce pb par de subtiles dispositions au niveau du serveur web.

3/CSS
Je crois que j'ai compris ton parti pris. En revanche je ne sais pas ce qui le motive. Pourquoi penses-tu qu'il est raisonnable de cantonner CSS à la "mise en forme" à l'exclusion d'effets DHTML ? Personnellement, compte tenu de la difficulté que j'ai bien souvent à mettre au point un javascript, j'ai trouvé le :hover bien pratique.

Le lundi 9 août 2004 à 19:08, par Sibelius :: site :: #

@Xavier >

1- C'est vrai que je n'ai pas testé, mais il me semblait bien avoir cerné le principe.
Donc il ne s'applique qu'à IE. Mais que se passe-t-il pour les <em>autres</em> navigateurs qui ne respectent pas totalement les Standards ?

2- Scintillement. Voilà une explication ma foi fort intéressante en effet, même si ma "logique" me semblait claire :
- l'événement ne se produit QUE sur un onclick
- la fonction commence par effacer tous les sous menu
- puis elle affiche le sous-menu demandé
Je ne vois pas ce qui peut poser problème. As-tu une alternative à me proposer ?
En attendant, je n'ai toujours pas d'exemple pour illustrer ce problème, et tous les essais que j'ai pu faire n'ont pas décelé de problème ;-/

3- En fait le W3C lui-même suggère :
- le HTML pour la structure
- le CSS pour la mise en forme
- les scripts (dom) pour les effets

J'avoue que le :hover est extrêmement pratique et ouvre de belles horizons, mais je suis perplexe quant à son domaine d'activité.

Le lundi 9 août 2004 à 20:03, par xavier :: site :: #

@Sibelius >

1/ Personnellement je ne connais pas de navigateur alternatif qui dans sa ou ses versions les plus récentes ne gère pas raisonnablement :hover. En connais-tu ? Parce que si c'est le cas je vais sans doute devoir réviser l'usage fréquent que je fais du :hover.

2/ je ne porte pas de jugement sur ton code qui fonctionne sur les exemples que tu donne. Mais en revanche si Franz constate un scintillement c'est que <strong>son</strong> implémentation de <strong>son</strong> menu induit une boucle, ou qu'il utilise une image (en fond par ex), qu'il fait apparaitre et disparaitre sous IE.
Sans le code qui "scintille" sous les yeux c'est difficile d'en dire plus.

3/ bon bon je vois ton âme pure.
une dernière tentative : peut-être que le W3C voulait dire scripts pour les effets qui echappent au pouvoir de CSS. Autrement dit :hover ne permettrait pas vraiment des effets mais de la mise en forme, de menus déroulants par exemple ?

Le lundi 9 août 2004 à 20:57, par Sibelius :: site :: #

@Xavier >

1- Non, je n'en connais pas, mais vu que ce n'est pas impossible, ça limiterait l'accessibilité de ce hack (je chipote? oui sans doute)

2- Oui, j'aimerais beaucoup le voir de mes yeurx en effet, j'aurai une base de travail pour y remédier.

3- Je vais bientôt passer pour un intégriste Mais je ne sais pas ce que le W3C a dans la tête, il est vrai qu'il est souvent flou dans ses directives. Je le prends au pied de la lettre, peut-être ai-je tort en effet.

Ps : j'aime beaucoup ton site... tu n'embaucherais pas par hasard un jeune (enfin, façon de parler) intégrateur-designer motivé ? :-p

Le mardi 10 août 2004 à 08:30, par Laurent Denis :: #

@Xavier, Sibelius : puis-je mettre mon grain de sel à propos du "rôle des autorités" que vous sous-entendez pour IE7 comme pour les :hover ?

Pour IE7, il n'y a tout simplement aucune autorité possible en la matière pour dire "c'est bien" ou "c'est mal" C'est un simple mécanisme qui ne contrevient à aucune norme, proposé pour pallier certaines lacunes d'IE, et d'IE seul.

C'est d'ailleurs pourquoi je ne m'en sers pas personnellement : un hack trop lourd traitant d'un navigateur unique, sur des défauts d'implémentation qui n'ont rien de dramatique dès lors qu'une dégradation de la présentation dans IE n'entrave pas l'accès au site. Bien-sûr, les utilisateurs d'IE n'ont pas la même expérience de navigation que ceux d'Opera ou de FireFox. Mais vouloir que tous les utilisateurs aient une expérience de navigation identique pour un site est pour le coup un contre-sens sur la notion d'interopérabilité.

Pour les CSS qui n'auraient pas à traiter les effets : Sibelius, je crois que tu t'imposes une stricte séparation des rôles entre CSS et DOM qui n'a absolument pas été prévue par les normes. Au contraire, celles-ci invitent fréquement à allier ces deux outils. Par exemple:

"Corrélations avec d'autres langages. Les propriétés décrites par cette spécification forment un jeu consistant pour le modèle de formatage des présentations visuelles et auditives. Le langage CSS permet d'accéder à ce modèle mais les corrélations avec d'autres langages sont aussi possibles. Par exemple, un programme JavaScript peut changer de façon dynamique la valeur de la propriété 'color' d'un élément donné ;"
www.yoyodesign.org/doc/w3...

Le mardi 10 août 2004 à 11:25, par xavier :: site :: #

@Laurent
Cela m'ennuie d'être épinglé sur la question de l'autorité. Je croyais les sous entendus plutôt de le sorte : "mes propos fruits de mon expérience relatent une vision personnelle nécessairement incomplète...". Malheureusement tu en as décelé d'autres.
Donc pour ce dernier post je vais prendre plus de précaution.
J'ai, du fait de mon métier à coder des pages web sous certaines contraintes. Cela m'a forgé une expérience et une vision du web ainsi que des outils disponibles. Je conviens que cet angle de vue n'éclaire pas toute les situations possibles, et que ce faisant d'autres webmasters ont une acuité pour des choses qui restent de peu de relief à mes yeux. C'était le cas je suppose entre Sibelius et moi, et finalement c'est pas mal de faire naître un peu de relief là ou l'on ne regardait pas.

Concernant ta deuxième remarque et d'après mon expérience, IE concentre plus de 90 % des postes clients et la même proportion sans doute d'écarts aux standards constatés sur les navigateurs récents. Donc IE7 adresse une masse considérable de difficultés. J'aimerais que les écarts aux standards de IE n'induisent juste qu'une expérience de navigation un peu différente. Malheureusement (selon mon expérience) ce n'est pas le cas. J'ai honte, mais j'ai fait des pages web (valides xhtml et css) qui sont absolument invisibles de certains navigateurs (IE mac principalement). Dans la pratique, au moment d'intégrer un design je suis obligé de penser aux défauts (relativement aux standards w3c) des navigateurs, de IE essentiellement et d'introduire des verrues. En cela IE7 qui améliore IE (insuffisamment à mon goût) soulage mon angoisse, et augmente ma productivité. C'est un point de vue très pratique j'en conviens. Mais je n'ai jamais réussi pour l'instant à produire une page web sans hack même en réduisant mes prétentions à la rendre simplement pratiquable. Dans ce contexte IE7 me semble plutôt propre, et simplificateur.

@Sibelius
je suis au regret .. enfin je n'ai clairement pas de proposition à te faire actuellement.

@Tout le monde
Je change de sujet en espérant cependant n'importuner personne.
Je viens de mettre à disposition un petit outil XSL de "marquage sémantique" : ajout de markup simple à une page web sur la fois d'un lexique externe. L'idée est de prendre en charge par exemple un vocabulaire métier, automatiser la pose de liens...
www.ultra-fluide.com/ress...

Si vous souhaitez me contacter :
xavier.boully at ultra-fluide.com

Le mardi 10 août 2004 à 12:38, par Laurent Denis :: #

@Xavier : Toutes mes excuses pour cette "épingle" involontaire due à ma maladresse d'expression. Ma remarque ne concernait que la réserve émise par Sibelius : "Tant qu'une autorité n'a pas donné l'aval sur une méthode, je m'en méfie", et ne sous-entendait aucune "prise d'autorité" abusive de ta part

Ton Semark.xsl m'intéresse diablement. J'y vais de ce pas

Le mardi 17 août 2004 à 01:06, par Guic :: #

Bonjour,

on te le dit souvent, mais encore bravo pour ton site !
Le menu horizontal sous Opera 7.11 est ... vertical.
Je cherche désespérement un menu qui soit compatbile avec TOUS les navigateurs et je peux vous affirmer que c'est mission impossible.
J'avais cru toucher du doigt la fin de ma quête, mais hélas !

Le mardi 17 août 2004 à 07:48, par Raphael Goetter :: site :: #

@Guic > c'est sans doute une histoire de float : j'ai toujours eu des soucis avec les menus hirizontaux (float) et Opera.
En tout cas, il est bien horizontal sur Opera 7.23

Le mardi 17 août 2004 à 09:27, par Laurent Denis :: #

@Raphael : c'est un problème classique. Il suffit de spécifier la largeur du conteneur (width: 100%; pour ton #menu { par exemple).

C'est une imprécision de CSS2 qui donne lieu à deux interprétations divergentes sur la largeur par défaut du conteneur positionné d'un flottant :

- la plupart des navigateurs ont opté arbitrairement pour la valeur "auto": les éléments flottants cumulés déterminent la largeur finale calculée du conteneur. Il ya donc forcément la place pour que "ça flotte".

- Opera 7 considère qu'il n'y a pas de largeur imposée par défaut, et la largeur du conteneur est donc déterminée par l'élément flottant (<li>) le plus large. Il n'y a donc jamais la place pour que "ça flotte".

Samuel Latchman propose un hack pour les cas où spécifier la largeur pose un problème :
www.latchman.org/sam/inde...

Le mardi 17 août 2004 à 09:33, par Laurent Denis :: #

Fautes de typo, il fallait lire bien-sûr :

" la plupart des navigateurs ont opté arbitrairement pour la valeur "auto" **suivante**: les éléments flottants cumulés déterminent la largeur finale calculée du conteneur."

"Opera 7 considère qu'il n'y a pas de largeur **cumulée** imposée par défaut..."

Le mardi 17 août 2004 à 16:37, par Raphael Goetter :: site :: #

Merci beaucoup Laurent pour ces précisions et cette solution.

Le mardi 17 août 2004 à 23:55, par Guic :: #

Merci à Laurent et Raphael pour leur réponse.
J'ai du coup chargé la version 7.23 d'Opera, mais j'ai curieusement toujours le même problème. (F5, vidage de cache, création du menu en local .. rien n'y fait)

Je vous promet que si je trouve d'où cela vient, je vous en informe

Le mercredi 18 août 2004 à 02:57, par Guic :: #

Je n'avais pas pris en compte la solution de Laurent désolé.
C'est effectivement la solution, puisqu'en rajoutant le width: 100%;, cela marche très bien.

D'ailleurs Raphael l'a aussitôt mis en place ... quelle réactivité !!
Merci à vous.

Le mercredi 18 août 2004 à 23:16, par Guic :: #

@ Raphaël > la même solution peut être appliquée à ton menu déroulant horizontal 2 de ta galerie.

Le jeudi 19 août 2004 à 11:39, par Raphael Goetter :: site :: #

@Guic > oui tout à fait, je vais rajouter cette astuce.