Bobe
-
Compteur de contenus
72 -
Inscrit(e) le
-
Dernière visite
Messages postés par Bobe
-
-
CSS permet de faire cela. Je te renvoie au chapitre 17 de la spécification
-
c'est une impression globale qui a tendance à s'installer : on dit que c'est mal de penser comme ça pour trouver une justification à un problème actuellement non réalisable correctement en CSS.
C'est parce qu'on sort doucement d'une période de grande tolérance et de tendance à faire n'importe quoi. Par contre coup, la tendance actuelle dans la frange "pro-standard" est d'être peut-être trop excessif dans les restrictions qu'elle s'impose et/ou souhaite imposer dans l'utilisation des outils normalisés.
Je trouve ça dommage : les CSS ne sont pas parfaits ? soit. Acceptons-le, plutôt de dire qu'il faut penser différemment pour s'y adapter.CSS n'est pas parfait loin s'en faut. Par contre, attention à bien faire la distinction entre les carences de CSS et celles de certains navigateurs
-
je trouve que c'est une façon de justifier une carence évidente des CSS.
Quelle carence ? Laurent Denis a indiqué les mécanismes prévus pour ce type de mises en page dans le message qui précède le tien.
-
Il faut que l'option MultiViews d'apache soit activée.
et http://domain.tld/fichier.html
pourra être simplement appellé avec l'url:
-
Ben si cet historique m'affiche 10 fois "Webmaster-hub", il ne me servira pas à grand chose et encore moins au non-voyant pour qui c'est une fonction indispensable.
A ma connaissance, il n'y a pas d'autre moyen pour retourner sur une page précise.
Il a dù y avoir une incompréhension quelque part là
Je défend l'idée de mettre le titre du document dans l'élément TITLE et rien d'autre (donc pas le nom du site), en aucun cas de n'y mettre que le nom du site.
-
J'ai oublié de préciser que je parlais de l'historique disponible avec le bouton "Back".
Il en existe d'autres ?
Quand j'ai visité plusieurs pages (du même site ou non), j'utilise cette liste pour revenir sur la page de mon choix... en quoi est-ce une utilisation incorrecte ?Non non, c'est une utilisation correct (chacun l'utilise comme il veut). Ce qui est incorrect, c'est de penser que l'historique a pour rôle d'indiquer également le nom du site (quoiqu'il pourrait avoir un tel rôle, il faudrait simplement un moyen sùr et normalisé de récupérer le nom du site, par exemple <meta name="Sitename" content="le nom du site">). Évidemment, on peut indiquer ce nom dans l'élément TITLE, mais je vois mal comment on peut justifier sa présence dans cet élément (hormis pour d'éventuelles raisons pratiques)
-
Le titre (balise title) de la page est repris dans l'historique. Quand j'ai parcouru plusieurs pages (parfois de sites différents) je peux choisir la page sur laquelle je veux retourner... à condition que le libellé soit suffisamment précis (donc le nom du site et le titre de la page).
C'est qu'il y a méprise sur le rôle exact de l'historique d'un navigateur. L'historique fournit une liste des derniers documents récupérés, et non des derniers sites visités (Enfin rien n'empèche un navigateur de gérer ça autrement, par exemple en regroupant les entrées par nom de domaine).
Méprise aussi sur le rôle de cet élément TITLE qui est de donner un titre au document, non d'indiquer dans la foulée le nom du site.
Bien sùr, ma contribution porte sur l'aspect théorique. Après, qu'il y ait un avantage pratique est tout à fait possible.
-
Pour moi la différence entre le title et un titre h1, c'est que dans la balise title il faut absolument que l'internaute sache sur quel site il est en plus du thème (non exhaustif) de la page
Non car l'adresse du site est déjà indiquée dans la barre d'adresse.
Indiquer l'adresse du site ou même le nom du site dans le titre de la page est au contraire inutile. C'est le document que je consulte, pas le document sur tel ou tel site.
P.S. je suis plus partisant d'un seul h1 pour une raison de clarté (ben oui un titre principal c'est plus parlant)Il y a déjà l'élément TITLE pour indiquer le titre principal du document. Et ça tombe bien car un document n'a qu'un titre principal, et justement, l'élément TITLE doit être unique dans le document.
Une solution toute simple est de styler directement l'élément TITLE
head { display: block; }
head * { display: none; }
head title {
display: block;
margin: 10px;
border: 1px solid black;
padding: 4px;
}(mais IE voudra rien savoir
) -
Le problème n'est pas du coté du concepteur du document mais du coté du navigateur. Opera par exemple gère très bien le déroulement d'un bloc muni d'un ascenseur avec les flèches du clavier. MSIE également. Pas Mozilla par contre, sauf dans la toute dernière version.
Dans tous les cas, il faut d'abord cliquer avec la souris dans le bloc en question pour lui donner l'attention (focus).
-
Mais, en même temps cela demanderais pas mal de compétences techniques, en plus d'un redactionnel impecable, car le DOM est comme tu l'à vu un truc très technique, un peut déroutant au départ et qui, de fait, se borne souvent à getElementById et getElementsByTagName...
Mais bon si ya une iniative sur ce sujet je veux bien en être, je suis venu au DOM et au concept de séparation comportement/structure par la problématique de l'accessibilité, (qui est l'essentiel de mon activité pro), autrement dit pour EcmaScript, comment rendre un script non intrusif ni destructeur pour l'accessiblité d'un contenu.
Je peux apporter pas mal d'éclairage la dessus, par contre je ne me risquerais pas, en tout cas pas tout de suite sur de la rédaction de ressource plus technique, les scripts que je produis fonctionnent bien mais face à une compétence comme celle de l'ami bobe, je mesure le chemin qu'il me reste à parcourir, (attention.. Top départ !)
.Je ne m'y risquerais pas non plus (complètement autodidacte, j'ai des difficultés à transmettre mes connaissances et une pratique rédactionnelle médiocre).
En passant, merci pour la leçon bobe, et si tu à une minute pour glisser les deux ou trois commentaires qui vont bien, je suis sur que tu vas créer des vocations ... :)Comment ça ?
-
Oula, il faut savoir exactement de quoi on est en train de parler là.
Prenons une URL simplement pour ce qu'elle est, c'est à dire une chaine de caractère:
http://domain.tld/script.cgi?var1=aaa&var2=zzz&var3=sss
C'est différent.
Maintenant, remettons nous dans le contexte d'un document (x)html et on retombe sur mon explication précédente (et celle de Nudrema).
Je sais que toi et Denis comprenez très bien le fonctionnement de tout cela, simplement, attention aux raccourcis susceptibles de troubler le lecteur.
adn: il y a quatre caractères spéciaux en html. &, <, > et "
Le premier sert pour déclarer une entité de caractère. Si tu veux utiliser le caractère simplement pour ce qu'il est, utilise & (Cas le plus courant: les esperluettes délimitant les paires nom/valeur dans une URL)
Les chevrons ouvrants et fermants servent évidemment à déclarer les balises dans la structure du document. À remplacer respectivement par < et > si l'on veut le caractère lui même.
Le guillemet sert pour délimiter les valeurs des attributs dans les balises ouvrantes. Utile essentiellement si l'on veut ajouter un guillemet dans la valeur d'un attribut, par exemple, dans le cas d'un texte dans l'attribut title.
Comme les valeurs d'attribut peuvent être entourées d'apostrophes plutôt que de guillemets, xhtml a introduit une nouvelle entité de caractère pour l'apostrophe: '. En html, utiliser l'entité numérique: & #39; (sans l'espace bien sùr), simplement dans le cas où l'on veut une apostrophe dans une valeur d'attribut délimitée par des apostrophes.
-
Non, Denis, ce n'est pas la même chose. & marque le début d'une entité de caractère. & représente une esperluette.
-
Merci beaucoup, j'ai appliqué cette méthode sur mon site et j'en suis très satisfait. C'est super.
Ah, bonne nouvelle
Il manque une ressource francophone sur le sujet, vous ne trouvez pas ?En effet
-
Pour le deuxième, vous mettez application/xhtml+xml dans le meta du "content-type", mais vous indiquez cela également avec les en-têtes http ?
Il faudrait montrer le script ou donner un lien vers la page aussi
-
Il y a des différences entre le mode de compatibilité (doctype incomplet ou pas de doctype) et le mode standard. Votre page de tests a t-elle un doctype ?
Après entre du XHTML déclaré comme tel ou déclaré comme du HTML, il y a par exemple nodeName qui renvoie le nom exact de l'élément et non tout en majuscule.
À propos de sous menus, on en parlait dans un autre forum, ça vous interessera peut être:
-
Un article qui peut aider:
-
Seul petit probleme sur Netscape 7 où il est difficile d'accrocher le sous-menu, mais bon, netscape 7 est particulièrement buggé sur ce genre de comportement.
Quelle version de Netscape 7 ? Ou mieux, la version de Mozilla sur laquelle est basé le netscape 7 avec lequel tu as fait le test.
Le dernier en date en ce qui me concerne: on peut obtenir un focus sur un lien en display:none ou visibility:hidden avec la navigation tabulaire, qui en plus utilise une séquence de touche propriétaire, le pied total quoi !...
Ah oui, interessant ce bug
Seul petit bémol, à mon gout et parce que j'aime bien triturer le code, je trouve la syntaxe un chouia compliqué à suivre, donc à adapter eventuellement.Je peux fournir des explications si besoin.
Enfin concernant la partie script, je pense que c'est assez propre et clair (au niveau de la lecture).
J'ai essayé de faire quelque chose d'un peu modulaire. On peut par exemple déplier manuellement un sous menu, il suffit de faire:
ComplexMenu.unfoldingSubMenu(obj);// obj est l'objet représentant un UL de classe 'submenu'
Pratique pour que, par exemple, le sous menu correspondant à la section dans laquelle on se trouve soit déplié par défaut (Ce serait bof dans l'affichage par défaut qu'on a là, mais ça pourrait être bien avec un affichage en deux colonnes avec le menu d'un coté et le contenu de l'autre):
if( typeof(document.getElementById) != 'undefined' )
{
window.onload = function() {
ComplexMenu.initialize();
ComplexMenu.unfoldingSubMenu(document.getElementById('section-active'));
}
}Avec un id 'section-active' sur le UL de classe 'submenu' correspondant à la section ou rubrique du site dans laquelle on se trouve.
Bon, ça pourrait évidemment être encore plus personnalisable. Par exemple, désactiver le dépliage d'un sous menu.
J'en profite pour corriger un petit bug, hideOnActicate -> hideOnActivate
-
& bull; ou & #8226;
-
Oui, encore une fois c'est bien ce que j'écris ensuite, non ?
En tout cas, merci pour ces confirmations
Oui, j'apportais juste une précision, comme tu ne semblais pas sùr de toi...
-
Toutes mes certitudes s'effondrent !!
On peut donner des dimensions à une balise <a> ?? (pourtant en-ligne non remplacée)
Non non, on ne peut effectivement pas, sauf si l'élément A en question est positionné ou qu'il flotte (Auquel cas, display passe automatiquement en block; http://www.yoyodesign.org/doc/w3c/css2/visuren.html#q24)
-
http://dev.webnaute.net/BAS/Menu_dynamique
Sous IE, il me met le dernier item, "menu 5" à la ligne et a tendance à ne pas refermer les sous menus parfois.
Bon, pour le menu5 qui se met à la ligne, c'est parce que IE limite la largeur d'un bloc positionné à celle de son bloc conteneur. Et comme j'avais mis des marges latérales à l'élément BODY, et que le UL racine du menu héritait de la largeur calculée de BODY, il n'y avait pas assez de place pour que tous les LI soient alignés.
Sous Opera 7.50, c'est comme si je n'avais pas mis float: left;C'est un bug:
http://www.latchman.org/sam/index.php/2004...peraIlFlottePas
Corrigé dans la 7.60.
Sous Opera 7.60p1, presque parfait, sauf que le premier item, "accueil", est caché
Là, c'est encore pire avec les corrections que j'ai faite...
Mais si je désactive le javascript et que je recharge le document, je peux constater que l'affichage est parfait avec les menus dépliés, donc ce n'est pas un problème de CSS. Et je suis sùr de la partie du script qui masque les sous menus au chargement du document, donc une mauvaise gestion dynamique des styles de la part de Opera 7.60 à priori. (Bon, en même temps, c'est une preview1, faudra voir avec une version plus stable de cette branche).
Tip: Toujours donner des marges externes et internes nulle à l'élément body. Sinon, cela peut poser problème avec IE. Là, le UL positionné se retrouvait positionné au dessus de l'élément HTML (car body avait un margin-top de 4%) et lorsqu'on arrivait avec le curseur de la souris sur l'espace séparant l'item de menu du bloc de sous menu, IE considérait qu'on passait sur l'élément html et refermait donc le sous menu. Cela ne fait pas ce bug absurde si le UL du menu est au dessus du BODY (margin: 0; padding: 0; sur l'élément BODY donc pour ne pas avoir de surprise) ou autre élément.
-
http://dev.webnaute.net/BAS/Menu_dynamique
Bon, alors là:
C'est parfait sous Firefox et autres geckos
Sous IE, il me met le dernier item, "menu 5" à la ligne et a tendance à ne pas refermer les sous menus parfois.
Sous Opera 7.60p1, presque parfait, sauf que le premier item, "accueil", est caché
Sous Opera 7.50, c'est comme si je n'avais pas mis float: left;
Bon, que des problèmes de CSS en tout cas, le script en lui même semble fonctionner parfaitement
Petits extra:
La CSS est agencée de telle manière que si l'écran est trop petit, les items se mettent sur plusieurs lignes et dans un alignement parfait. J'aime beaucoup
Sur un click sur un lien d'un sous menu, le sous menu est refermé au lieu de rester ouvert et l'attention (focus) est retiré du lien.
À tester éventuellement sur d'autres navigateurs (au moins Safari). J'essaierai de corriger les problèmes de CSS.
-
Voila qui devrait satisfaire l'ami pierre duquel nous n'avons plus de nouvelles...
Arf, c'est vrai. J'espère qu'on ne l'a pas effrayé avec nos considérations techniques
hideSubMenu
referme tous les objets ul référencés, ce qui ne permet pas d'inclure des sous-sous menus ?
Referme l'élément UL de classe 'submenu' enfant du LI sur lequel est référencé l'évènement onmouseout si l'utilisateur quitte le LI en question.
Si je comprends bien, la syntaxehideSubMenu: function()
passe la fonction en référence de l'objet, c'est donc équivalent à une instanciation de classe ???
Pareil pour
make :
tu à un lien de référence sur cette déclaration ?
Cela s'appelle une déclaration littérale d'un objet.
Il y a deux façons de déclarer un objet:
classique, avec un constructeur:
function monObjet(var1, var2)
{
this.mavar1 = var1;
this.mavar2 = var2;
this.maMethode = function() {
/* du code */
};
}
// instanciation
var obj = monObjet(x, y);Utile plutôt si plusieurs instanciations de l'objet peuvent être nécessaires.
littérale, sans constructeur:
var obj = {
mavar1: var1,
mavar2: var2,
maMethode: function() {
/* du code */
}
};Pas d'instanciation, l'objet est directement utilisable. Par contre, on a donc pas de constructeur. On ne peut pas créer une autre instance de l'objet.
Je ne connaissais pas cette syntaxe très intéréssante, mais il est vrai que bien qu'apprentis forcené du DOM, je trouve qu'il est très compliqué de trouver des tutos/doc/références qui ne se contente pas de réécrire bêtement les specs...
Ah, mais cette façon de déclarer un objet est décrite dans la documentation java script:
http://devedge.netscape.com/library/manual...nt.html#1013090
En tous cas en francophonie un tuto bien fait sur le couple EcmaScript / DOM fait cruellement defaut et ne favorise pas l'effort nécessaire de séparation comportement/structure, qui n'est somme toute que l'équivalent de la séparation contenu / forme introduite par la standardisation, qui nous débarasserait des bouillies javascriptés actuelles.Oui, il manque vraiment une référence francophone de qualité (mais y a t-il seulement une référence anglophone de qualité ?).
Et cela représenterait un boulot conséquent d'en créer une.
P.S: Petit ajout à mon message du vendredi 27 août. Le DOM 3 Events précise que l'ordre d'appel des guetteurs enregistrés sur un objet avec addEventListener() est le même que l'ordre d'enregistrement, donc premier enregistré, premier appellé
If two event listeners {A1, A2}, which are part of the same group, are registered one after the other (A1, then A2) for the same phase, the DOM event flow guarantees their triggering order (A1, then A2).http://www.w3.org/TR/DOM-Level-3-Events/ev...vents-listeners (paragraphe 1.2.2.2 - "event groups")
-
Bon, voilà ce que ça donne pour l'instant:
http://webnaute.net/temp/Menu_dynamique
Le code javascript est fait à l'arrache et pas vraiment propre et structuré pour l'instant, mais ça fonctionne dans firefox 0.9.3 et Opera (sauf que lui me fait des bizzareries avec les flottants mais c'est sùrement corrigeable). J'adapterai pour IE demain et j'essaierai de le tester sous Konqueror également.
Super,En passant felicitation pour webnaute...
Merci
En passant, j'ai été surpris de ne rien trouver de vraiment convaincant qui serait dans l'esprit de l'article de PPK ( séparation comportement/structure).Faire du JavaScript/DOM en faisant complètement cette séparation est encore peu répandu.
Et tu à raison, c'est hallucinant qu'Opéra ne supporte pas document.styleSheets...
Et toujours rien avec la version 7.60
pb avec les boites verticales
dans (X)HTML et CSS
Posté · Modifié par Bobe
Toi oui. Les lecteurs de ce fil, pas forcément.
Non, les CSS comme tout en ce bas monde ne sont pas parfaites.
Ma démonstration avait juste pour but de montrer que ce que veux l'initiateur de ce fil est possible avec CSS2, donc dire qu'il y a une carence des CSS est complètement faux et c'est ce que je tenais à mettre en lumière. Par contre, c'est effectivement non géré par certains navigateurs incontournable du marché et donc non utilisable à l'heure actuelle pour un site grand public.
À l'avenir, tu devrais faire plus attention de dissocier clairement l'aspect théorique et l'aspect pratique des choses pour ne pas induire les gens en erreur.