LaurentDenis
-
Compteur de contenus
1 281 -
Inscrit(e) le
-
Dernière visite
Tout ce qui a été posté par LaurentDenis
-
changer la couleur d'un <input disabled ?
LaurentDenis a répondu à Anonymus - Forum : (X)HTML et CSS
Vite fait, avec le code suivant, les IE 5 à 6 me donnent bien la couleur d'arrière-plan de l'input... <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <meta http-equiv="Content-style-type" content="text/css" /> <title>Test</title> <style> input { background-color: #ff0000; } </style> </head> <body> <div> <input disabled="disabled" type="text"> </div> </body> </html> -
HTML versus XHTML : deux langages, avec quelles difficultés d'apprentissages ? - vocabulaire : moins de balises et d'attributs en XHTML strict qu'en HTML transitionnel... Donc, moins de risques d'erreur. - orthographiques : le XHTML exige le zéro faute à la dictée, mais ses règles orthographiques sont simplissimes. Deux-trois règles de minuscules, de signe de fermeture de balise... - grammaticales : quelques exigences supplémentaires sur les enchâssements de balises, tout au plus. Pour tout dire : cela fait un bon bout de temps que j'écris au fil de la plume en XHTML strict, en risquant tout au plus une erreur de validation évidente pour une faute de typo. Et je prends plus de risque avec l'orthographe de la langue qu'avec celle du langage de structuration
-
Bravo pour ces félicitations du jury !
-
Cet attribut src permettrait de mieux gérer le problème des contenus alternatifs. Par exemple, pour l'instant, le contenu alternatif d'une image complexe doit se trouver dans un document annexe, auquel renvoie l'attribut longdesc. Même si celui-ci était correctement supporté par les navigateurs, il poserait encore de nombreux problèmes de traitement : comment signaler ce lien à l'utilisateur ? Celui-ci doit-il intervenir pour l'activer ou faut-il que le contenu alternatif soit directement affiché ? Où ? Que se passe-t-il si la ressource annexe n'est pas disponible ? Etc. Le nouvel attribut scr permet de simplifier considérablement, en inversant la situation : l'équivalent XHTML de l'image fera partie du document principal, et sera donc immédiatement accessible au navigateur. Le résultat est plus "robuste" dans le sens où si le lien vers l'image (ou toute autre ressource non XHTML) est rompu, le sens du document n'est pas perdu, puisque l'équivalent est toujours là, parfaitement intégré au reste du contenu. Il y a également un gain par rapport à l'utilisation actuelle de alt qui n'autorise qu'un contenu très bref et non structurable. En fait, la notion de contenu alternatif change : c'est l'image qui devient une ressource alternative au contenu du document. Cela semble plus cohérent. Au total, un progrès considérable, AMHA.
-
Un rappel à propos du projet XHTML2, à lire avant de se lancer dans des débats passionnés : XHTML 2.0, le vilain petit canard (Voir aussi XHTML 2.0, toujours...)
-
A un moment donné du développement du site, un éditeur wysiwyg (ou toi-même) a dû générer quelque-part dans le site un tableau doté d'une légende (caption) stylée avec cet incorrect font: qui devrait être en effet un font-size:... Donc : - voir s'il y a quelque-part sur le site un tableau, auquel cas corriger la CSS; - sinon, virer l'ensemble des règles liées à ce caption inutile.
-
Le "coup de sang" d'Olivier est plutôt une invitation à suivre les développements ultérieurs de Spip Agora, qui n'en n'est qu'à ses premiers pas : ne jetez pas le bébé trop vite sous prétexte qu'il a encore du mal à marcher
-
<?xml version="1.0" encoding="UTF-8"?> La source de ta page contient bel et bien des caractères... inattendus Peut-être à voir du côté de la génération de la page, une erreur PHP ?
-
Menus déroulants accessibles?
LaurentDenis a répondu à Sebastien - Forum : Accessibilité et Ergonomie Web
Mesdames et messieurs, permettez-moi de vous présenter (si vous ne le connaissez pas déjà) le spécialiste CSS d'OpenWeb et son designer attitré Dan, il va falloir déposer le domaine openweb-hub Avec les applications Web et les nouveaux langages ou extension de langages actuels qui sont envisagés, les questions d'accessibilité et d'ergonomie vont en effet se multiplier. Quand on lit par exemple le projet d'extension du HTML aux fonctionnalités d'application Web de Yan Hixon et du WHAT Working Group, on voit qu'il y aura beaucoup à faire ! Et il y a de quoi s'inquiéter quand Hixon écrit clairement qu'il s'agit essentiellement pour l'instant de simplifier la vie des développeurs... L'utilisateur y gagnera-t-il autre-chose que de la complexité ? -
Avec le défaut d'avoir à être en ligne sur le site pour utiliser le mail. ça ne pose aucun problème dans le cas d'un forum, c'est beaucoup plus problématique pour un site commercial, professionnel ou même personnel. Puisqu'on parle déjà des questions qui sont au-delà des résultats de ces tests : l'anti-spam me semble plutôt plutôt du ressort du serveur et du client de mail avec les filtres qu'il faut, non ?
-
Bienvenu sur le Hub ! Tu y trouveras déjà un premier avis (amical et amusé) : ne pas faire de page-paillasson-devant-le-seuil-en-flash-qu'y-faut-que-je-clique-encore-pour-entrer, comme http://www.odic-conseil.com/ : pour quelqu'un qui met en avant le "à haut rendement", c'est tout sauf du rendement Web Moi, ça ne m'inspirerait pas confiance, un Trader qui gaspille comme ça le temps de ses clients Après, il y a à faire pour éliminer les frames, en particulier si tu te mets au PHP avec le bénéfice très rapide des include.
-
Argh ! Pas d'adresse e-mail en image, par pitié. On commence à peine un dur combat pour virer le tri entre vrais utilisateurs et robots avec un de ces fichus codes en image à recopier dans un formulaire... N'en rajoutez pas
-
Je suis un peu dans ta situation, puisque si connais bien d'autres langages, il faut avouer que mes notions de PHP ont jusqu'ici été franchement minimales. Ayant résolu de m'y mettre, j'ai opté pour une démarche d'initiation un peu différente : décrypter et modifier selon mes besoins une "bonne" application PHP (rigoureusement codée). Au moins, comme ça, on a un bon point d'appui, sans compter un forum spécialisé sur l'appli en question avec des gens bien au fait du code concerné. Peut-être cela peut te servir de piste.
-
C'est drôle, mais constructif invite immédiatement à une avalanche de remarques polies sur ce qu'on aurait fait autrement que l'auteur, ou ce qui ne va pas du tout, etc Donc, avant de faire constructif : excellente idée ! Un test rigoureux permettrait enfin de faire la part des choses sur quelques fantasmes et légendes probables en matière de protection anti-spam par cryptage de l'adresse. Sans compter les problèmes d'utilisabilité et d'interopérabilité que certains posent. Sinon, pour faire constructif : - tests 6 et 7, avec le javascript désactivé (évidemment ) : plus rien ! Plus d'adresse sous une forme ou sous une autre, ce qui est un peu dur, tout de même. Avec cette méthode, il faut que l'utilisateur dénué de javascript activé puisse tout de même la copier à la main, cette adresse... Mais je suppose qu'il est prévu de le mentionner dans l'article final, bien-sûr. - test 9 : j'obtiens un page d'erreur 404 (Opera 7.50 Win, IE6, FireFox Win... et client mail unique Opera M2) - un test 10 à faire, variante du n°8, pour le principe : remplacer l'arobase par %40. Autant dire tout de suite que ça ne marche pas, vu la tonne de spam que je reçoit quotidiennement
-
Deux remarques rapides sur ce qui me dérange, faute de temps pour parler maintenant de ce qui me plaît beaucoup dans ce renard : - j'ai cru comprendre que l'enregistrement était requis par le mode de fonctionnement du moteur, pour "faire bosser" les utilisateurs afin d'améliorer les résultats pour tout le monde (je raccourcis beaucoup, mais tu me corrigeras si ce n'est pas en très gros le principe). Je ne suis pas contre, loin de là, en tant qu'utilisateur. Mais si c'est bien le cas, j'aimerai bien qu'on me l'explique simplement pour justifier que j'aie à m'enregistrer (avec une politique de confidentialité des données des plus floues). Là, l'enregistrement, ça fait arnaque douteuse plus qu'autre-chose (c'est injuste, d'accord, mais c'est ce que dit le client ) - une recherche sur l'expression "standards web" en français me donne exactement la même page de résultat que la recherche par défaut. J'ai loupé une manoeuvre ? [edit] Si Pourquoi demander : -Prénom, -Nom, -Homepage, -N° ICQ, -Pseudo AIM, -Compte MSN Messenger, (optionnels, d'accord).
-
C'est également dans cet état d'esprit que je me suis permis de reprendre la seule "erreur" de l'excellent travail de MissMonde : la hiérachie des titres, parce qu'elle aura des conséquences bien concrètes pour une partie des visiteurs. En revanche, quand j'ai parlé ensuite du portait, de la liste réduite à un seul élément et de la liste de définition, ce n'était pas pour apporter d'autres critiques, mais pour donner au contraire des exemples de (mauvaises) critiques "puristes" et subjectives. Si mon message était maladroitement formulé (fatigue de fin de semaine aidant), veuillez m'en excuser. (J'ai tout de même un doute de plus en plus sérieux sur la liste de définition réduite aux <dt>... puisque le but de l'élément <dl> est explicitement de faire correspondre des termes à des définitions (au sens large).) Ta page est au contraire tout prêt d'être excellente. Mais il ne faut pas trop en demander au validateur du W3C ! Comme tout validateur, ce n'est qu'une machine aux capacités limitées, qui fait une vérification plutôt formelle : la conformité du code aux règles de syntaxe requises par sa DTD. Une page formellement validée peut très bien être totalement aberrante, si les éléments HTML sont détournés de leur fonction. Exemple : ces pages où on n'utilise que des <div> transformées en pseudo-paragraphes, pseudo-titres... à coup de CSS. Voir Les Précieuses Ridicules (ou Cathos, XHTML et CSS). Tout simplement qu'utiliser une liste pour un seul item me gêne, et que j'y verrais mieux un paragraphe par exemple. Une liste... n'est-ce pas l'idée de plusieurs choses ? Voilà un bon exemple de purisme subjectif, ça : la vieille histoire du à partir de combien de grains de blé a-t-on un tas de grains de blé ? Un ? Deux ? Trois et plus ?. C'est la porte ouverte à tous les coupages de cheveux en quatre. Aucun intérêt ! Donc, concrètement, à chacun de faire comme il sent
-
Mon avis pour ce qu'il vaut J'ai de gros doutes sur la pertinence d'une site comme CssZenGarden. D'un point de vue de CSSiste, c'est un exploit collectif permanent, d'accord (Je serais totalement incapable d'y participer, faut-il le préciser ?) Mais c'est un exploit, justement. L'utilité des CSS n'est pas là. Elle est plutôt, AMHA, dans la mise en page de milliers de sites anonymes ou simplement commerciaux, pour qui la technique nécessitera un investissement initial non négligeable (en formation des développeurs et graphistes), mais au profit à long terme certain (maintenance, bande passante, élargissement de l'audience grâce à l'accessibilité...). Je crois donc qu'un design beaucoup plus "banal" techniquement, mais beaucoup moins théorique, est un argument nettement plus acceptable.
-
Bon, sérieusement cette fois, ne confondons pas purisme et rigueur. Le purisme, c'est dire que: - le portait de BZHcool n'a rien à faire dans la <div id="navigation"> - que l'élément de liste unique de cette div pour l'adresse mail est injustifié - que la liste de définition de la partie Pourquoi cette page? est inacceptable, vu qu'aucun <dt> n'est défini par un <dd> (Pas si puriste que ça, ce dernier point, d'ailleurs)... - etc. La rigueur, c'est de relever une erreur qui a des conséquences très concrètes pour un certain nombre d'utilisateurs du site : une mauvaise hiérarchie des titres: - peut faire échouer des traitements de la source XHTML visant à en extraire les titres pour former un résumé, une table des matières... - fait échouer un procédé d'accessibilité : la navigation dans une page par les titres dans Jaws. Voir Jaws, label, titres, liens et CSS en général (Yoan Simonian me corrigera je l'espère si je me trompe). [edit: j'en rajoute une couche] Source : Le plus récent référentiel d'accessibilité concret à ma connaissance (celui d'AccessiWeb) [/edit] Outre le fait que c'est à peu près aussi logique que : Tout ça pour que ce soit plus joli avec des h3 ?
-
Très bien, sauf pour le <h1>BZHcool.com</h1> suivi d'un <h3>QUI SUIS-JE? </h3> Il manque un petit <h2> quelque-part, non ? Outre la logique structurelle, c'est important pour l'accessibilité (navigation dans le contenu via la hiérarchie des titres) Allez-y... Je les démolirai toutes ! (Je sors, c'est ça ?)
-
Menus déroulants accessibles?
LaurentDenis a répondu à Sebastien - Forum : Accessibilité et Ergonomie Web
Ouïe ! Aïe ! Pan sur le bec ! N'en jetez plus Très franchement, comme je l'ai dit plus haut, je ne suis pas du tout un fana des menus à coulisse. C'est à dire que je ne m'en suis jamais servi personnellement, et que je n'aime guère en rencontrer sur un site. Ajoutons-y le fait que j'étais totalement offline quand cet article a été publié sur OpenWeb... et on arrive à la conclusion : je n'y connais pas grand chose, là, d'où ce renvoi que je croyais prudent à l'article en question Les réserves que tu fais sur le principe même de ces menus me renforcent dans mon antipathie latente à leur égards. Cela dit, à ta première réponse, j'avais cru comprendre que le problème technique de couleurs était simple : il n'en est apparemment rien. Toutes mes excuses, donc. La peste soit des menus à coulisse ! Belle illustration du problème de l'accessibilité "théoriquement standardisée" et de l'accessibilité réelle expérimentée... -
Menus déroulants accessibles?
LaurentDenis a répondu à Sebastien - Forum : Accessibilité et Ergonomie Web
Ah... que ne l'as-tu pas dit plus tôt Je transmets de ce pas à l'auteur de l'article pour que les corrections nécessaires soient faites (a priori, rien de bien difficile) Merci -
Heu, peut-être plutôt Types MIME et MathML 2.0, non ?
-
Menus déroulants accessibles?
LaurentDenis a répondu à Sebastien - Forum : Accessibilité et Ergonomie Web
N'étant pas un fana de la chose, j'en suis resté à Faire un menu dynamique ouvert et accessible qui explique comment faire un menu déroulant avec javascript, mais accessible sans celui-ci. L'accessibilité exige que tout contenu accessible par un script soit également accessible sans celui-ci. C'est effectivement le rôle du <noscript>. -
C'est tellement évident que j'en oubliais de le signaler : Pour les changements à apporter en passant du HTML au XHTML, voir Passer du HTML au XHTML Le Doctype XHTML1.0 strict : <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"> Voir List of valid DTDs you can use in your document sur le site du W3C pour toutes les DTD disponibles. L'espace dans les metas est nécessaire en effet, pour certains vieux navigateurs qui auraient du mal à comprendre le /> Enfin, comme dit plus haut, les navigateurs sont gentils pour l'instant et acceptent de traiter du XHTML1.1 comme si c'était du HTML quand le doctype est incorrect. Mais rien ne dit que ça durera
-
On déborde un peu là, mais rapidement : j'ai toujours supposé que tu servais du XHTML1.0 à IE. je vois que ce n'est pas le cas. Argh !!! Shame on you ! Tu seras damné pour l'éternité... (Sauf si Bleizig modifie ta négociation de contenu pour servir du XHTML1.0 à Internet Explorer. Il te règlera bien ça en deux coups de cuillères à pot, non ? )