LaurentDenis
-
Compteur de contenus
1 281 -
Inscrit(e) le
-
Dernière visite
Tout ce qui a été posté par LaurentDenis
-
Arf ! j'aurais dû préciser que: - comme je passe pas mal de temps à tester des navigateurs et leur support (X)HTML-CSS... j'utilise aussi bien FireFox, Mozilla... tout comme les différents IEWin successifs, les Opera successifs... sur ma machine - je teste régulièrement les extensions Firefox (dont QuickNote) qui peuvent correspondent à mes besoins. QuickNote correspond à une partie des fonctionnalités des notes Opera. Bref, il est fort possible qu'un jour FireFox ou un futur IE correspondent mieux à mes besoins, auquel cas je l'adopterai sans état d'âme comme navigateur principal Pour les styles utilisateurs, il ne s'agit pas de personnaliser l'affichage des pages, mais d'appliquer rapidement des tests révélateurs sur des pages, pour : - vérifier la présence, l'imbrication, la validité de la syntaxe, les attributs requis pour l'accessibilité... de différents éléments (tableau, object, images, formulaires...) - plus généralement, révéler la manière dont la page est codée, avant d'en afficher le code si nécessaire. Par exemple, une CSS user peut forcer l'affichage de tout le contenu de <head>... Bien-sûr, on peut faire tout ça avec des extensions Firefox, des applications en ligne, etc. Mais l'un et l'autre se complètent pour le plus grand bonheur de tout le monde Tiens, un exemple de CSS sur le <head>: affichez ce pseudo-blog dans son style alternatif. Attention, il n'y a pas de style switcher, et c'est juste un exercice de style un peu extrême à ne surtout pas recommander comme façon de bien faire un site
-
Visualisation du site sur tous les écrans
LaurentDenis a répondu à sophie_dev - Forum : Le salon de Webmaster Hub
Créer un design "figé" pour une résolution d'écran donnée est effectivement très risqué, car rien ne te permet d'être sûr qu'il passera dans toutes les configurations utilisateurs (il est impossible de toutes les tester). Cela dit, il est difficile de t'aider précisément sans avoir le code de la page incrimée: fais un copié collé, ou mieux, donne une url. -
On va tâcher de ne pas trop faire dévier ce fil, et surtout de ne pas donner matière à troller, mais la correction orthographique est un bon exemple des égales qualités de ces deux navigateurs et des raisons de choisir relatives aux besoins de chaque utilisateur. La correction orthographique est disponible dans les deux navigateurs: je l'utilise depuis la sortie d'Opera 7.5 dans celui-ci, et je viens de tester spellbound qui marche à merveille dans Firefox Les deux navigateurs sont donc également innovants pour cette fonctionnalité, contrairement à IE. Comme je rédige beaucoup plus en ligne qu'hors ligne, c'est une de mes raisons de préférer Opera ou FireFox à IE. Mais Opera couple la correction orthographique avec son système de "Notes", ce que n'offre pas Firefox. Ces notes permettent d'étendre l'utilisation du correcteur au-delà des simples zones de saisie de texte dans les pages Web. Avec les notes, je peux corriger à peu près n'importe quel document Web ou non, sans recourir à une autre application. Enfin elles ont beaucoup d'autres utilisations qui correspondent à mes besoins personnels. De la même manière, seul Opera offre certaines fonctionnalités pour les CSS utilisateurs dont je suis un grand consommateur. Et à l'inverse, il y a des cas où Opera se révèle moins pratique que d'autres navigateurs. Dans mon cas, cela concerne surtout ce qui n'est pas le navigateur proprement dit (client mail, lecteur RSS pour lequel une application spécifique est plus puissante). Au bout du compte, Opera m'offre un éventail de bonnes et de moins bonnes réponses à mes besoins personnels. Dans mon cas, les bonnes l'emportent, mais pour quelqu'un d'autre qui fait un usage différent de son navigateur, la balance penchera de l'autre côté. Conclusion : il n'y a pas et il ne peut pas y avoir un navigateur meilleur que les autres dans l'absolu. Il n'y a que des navigateurs qui : - ont effectivement des qualités et des défauts dans l'absolu (IE n'innove plus). - mais dont les qualités propres correspondent plus ou moins aux besoins relatifs de tel ou tel utilisateur (FireFox et Opera). C'est un peu long pour une parenthèse dans ce thread, désolé Mais surtout, que cela ne t'empêche pas de descendre chez moi dès que tu peux, avec ou sans le vin
-
Cleden : merci de rappeler systématiquement l'url de la page sur laquelle tu souhaites avoir de l'aide, dans le corps de ton message. Devoir aller chercher cet url dans ton profil n'encourage pas à te venir en aide.
-
Le mérite revient en fait à Cédric Malherbe qui l'a signalé en juin dernier sur la liste de l'AFUL.
-
Heu..... En lisant le message de dev67, j'avais plutôt compris qu'il voulait faire un encart dans sa page avec un ascenseur, bref un <iframe>, en fait. Et puis, en lisant ton premier message, j'avais compris que tu avais compris qu'il voulait faire un encart avec un texte qui défilait automatiquement (c'est ce que fait le script que tu lui indiques, non ?) D'où ma réponse pour dire que le défilement automatique, c'est plutôt du côté du navigateur, d'un certain point de vue (mais bien-sûr, on peut aussi le faire en Flash, à défaut de pouvoir utiliser SVG) Mais j'avais mal lu, et tu parlais effectivement de défilement automatique à l'horizontal, désolé Bref, dans ce cas, je ne sais pas si c'est adapté au contenu de dev67, mais un simple pre { overflow: auto; } peut suffire si le contenu en question se trouve dans un <pre> et que la largeur de celui-ci est déterminée directement par width: ou limité par la largeur de son conteneur.
-
Aide à l'amélioration d'un webmaster
LaurentDenis a répondu à Sans Esprit - Forum : Hébergement de Sites
Il serait préférable de garder séparées les questions sur: - le contenu du site, plutôt visée par ton autre fil Centralisation des cours, Un peu d'aide !!! (je viens de t'y répondre, d'ailleurs) - les couleurs, le code... ici. A ce propos, une remarque sur la forme : L'arrière plan des pages "Cours gratuit" (petits carrés orange et blancs) rend les pages à peu près illisibles. -
Sur le fond, quelques suggestions d'amélioration des cours HTML-CSS: Html : structure d'une page html: Quand on débute en HTML, il est très important de prendre tout de suite de bonnes habitudes pour les choses essentielles. La structure minimale d'une page Web doit commencer par une Déclaration de Type de Document (DTD) qui indique au navigateur quel dialecte HTML précis est utilisé dans la page, afin que celle-ci puisse être interprétée sans malentendus ni erreur. La DTD la plus recommandable à ce niveau est la plus souple, donc DTD html transitional : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title> TITRE DE LA PAGE </title> </head> <body> CORPS DE LA PAGE </body> </html> Html : Comment formater un texte: -faire deux tableaux pour différencier les éléments HTML de présentation (déconseillés et supprimés dans les normes les plus récentes) et les éléments HTML de structuration de texte (valides dans toutes les normes). Pour cela, voir simplement l'index des éléments HTML dans la norme HTML4.01. Les éléments de présentation sont marqués d'un D dans la colonne "Déconseillé". A propos des éléments de présentation, indiquer qu'ils doivent être remplacé par les styles CSS. -La balise <BLINK> est invalide dans tous les cas. -<DFN> n'introduit pas une définition: il balise le terme défini. (ex: "une <dfn>balise</dfn>, c'est ....") -Les listes </OL> ne sont pas triées mais ordonnées, c'est à dire qu'un numéro est ajouté à l'affichage. -<strong> ne fait pas du gras, mais ajoute une emphase. Ajouter aussi <em> qui joue le même rôle. -Supprimer le saut de ligne dans l'un des attributs HTML de l'exemple "Mon texte doit sortir en taille 3...": le code invalide ne fonctionne pas dans les navigateurs moins tolérants qu'IE et l'exemple n'a pas la présentation voulue. Html: liens et images: -<IMG SRC="image"> est faux. L'attribut ALT indiquant un éventuel texte de remplacement de l'image est obligatoire dans tous les cas. Donc <IMG SRC="image" ALT="Brève Description"> ou <IMG SRC="image" ALT="">. Voir Des images accessibles Langage Css : feuille de style: -"On parle aussi de feuilles de style en cascade [ Cascading Style Sheets ou CSS ] car en cas de styles identiques, un ordre de priorité sera déterminé par le browser.". Pas vraiment : La cascade signifie d'une part qu'une feuille de style peut en appeler une autre, qui peut elle-même en appeler un troisième, etc... et d'autre part que le document se voit appliquer simultanément 3 feuilles de style au minimum (celle de la page, celle de l'utilisateur, celle par défaut du navigateur). Le calcul de l'ordre de priorité est une conséquence de la cascade. -"Permettre le positionnement au pixel près du texte et/ou des images". La "philosophie" des CSS est plutôt de donner de la fuidité à la page, d'éviter le positionnement au px près, pour garantir une meilleure adaptation à toutes les conditions de rendu qui sont imprévisibles pour le concepteur. -"Les propriétés de style sont entourées par des "{" et par des [ ou des parenthèses." Des { seulement. crochets et parenthèses ont un tout autre rôle. -"La seul contrainte est que le fichier doit avoir une extension .css ( exemple.css )." Non. "css" n'est que l'extension usuelle et recommandée. Mais on peut tout à fait faire des CSS.php ou des CSS.asp, par exemple, pour y inclure des scripts serveurs. -"Une feuille intra-ligne s'insère directement à côté de la balise qu'elle définit" : dans ce cas, ce n'est pas une "feuille de style", mais un "style en ligne". Css : Index: -font-size : l'unité em a été oubliée. C'est en fait l'une des unités les plus utilisées en CSS (voir Comment définir la taille du texte en ems (traduction) -color : Corriger "En hexadécimal ou lettre ff0000" : la couleur "red" s'écrit #ff0000 en hexadécimal. Il n'y a pas de "lettre ff0000". -line-height : ne définit pas l'espace entre les lignes, mais la hauteur minimale d'une ligne.
-
Désolé si cela resemble à une façon agaçante de contourner la question, mais aujourd'hui... différents OS ont nativement une fonction de défilement automatique. Par exemple, un clic du bouton central de ma souris fait défiler les pages du Hub de haut en bas et inversement dans n'importe quel navigateur graphique (sous Windows XP). J'ai donc un peu de mal à comprendre l'intérêt de refaire au niveau du document ou de l'application Web quelque-chose... que l'agent utilisateur fait déjà très bien tout seul ???
-
Mon ministre (Education Nationale)... je ne sais pas Mais ses lointains subordonnés locaux qui décide plus concrètement en ce qui me concerne... oui ! Ils obligent à remplacer : - Word (MS) par OpenOffice (libre) - mais aussi Thunderbird (libre) par Outlook (MS) - et les navigateurs alternatifs sont priés de décamper au profit d'IE (MS) Une logique un peu... surprenante, non ? Finalement... j'ai viré le PC fourni officiellement et j'utilise mon portable personnel qui échappe à cette réglementation
-
Il me semble que tu mélanges deux choses : - le paramétrage du lecteur de feeds RSS (suppression des items après x temps). Celui-ci peut éventuellement exploiter les informations (RSS1.0) de syndication updatePeriod, updateFrequency et updateBase (voir RSS1.0 : module syndication) - le fil lui-même : une news périmée doit être simplement retirée du document RSS... le procédé peut être automatisé par un script utilisant, pour RSS1.0 par exemple, l'élément <dc:date> du Dublin Core (voir Module Dublin Core RSS1 et Métadonnées et Dublin Core
-
Très intéressant, ce tutoriel ! Juste quelques fonctionnalités de détails à vérifier car peut-être mal supportées ici ou là, comme optgroup et l'aide contextuelle avec les title ? L'auteur propose d'ailleurs d'autres ressources tout aussi intéressantes... Merci pour le lien
-
Pour une meilleure visibilité ...
LaurentDenis a répondu à Wanbli - Forum : Techniques de Référencement
Je ne suis pas sûr de comprendre : pourquoi déplacer côté serveur ce que le navigateur, les robots... font nativement ? -
Hum... Si tu souhaites aller plus loin, il faut regarder un peu le code des pages à présent. Comme documentation, je te recommande Ecrire une page Web, fait par les élèves de l'ENS, qui donne toutes les bases dans un langage... humain Il semble que tu aies beaucoup procédé par copié-collé de pages ou de bribes de codes que tu as pris en exemple. C'est une très bonne façon de commencer, mais il faudrait y mettre un petit peu d'ordre. En l'état, ta page d'accueil (par exemple) comporte 3 sections <html>...</html>, 3 sections <body>...</body> et 4 sections <head>...</head>, ce qui est un peu trop En effet, abondance de biens ne nuit pas, mais... une page HTML ne peut comporter qu'une section <html>...</html> unique, et dans celle-ci : - une section <head>...</head> unique pour des informations non directement affichées par le navigateur dans la fenêtre, mais nécessaires à la bonne restitution de la page, - une section <body>...</body> unique pour ce qui sera affiché. Donc typiquement : <html> <head> ici pleins de lignes de code </head> <body> ici pleins de lignes de code </body> </html> Avant d'aborder des choses commes XHTML, CSS et autres, l'étape suivante me semble donc de déplacer un peu les bouts épars et d'éliminer les morceaux inutiles. Tes pages y gagneront à nouveau en poids, et tu pourras aborder le code avec quelque-chose de lisible (pour l'instant, tu aurais beaucoup de mal à t'y retrouver). Pour t'aider, voici à quoi devrait ressembler le résultat dans un premie temps: <html> <head> -ici un seul <title>CooloWeb.net : Le site généraliste de l'internaute et du webmaster classé en 8 thèmes</title> -ici plein de <meta... -ici un seul <style>...</style> -ici plein de <script>...</script> </head> <body background="... -ici plein de lignes de code </body> </html>
-
Voir à nouveau chez les pompeurs : Techniques et astuces pratiques pour une mise en page CSS
-
Depuis la version 7.5x d'Opera, on peut le coupler à un correcteur orthographique (Aspell, nombreuses langues couvertes, OpenSource...) Il permet de vérifier en particulier le contenu des contrôles de formulaires (textarea, donc intéressant dans les applications de saisie de contenu en ligne...) et les "Notes" du navigateur (Et on peut envoyer d'un clic dans une note le contenu d'une page affichée)... J'imagine qu'un magicien du code devrait pouvoir réaliser la même fonction pour les navigateurs Geckos
-
Plutôt que les tableaux en eux-mêmes, c'est la manière de s'en servir qui est dangereuse, ici. On peut être accessible en utilisant des tableaux sans imbrication pour des formulaires simples. Le principal risque est que les <label> des contrôles soient dissociés de ceux-ci lorsque le tableau est linéarisé (rendu dans l'ordre brut des éléments HTML). Par exemple, le tableau suivant, qui place les <label> au dessus des contrôles: <table> <tr> <td>label 1</td> <td>label 2</td> </tr> <tr> <td>contrôle 1</td> <td>contrôle 2</td> </tr> </table> ... donnera un résultat aberrant une fois linéarisé : label1 label2 contrôle 1 contröle 2 En revanche : <table> <tr> <td>label 1</td> <td>contrôle 1</td> </tr> <tr> <td>label 2</td> <td>contrôle 2</td> </tr> </table> se linéarise correctement... label 1 contrôle 1 label 2 contrôle 2 Mais il existe de nombreuses solutions CSS. Tu peux par exemple utiliser une liste de définition (très à la mode ) sur le principe : <dl> <dt>label 1</dt> <dd>contrôle 1</dd> <dt>label 2</dt> <dd>contrôle 2</dd> etc. </dl> avec en CSS un float:left sur les <dt>...
-
Pour enfoncer un peu le clou après le message de Denis : Le rôle d'OpenWeb n'est pas de définir des normes, pas plus que ce n'est le rôle d'Opquast, d'AccessiWeb, de tel ou tel groupe d'experts, ou de Monsieur X. Les normes et les standards ne peuvent être définies qu'au sein d'organismes tels que le W3C, l'IETF, l'ISO... Lorsqu'une norme existe, OpenWeb la présente et l'explique au mieux afin d'en faciliter l'utilisation. Mais lorsqu'il n'y a pas de norme, on ne peut que diffuser des éléments de réflexion ou des propositions de bonnes pratiques. Dans tous les cas, c'est à chacun de faire ses propres choix techniques. C'est la seule ambition de l'article que j'ai écris pour OpenWeb sur les accesskeys : dresser un état des lieux, faire la synthèse d'avis compétents et en tirer une suggestion de solutions. (Au passage, ce ne sont pas les solutions que j'aurais retenues à titre personnel.)
-
Pour le pied de page : le bon résultat obtenu dans IE est en fait accidentel (et la preuve qu'il ne faut pas développer sa CSS en prenant IE comme navigateur de référence) : - tu utilises une propriété position:fixed qui n'est pas supportée par IE. Il l'ignore donc, et il laisse la div #pied se placer "en flux", c'est à dire tout simplement en desous du contenu qui la précède. - FireFox et Opera savent faire du position:fixed. Ils font donc ce que tu leur demandes, et placent ta div #pied par-dessus tout autre contenu, à 0pixels du bas de la fenêtre du navigateur, et l'y maintiennent en permanence indépendamment du scroll. Solution : essaie déjà d'enlever ce position: fixed et les règles left et bottom qui vont avec. Ta div se placera en flux, ce qui suffira peut-être (je n'ai pas testé ni regardé la CSS en détail). D'une manière générale, "moins on positionne, mieux on se porte" : le flux est là pour gérer à ta place un positionnement vertical simple. Ne positionner que quand on cherche quelque-chose de plus évolué.
-
Le doctype peut il changer la mise en page ?
LaurentDenis a répondu à desx - Forum : Accessibilité et Ergonomie Web
Vérifie si ce n'est pas un problème de "DocType Switching" : en fonction du DocType spécifié dans le document, le navigateur adoptera l'un ou l'autre mode de rendu graphique: - mode "Standard" (tel que défini par les spécifications du W3C) - mode "Quirks" (tel que défini par le comportement propriétaire d'IE5) - mode "Almost Standards" pour les navigateurs Mozilla uniquement, intermédiaire entre les deux précédents. Selon le mode de rendu graphique, le comportement des tableaux et le calcul des dimensions des boîtes CSS est différent (entre autres). Voir à ce sulet http://www.ericmeyeroncss.com/bonus/render-mode.html Si tu veux creuser la question et vérifier, consulte les tableaux de DocType Switching des différents navigateurs. Tu trouveras ici : http://www.opera.com/docs/specs/doctype/ le tableau pour Opera, et des liens vers les pages équivalentes pour Mozilla et IE [edit] J'oubliais: même si le code est validable strict, il n'y a aucun inconvénient à le servir en transitionnel. -
Flash est effectivement une technique excellente et à recommander, à la réflexion. Elle ne pose aucun problème d'accessibilité ou d'interopérabilité... (Ne vous étouffez pas, Denis et Monique : lisez la suite) ... aucun problème dès lors que le contenu est fourni par ailleurs en bon HTML bien dur, à titre alternatif, conformément aux spécifications D'accord, ça fait double emploi, double coût, etc. Mais c'est le revers de la médaille plugin.
-
Il te manque la puce, en effet : une règle "marker-offset" sur les <a> pour l'obtenir. Mais son support est très limité, et évidemment inexistant dans IE. http://www.yoyodesign.org/doc/w3c/css2/gen...f-marker-offset
-
Monique, on ne peut pas simplifier. Les situations concrètes posent des problèmes trop variés. Rapidement : Si mon menu n'a que 3 ou 4 items, et qu'il s'agit bien des liens essentiels du site (accueil, recherche, accessibilité, mail), alors, c'est sans doute une bonne idée de le placer avant le contenu, disons au moins en page d'accueil. Mais si mon menu comporte 15 ou 20 liens... l'usage du lien "skip navigation" va devenir systématique pour la quasi-totalité des visiteurs concernés, il me semble (Laissons de côté les accesskeys, trop peu fiables : c'est un plus, pas un mécanisme de base). Dans ce cas, pourquoi le mettre en début de page ? Il devient une nuisance. Il faudrait encore différencier page d'accueil, carte, et autre pages d'un site. Quand un menu comporte tellement d'items qu'il en devient encombrant... la structure est à revoir: ce n'est plus un menu, c'est une page de table des matières à part entière qu'il s'agit de faire. Du point de vue structurel, d'autre part, un document HTML étant linéaire, il semble beaucoup plus logique de placer les liens en fin de document, comme des notes en bas de page. Concrètement ? Un compromis, quand le menu comporte plus de 3 ou 4 liens : - Placer en tête de page, pour l'accessibilité, les liens essentiels du "menu d'accessibilité" qui comporte lui même un lien vers : - un second menu, en fin de contenu, qui comporte les autres liens.
-
Il ne faut surtout pas cacher le lien, ni avec "display: none", ni avec "visibility:hidden" : des défauts d'implémentation de CSS dans la quasi totalité des lecteurs d'écran font que le lien n'y apparaîtra pas. On aboutit donc à l'inverse du gain d'accessibilité escompté ! Si on tient absolument à masquer ce lien, utiliser plutôt la solution CSS de Paul Bohman, qui ne semble pas poser de problèmes d'accessibilité: http://www.blog-and-blues.org/weblog/2004/...ne-saurais-voir Mieux : ne pas cacher le lien, qui a effectivement son utilité pour tout le monde, en fait, y compris dans les navigateurs graphiques
-
changer la couleur d'un <input disabled ?
LaurentDenis a répondu à Anonymus - Forum : (X)HTML et CSS
ça me semble mal parti : on dirait bien le cas d'une de ces règles de présentation de formulaire qui "ne sont pas exprimables en CSS", comme dit la spécification http://www.yoyodesign.org/doc/w3c/css2/sample.html De fait, ni color ni text-shadow n'ont le moindre effet...