LaurentDenis
-
Compteur de contenus
1 281 -
Inscrit(e) le
-
Dernière visite
Tout ce qui a été posté par LaurentDenis
-
FireFox et Opera répondent à deux approches totalement opposées en matière d'ergonomie: - FireFox appartient à la lignée des navigateurs minimalistes mais extensibles - Opera est une "suite" logicielle (navigateur, mail, rss...) qui n'est pas extensible, mais fournit par défaut un très nombre de fonctionnalités, dans un interface très librement configurable. Dans le premier cas, l'utilisateur doit "assembler" le navigateur qui lui convient en ajoutant des extensions. Dans le second, il peut configurer ses outils à sa guise en retranchant ce qu'il ne souhaite pas utiliser. Ce sont donc deux logiques différentes, mais complémentaires en fait car elles répondent à des souhaits différents de la part des utilisateurs. La comparaison est donc d'un intérêt limité, car le choix de l'un ou l'autre navigateur est largement subjectif Ce qui est intéressant, en revanche, c'est que cette "complémentarité" de réponse aux attentes des utilisateurs montre que ceux-ci ont tout à gagner à ce que l'offre d'outils de navigation soit diversifiée.
-
Images décalées vers la gauche sous mozilla et pas
LaurentDenis a répondu à cath.h - Forum : (X)HTML et CSS
Le problème ne relève pas de CSS (au moins dans un premier temps) : il faut d'abord impérativement corriger le code HTML pour aboutir à un code valide. En l'état du code, le comportement des navigateurs n'a rien de rationnel En effet, on relève rapidement: - 4 éléments <body>... (l'élément <body> doit être unique) - plusieurs liens vers la feuille de style dans ces éléments body (<link> ne doit se trouver que dans l'élément <head>) - et de nombreuses autres erreurs Peut-être devrais-tu commencer par la lecture de cet excellent tutoriel: Écrire une page Web. -
demande aide pour afficher feuille de style
LaurentDenis a répondu à merlin - Forum : Les langages du Net
C'est invalide en HTML comme en XHTML. Dès lors, rien n'oblige un navigateur à en tenir compte, et rien ne garantit que ceux qui en tiendront compte le feront correctement sans dégrader le rendu. -
Pour évacuer tout de suite une mauvaise question, je n'ai aucun navigateur à vous vendre : le choix in fine d'un navigateur ne tient pas à des considérations objectives, mais au pire à des circonstances, et aux mieux à des questions de goût. Mais cet article du Monde est navrant, et je regrette de voir un quotidien national reprendre inconsidérément et sans critique la "ligne du parti", c'est à dire le discours officiel cherchant actuellement à vendre les excellents navigateurs que sont Mozilla et FireFox. A côté de ce qui est justifié, on y trouve pêle-mêle : - l'idée qu'un navigateur alternatif serait, en raison de ses qualités propres, responsables d'une "amorce de frémissement de frétillement à la baisse des statistiques d'utilisation d'IE". Ce sont les problèmes de sécurité d'IE et de Windows, pour la première fois évoqués dans des medias grands publics, qui en sont responsables. Pas FireFox, quelque-soit ses qualités. - le FUD : "si vous n'avez pas Windows XP, il vous faudra payer pour être à jour". Pour être à jour des correctifs de n'importe quelle application, il est recommandé en effet d'en utiliser la dernière version mise à jour. - Google et son éventuel-hypothétique-navigateur... Ce qui n'est au mieux qu'une rumeur de blog que rien à l'heure actuelle n'est venu confirmer (au contraire). Ah... Si seulement c'était aussi simple, tout cela, comme la vie serait belle !
-
Puisqu'ElMoustiko essaye de me convaincre que le javascript n'est pas le mal incarné, j'ai testé Précision sérieuse tout de suite : je ne crois pas que ce soit le mal incarné et les scripts d'ElMoustiko sont passionnants à suivre. Revenons à nos moutons : Sous Opera - au chargement de la page, c'est un peu surprenant : le menu apparaît intégralement, et puis "plop", tout disparaît ! En fait, javascript a commis son crime après le rendu HTML brut et après le rendu CSS de la page, le menu s'est donc "replié", d'où cet effet suprenant. -Les items se déroulent tout à fait normalement. Je passe mon curseur sur l'item 1, il s'ouvre... Je descends les sous-items... Je vais passer de "item 1.9" au "titre 1" qui suit... et Argh ! Tout s'est refermé ! C'est logique puisque je ne suis plus en "on mouse over" sur l'élément enfant, mais que je suis revenu sur un "on mouse over" de quoi au juste ? peut-être bien le body ? Bref, je m'aperçois que les déplacements intuitifs de ma souris n'induisent pas les comportements attendus du menu. J'arrête là le test: en bon utilisateur que ça agace, je ne lit pas le site. Sous IE - Premier test avec IE5.0 Windows... C'est pas charitable, je sais. Mais n'empêche que si veux cliquer sur un sous-item du menu... Je peux toujours courir ! Dès que mon curseur de souris quitte "Titre ", tout se replie ! Je me suis encore arrêté là, puisque je suis vraiment le cas type du client-roi, c'est à dire un râleur impénitent. Sans souris Je n'ai pas essayé. On verra demain Conclusion sérieuse Le menu déroulant pose de tels problèmes: - d'interopérabilité, avec ou sans notion très large de la dégradation admissible, - d'accessibilité (essayez sans souris, je l'ai fait en fait) ... que c'est définitivement une idée aussi abominable que séduisante. Cela n'enlève rien au mérite de cette tentative, ni de l'entreprise javascript d'ElMoustiko ici, dont le script d'images vignettes/agrandies sur la même page est excellent. Ici, ce n'est pas le script qui est mauvais, c'est l'idée de menu déroulant Web dans le cadre des technologies actuelles
-
demande aide pour afficher feuille de style
LaurentDenis a répondu à merlin - Forum : Les langages du Net
Nous aurons peut-être la réponse de merlin lui-même, mais l'inclusion d'un <style> dans le body est plus pratiquée qu'on le croit, et marche mieux qu'on le voudrait. Voir l'exemple classique d'AOL Info -
Autre solution, plus simple : utiliser uniquement les effets de bordures sur les autres éléments pour obtenir le résultat visuel attendu via CSS, et mettre les hr en display:none; ou mieux en visibility: hidden. Typiquement, la ligne horizontale sera obtenue par un border-top ou un border-bottom du div conteneur.
-
demande aide pour afficher feuille de style
LaurentDenis a répondu à merlin - Forum : Les langages du Net
Juste par aquis de conscience : ton bloc <style> ne se retrouvait pas dans le <body>, avec cet include ? style est un élement qui ne peut se trouver que dans <head> Un style directement contenu dans <body> ne peut passer que par l'attribut style="...", jamais par un élément <style> -
L'erreur est que le validateur ne te dit pas qu'il n'y a pas d'attribut height dans ton code : il te dit qu'il n'y en a pas dans la DTD retenue pour ta page, autrement dit que cet attribut est invalide et doit être supprimé de ton code <edit>fredwat est passé avant moi</edit>
-
A noter : encore faut-il que le serveur soit configuré pour accompagner les fichiers .xhtml du type mime correspondant. Bravo pour l'intervention pédagogique, Anubis : j'étais trop pressé ce matin
-
page d'aide à la navigation clavier
LaurentDenis a répondu à clb56 - Forum : Accessibilité et Ergonomie Web
Ce n'est pas tout à fait ça. En fait, la quasi-totalité des aides à l'accessibilité ne nécessite aucune page d'aide, car elles sont transparentes pour l'utilisateur, et gérées sans intervention de sa part par le navigateur ou le media d'aide (lecteur d'écran...) : - mise en page CSS sans tableaux imbriqués pour permettre une linéarisation cohérente du document; - contenus alternatifs pour les contenu non textuels (attribut alt des images...) - labellisation des éléments de formulaire - etc. -
Tout ceci n'a pas grand-chose à voir avec le référencement, en fait. Plutôt avec les techniques du Web sémantique encore très peu exploitées. Les metadonnées Dublin Core (signalée par le préfixe DC) sont une coquetterie sémantique plus qu'autre-chose, dans la mesure où aucun moteur de recherche classique ne les exploite actuellement (des moteurs internes de sites ou d'intranet s'en servent en revanche). Le Dublin Core est un standard externe au W3C. Voir Métadonnées et Dublin Core pour une bonne introduction à leur sujet. Les liens relatifs (<link rel="start, index, glossary, help, search...) eux, sont en revanche exploités par certains navigateurs (Opera, FireFox, Lynx...) mais pas par IE. Ils permettent au navigateur de générer une barre de menu associée à la page. A leur sujet, voir simplement la spécification HTML4.01 : http://www.w3.org/TR/html401/types.html#h-6.12 Il semble qu'ils soient suivis par les moteurs de recherche courants. D'autres liens permettent d'indiquer la source des feeds RSS du site : <link rel="alternate" type="application/rss+xml" title="RSS" href="..." /> <link rel="alternate" type="application/xml" title="Atom" href="..." /> Ils sont utilisés par les lecteurs de fils RSS à qui il suffit alors de donner l'url du site pour qu'ils trouvent eux-mêmes l'url du fil... Tu trouveras également parfois une meta du type : <meta name="icbm" content="46.7229, 3.6848" /> Qui indique la localisation géographique du site. Elle est exploitée par exemple par GeoUrl (le site est indisponible actuellement) pour mettre en relation des sites d'origine géographique proche. Pour l'aspect normatif, le standard est le WGS84 (World Geodetic System). Voir GeoInfo (en anglais) à ce sujet. Un lien du type <link rel="meta" type="application/rdf+xml" title="FOAF" href="..." /> ...indique la présence du document "Friend Of A Friend" de l'auteur, c'est à dire un document RDF définissant sa sociabilité virtuelle (Je suis "X", je connais "Y" et "Z"). Pour son exploitation, voir FOAF Explorer et les autres ressources citées dans Websemantique.org (FOAF) (où tu trouveras également le lien vers la norme FOAF)
-
Ce qui te trompe, c'est que la plupart des sites en XHTML le servent en fait uniquement comme du HTML, c'est à dire avec le type mime text/html. Ceux qui le servent en tant qu'application/xhtml+xml utilisent un script de détermination des capacités du navigateur pour adresser à IE (et à d'autres) du text/html. IE n'a alors aucun problème : - puisqu'il s'agit d'un type de document qu'il connait (text/html), - et que le balisage spécifique du XHTML est alors assimilé à de la soupe de tag qu'il sait corriger. Au passage, IE ne permet pas de voir immédiatement quel est le type mime d'un document. Il faut pour cela utiliser un navigateur comme Opera, FireFox, etc. Enfin, un site en XHTML n'a en fait guère d'avantage particulier pour l'utilisateur. Tout au plus peut-on dire que les pages sont le plus souvent plus légères et donc plus rapides à télécharger. Au-delà, cela dépend du respect de divers facteurs de qualité par l'auteur: - accessibilité, - ergonomie, - utilisation appropriée des CSS - utilisation rigoureuse de la sémantique HTML En fait, XHTML est surtout profitable actuellement aux auteurs: - syntaxe plus ferme diminuant le risque d'erreur - exploitation des sources en tant que XML Voir par exemple D'ailleur pourriez vous me dire les avantages du XHTML ? pour un article volontairement sceptique sur le sujet, dont les commentaires apportent un éclairage plus optimiste
-
Si les utilisateurs peuvent le désactiver... Je veux bien faire un effort. Mais je vais te faire un aveu: personnellement, je navigue avec javascript désactivé...
-
page d'aide à la navigation clavier
LaurentDenis a répondu à clb56 - Forum : Accessibilité et Ergonomie Web
La question des accesskeys est en effet loin d'être simple. Et ce n'est pas pour rien qu'ils sont appelés à changer totalement de fonctionnement dans le futur XHTML2.0 Que tous les accesskeys-caractères sont à éviter. - Alt+V par exemple correspond à l'item "View" de nombreux menus... - Alt+W ... "Window" - Alt+Y est utilisé dans une version de Jaws. - sans compter les imprévisibles applications de confort ou d'accessibilité installées par de nombreux utilisateurs, du type loupes, bureaux étendus... Même les accesskeys numériques, qui ont été choisis comme solution après des tests particulièrement étendus, posent des problèmes : je me souviens de quelqu'un qui était furieux parce qu'ils désactivaient son gestionnaire de bureaux virtuels dans je ne sais plus quel linux Je te renvoie à l'article cité ci-dessus (Accesskey, l'essai non transformé de l'accessibilité, en français), ainsi qu'à la série d'excellents articles réalisés par le WATS.ca ( Web Accessibility Testing and Services) : - Accesskeys and Reserved Keystroke Combinations pour une liste des conflits entre accesskeys et raccourcis de navigateur, de lecteurs d'écran, etc. - More reasons why we don't use accesskeys Voir http://www.opera.com/support/tutorials/nomouse/ ou plus directement installer Opera et consulter les pages d'aides En soi, l'idée est justifiée. Mais une page d'aide vise en particulier des utilisateurs pour qui un contenu long et complexe sera plus difficilement appréhendable. Voir par exemples les remarques d'un internaute aveugle, lui-même formateur Web : http://www.temesis.com/article/questionbf_fr.html Un article distinct de la page d'aide serait plus approprié. -
Le menu déroulant est un bon exemple des règles d'une bonne utilisation du java script: - Pour ElMoustiko, le menu déroulant est un "plus" ergonomique qu'il s'empresse d'imposer à ses visiteurs avec sa propre vision de l'ergonomie ( j'exagère, ElMoustiko, j'exagère ! ) - Pour d'autres utilisateurs, ce sera au contraire un "moins", voire un obstacle à la navigation. Pour moi, c'est un moins car il ne permet pas d'avoir une image immédiate et complète de la structure du site reflétée par son menu. Pour un utilisateur handicapé moteur, il a vite fait se se transformer en exercice de voltige cauchemardesque Dans ce cas, si le script et le menu ont été correctement conçus, on peut en effet s'abriter derrière l'idée que le menu se retrouve à plat une fois javascript désactivé. Finalement, javascript peut effectivement être bien utilisé. Mais il faut encore que la fonctionnalité visée soit elle-même une bonne idée D'où trois questions à se poser systématiquement avant de se mettre à coder: - l'idée que javascript me permet de réaliser est-elle vraiment bonne ? - puis-je le faire sans l'imposer à mes visiteurs ? - puis-je le faire sans que ce soit obstructif, c'est à dire que l'accès au contenu et à la navigation en dépendent ?
-
page d'aide à la navigation clavier
LaurentDenis a répondu à clb56 - Forum : Accessibilité et Ergonomie Web
Une bonne idée sur le principe, mais beaucoup plus difficile qu'on ne l'imagine à mettre en oeuvre. En effet, les types de clavier nationaux et surtout les combinaisons de touches d'accès propres à chaque navigateur/OS créent en fait un très grand nombre de configurations utilisateurs possibles. Or ce que tu décris ne correspond guère qu'à une partie des navigateurs sous Windows. Pour te donner un exemple de cette diversité, l'accès au accesskey se fait avec: (Voir http://www.openweb.eu.org/articles/accessk...non_transforme/ à ce sujet et pour ce qui suit.) Il faudrait donc: - soit tenter d'être exhaustif... ce qui est illusoire (mises à jours régulières à prévoir, en supposant qu'on parvienne à se tenir au courant de chaque nouveauté)... - soit laisser l'utilisateur prendre ses responsabilités, et se contenter d'indiquer les accesskeys, sans les combinaisons Alt+ etc qu'il est supposé connaître sur son propre navigateur. Une très brève explication peut suivre sur le principe des accesskeys pour les utilisateurs qui n'en connaissent pas le principe. D'autre part, tes choix d'accesskeys ne seront accessibles que dans certaines configurations, ou même désactiveront des racourcis claviers indispensables sur diverses configurations (voir l'article cité ci-dessus) : ta combinaison Alt + d neutralise par exemple l'accès à la barre d'adresse du navigateur dans IE; la combinaison Alt+a neutralise l'accès au menu affichage. Il en sera de même pour les utilisateurs de JAWS, tandis que ces accesskeys ne fonctionneront au contraire plus dans IBM Home Page Reader... Quoiqu'il n'y ait pas de solution parfaite dans ce domaine, le meilleur compromis à ce jour est de se limiter à un tout petit nombre d'accesskeys numériques réservés aux fonctionnalités-clés. Voici ceux communément retenus: Enfin, les meilleurs pages d'aide à l'accessibilité sont en général... les plus concises. L'utilisateur de racourcis clavier cherchera avant tout un aide-mémoire limité à une simple liste d'accesskeys. Le non-utilisateur curieux peut être invité à lire un article distinct sur le sujet. -
Sauf erreur de ma part : <div class="flash"> <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0" width="550" height="127"> <param name="movie" value="images.swf"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <!--[if !IE]> <--> <object data="images.swf" width="550" height="127" type="application/x-shockwave-flash"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <param name="pluginurl" value="http://www.macromedia.com/go/getflashplayer"> Ici un contenu alternatif </object> <!--> <![endif]--> </object> </div> (Technique de Yan Hixon)
-
Pas remplacé, en fait : - si l'on diffuse du XHTML en tant que HTML (comme c'est le plus ouvent le cas), il faut doubler l'attribut name par un attribut id de même valeur pour respecter les règles de compatibilité théoriques. - si l'on diffuse du XJTML en tant que XML (ce qu'on a très rarement besoin de faire), l'attribut name disparaît au profit de l'attribut id. Pour l'instant donc, restons en HTML qui convient à la plupart des besoins, et contentons-nous de "name", ou passons en XHTML et dupliquons name et id dans l'idée que cela servira par la suite.
-
Je dirais "guide-gites" point "peu importe", mais préférence "com" qui est le plus connu. Le "des" n'apporte rien, sauf à devoir atteindre un NDD non encore pris.
-
Tiens, si jamais quelqu'un se posait la question : Opera PC et Mac supporte SVG via le plugin Adobe SVG viewer. Pour installer ce dernier, voir http://www.opera.com/support/search/supsearch.dml?index=466
-
Sauf erreur de ma part, Jaws a quelques difficultés avec l'attribut lang. Quelqu'un pour infirmer/confirmer ? IBM Home Page Reader et Windows Eyes ignorent quand à eux les éléments <abbr> et <acronym>, et leurs attributs avec. IBM HPR utilise son propre système linguistique d'identification des abréviations uniquement à partir du contenu. Opera 6.0 multimodal fait de même à la suite d'IBM HPR dont le moteur vocal lui sert de base. Qu'en tirer ? Que ce <span lang=""> est d'une portée très limitée, et qu'il vaut mieux coder simplement <abbr lang="..." ...> Sinon, il n'existe aucun moyen de spécifier que la langue d'un attribut est différente de celle de l'élément concerné, ce qui pose effectivement quelques problèmes dans l'absolu: <html lang="fr"> ... <q cite="Tim Berner-Lee, Cool URL don't change"> ... traduction en français de la citation originale ... </q> Au passage, on ne peut pas signaler non plus la présence d'une abréviation dans un attribut... Heureusement, d'ailleurs
-
Ah... Voilà des choses dont il aurait été passionnant de discuter ici ! Bonne chance, tout de même
-
Ce qui nous amène à une petite question : comment l'accessibilité / l'ergonomie doivent-elle tenir compte de ce que sait/ne sait pas/n'est pa supposé savoir/devrait savoir l'utilisateur ? L'ergonomie doit-elle prendre totalement l'utilisateur en charge, y compris dans son ignorance ? (je ne sais pas gérer les fenêtres/onglets dans mon navigateur ; je ne sais pas choisir mon navigateur selon ses capacités ; etc) Il y a derrière le target=_blanck un certain a priori sur l"utilisateur, ce qu'il sait et surtout ce qu'il doit/ne doit pas savoir et que le webmestre sait... bref, sur l'inégalité du savoir-faire et de l'accès au savoir-faire. Vouloir maintenir l'utilisateur sur son site à l'aide de ce type de procédé, c'est souhaiter finalement le tenir beaucoup plus profondément captif que cela : captif de son ignorance. Et maintenir l'auteur dans une situation privilégiée de ce rapport de force de la compétence et de la maîtrise de l'outil (le navigateur). Pas beau, ça
-
Le truc curieux, c'est l'application du "modèle de boîte" (box model, voir http://openweb.eu.org/articles/dimensions_boites_css/ , quoique l'article ait un peu vieilli) La largeur utile pour le rendu affiché de tes éléments n'est pas la largeur spécifiée : c'est la somme width+padding+border (les marges ne sont pas prises en compte ici). Regarde le calcul de tes largeurs: - colonne gauche: 200px + 2px de bordure gauche + 2px de bordure droite : 204 pixels en tout. - idem pour la colonne droite Ta div centre doit donc avoir des marges latérales de 204px et non de 200px. Second problème : les valeurs par défaut imposées par les navigateurs. L'élément <body> a des marges et/ou un padding par défaut variable selon les navigateurs. Il est toujours plus aisé de les annuler systématiquement, ou de les préciser à sa convenance avec un body {margin: 0; padding: 0;}. A noter: ceci s'appliquera par héritage sur une grande partie des autres éléments, puisque body est l'élément qui génère le conteneur initial en HTML (en XHTML, c'est l'élément <html> qui joue ce rôle). Troisième problème : Internet Explorer 5.x Windows a un mode de calcul différent pour le box-model. Et IE6.0 applique dans certains ce mode de calcul "Microsoft" non standard (voir l'article cité ci-dessus). Sans s'étendre sur les détails, le résultat est que la même boîte CSS aura une largeur affiché plus réduite dans IE, d'où un espace inattendu entre tes colonnes dans ce navigateur. Il y a de multiples contournements possibles, dont l'utilisation d'une syntaxe permettant: - de spécifier une première largeur qui ne sera lue que par IE (margin-left: 200px) - de spécifier ensuite une seconde largeur destinée aux autres navigateurs (html>body margin-left: 204px) Le résultat de tout cela donne dans ton exemple de CSS: body { margin: 0; padding: 0; } ... div.centre { margin-left: 200px; margin-right: 200px; height: 300px; border:2px solid blue; background-color: #000099; } html>body div.centre { margin-left: 204px; margin-right: 204px; } Quoique le plus sage soit de prévoir des largeurs laissant "du jeu" entre les <div>, de manière à pouvoir spécifier des valeurs identiques pour tous les navigateurs qui en feront chacun une utilisation à leur portée, sans pour autant casser la mise en page. Bienvenu au monde merveilleux de l'implémentation CSS, des bugs de navigateurs et des tristes hacks parfois nécessaires Heureusement, le salut est dans le Tao