Aller au contenu

LaurentDenis

Membres
 Afficher le profil  Parcourir son contenu

  • Compteur de contenus

    1 281

  • Inscrit(e) le

  • Dernière visite

 Type de contenu 

Tout ce qui a été posté par LaurentDenis

  1. LaurentDenis
    Ouh la la... je suis fatigué, moi : Je ne sais plus lire, en effet Oubliez ça
  2. LaurentDenis
    Là, j'ai du mal à te suivre : permettre à l'utilisateur de passer d'une version linguistique à une autre est au contraire nécessaire. Si j'arrive sur la version anglaise (via un moteur, ou un lien dans un autre site, par exemple), je serais heureux de trouver sur la page anglaise un lien vers son équivalent français cela dit, sans doute voulais-tu dire "pas une bonne idée du point de vue référencement" ? Auquel cas... c'est effectivement problématique
  3. LaurentDenis
    Le problème d'encodage ne doit pas être réglé dans le fichier lui-même. Celui était encodé en iso-8859-1 apparemment. Il faut donc d'abord rétablir le <?xml version="1.0" encoding="iso-8859-1"?>. Ensuite, pour résoudre le problème signalé par le validateur, il faut intervenir au niveau serveur, pour modifier l'en-tête HTTP Content-Type qui renvoit actuellement la valeur US-ASCII et qui devra indiquer l'encodage réel du fichier, c'est à dire iso-8859-1. Au plus simple, passer par php et ajouter : header('Content-Type: text/xml; charset=iso-8859-1'); Aïe Aïe Aïe ! Non ! ça n'est pas du tout ça, un encodage ! Le fait qu'un document soit en utf-8 ou en iso-8859-1 ne change rien. Les caractères accentués peuvent aussi bien être: - directement présents : é - présents sous forme d'entités caractères: & eacute; - présents sous forme d'entités numériques: & #233; Ce n'est que lorsque l'on utilise un caractère absent d'un encodage qu'il est nécessaire de passer par l'entité caractère ou numérique, celle-ci étant indépendante de l'encodage. Autrement dit, la lettre grec alpha dans un document en iso-8859-1 doit être encodé & Alpha; ou & #913; Ici, ce n'est absolument pas nécessaire, et tant que nizouille se contentera de mettre des caractères accentués, il peut très bien les écrire littéralement, dans la mesure où son éditeur HTML gère l'iso-8859-1. Il peut aussi les encoder, ce qui ne sert à rien, mais ne pose absolument aucun problème.
  4. LaurentDenis
    L'image peut être placée en position absolue en CSS. Voir Initiation au positionnement CSS : 3. position absolue et fixe Approximativement : en HTML: <div id="logo"><img src="..."></div> Dans la feuille de style CSS: #logo { position: absolute; left: 10px; /* à modifier selon les besoins */ top: 10px; /* à modifier selon les besoins */ }
  5. LaurentDenis
    Du danger des simplifications... Ce que dit le HTML 4.0 Block-Level Elements du WDG est un beau racourci... qui crée effectivement une certaine confusion. <script> n'est pas alternativement un élément %inline et un élément %bloc. C'est un élément %inline uniquement. En effet, la DTD HTML4.01 stricte déclare: <!-- %inline; covers inline or "text-level" elements --> <!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;"> Où est <script> là-dedans ? Tout simplement dans %special : <!ENTITY % special "A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO"> En d'autres termes, <script> appartient à la catégorie %special, laquelle appartient elle-même à la catégorie %inline. En revanche, <script> n'est pas un élément %block : <!ENTITY % block "P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT | BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS"> ... là, pas de SCRIPT directement ou indirectement mentionné. (En revanche, on y trouve bien <noscript>) Alors... Comment fait <script> pour pouvoir se mettre directement dans <head> et dans <body>, qui n'admettent pas d'éléments enfants %inline ? Tout simplement en vertu d'un cas d'exception : <!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- document body --> <!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- repeatable head elements --> <!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- document head --> Autrement dit, <script> bénéficie ici d'un privilège qui l'autorise à figurer dans <body> et dans <head>. En HTML4.01 transitional, il en est de même, si ce n'est que <script> peut être mis directement dans <body> puisque l'une des particularités de transitional est d'y autoriser la présence d'un élément %inline. En revanche, on trouve la même règle d'exception pour <head> On est donc dans un cas très différents de <ins> et <del> qui eux, sont explicitement des éléments alternativement %inline et %block, selon les DTD. Maintenant, le problème reste entier : un <script> étant %inline... peut-il comporter des éléments %block ? Là, le WDG simplifie maladroitement : en effet, un <script> ne contient aucun élément HTML. La question ne se pose simplement pas. En revanche, il peut générer un élément HTML %block... qui n'invalidera pas le document, mais qui n'en sera pas moins problématique. C'est une des limites du HTML. XHTML résoud le problème, par exemple en faisant en sorte que document.write ne marche pas dans un script lorsque XHTML est traité comme du XML... Dans le même ordre d'idées, <script> peut permettre de générer la balise de fermeture d'un élément ouvert hors du script. Si javascript est désactivé... l'élément n'est plus fermé Là encore, ce n'est plus possible en "vrai" XHTML. Et puis, au fond, on le sait : javascript est intrinsèquement démoniaque
  6. LaurentDenis
    Ah... Pas simple, HTML4.01, sur ce coup là. Résumons: L'élément <script> est un élément de type%inline. Pour cette raison (et d'autres, mais passons sur les détails des DTD), il peut se placer, en HTML transitional comme en strict: - directement dans l'élément <body> - dans l'élément <head> - dans un élément %bloc - dans un élément %inline L'élément <noscript>, lui, est un élément de type %block. Il ne peut donc se placer (toujours en précisant qu'il y a d'autres raisons liés à des détails des DTD), que: - directement dans l'élément <body> - dans l'élément <head> - dans un élément %bloc La question est donc: pourquoi diable <noscript> est-il un élément %block et non %inline comme <script> ? A cause de leur contenu, qui est fondamentalement différent. En effet: - un <script> ne contient aucun élément HTML, mais ... du langage de script, c'est à dire d'une certaine manière du texte brut (en fait, c'est plus compliqué, car la présence d'un balisage HTML dans un script provoque un comportement spécifique du moteur HTML... mais passons. L'idée générale que c'est du texte est suffisante ici). - un <noscript>, lui, n'est pas destiné à contenir du texte brut, mais du balisage HTML qui devra être interprété directement par le navigateur comme n'importe quel autre balisage. Et ce balisage ne peut pas être restreint à des éléments %inline : il faut que <noscript> puisse comporter des éléments %block pour permettre d'afficher des titres, des paragraphes, des tableaux, des listes, etc. La plus grande permissivité du HTML4.01 transitional permet de placer dans <noscript> aussi bien du texte brut, des éléments %inline et des éléments %block. Ce n'est plus le cas en HTML4.01 strict, où il n'admet plus que des éléments %block. Mais l'important est là: dès lors que <noscript> contient des éléments %block... il ne peut pas être placé dans un élément %inline. Logique imparable, non ?
  7. LaurentDenis
    Si l'accessibilité est une de tes préoccupations, ce type de redirection est très problématique : certains de tes visiteurs n'auront pas le "temps" de consulter le contenu de la page d'avertissement (dans un lecteur d'écran par exemple, ou tout autre circonstance ralentissant leur lecture) et se retrouveront à leur point de départ sans comprendre pourquoi le lien suivi ne marche pas.
  8. LaurentDenis
    Il est en effet probable que, sur une machine un peu lente, le traitement de la page soit suffisamment long pour qu'un affichage progressif de ce genre se produise. Si tu souhaites inverser l'ordre de ton contenu pour obtenir <contenu> puis <menu>, tu peux conserver ton positionnement en float: - float:right sur le <contenu> avec une largeur en % - menu en flux de largeur donc variable selon les résolutions. Mais en fait: - si je ne me trompe pas, ton pied de page n'occupe pas toute la largeur d'affichage ? Auquel cas, la solution du menu en positionnement absolu est bien plus évidente. - et finalement, ce petit problème de rendu progressif est-il vraiment essentiel au point de revoir ta mise en page ?
  9. LaurentDenis
    Hem... Il doit y avoir, au bas mot et à vu de nez, plus d'une trentaine de raisons potentielles pour que des images d'arrière-plan CSS ne s'affichent pas. Comme on ne va peut-être pas toutes te les passer en revue, essayons un truc plus simple : - l'url de ta page web ? - ou au moins le code HTML et CSS concerné ?
  10. LaurentDenis
    Lafleur, en ce qui me concerne, et à la lecture de ton dernier message, le troll s'arrête là. (Et je suis très tenté de fermer ce sujet si tu continues à l'alimenter de cette manière). Pour être clair, inventaire des trolls :
  11. LaurentDenis
    Tout en renvoyant à mon tour au billet d'Eric ( http://blog.dreams4net.com/FudTrollEtUzine ) qui démontait parfaitement les erreurs à la base du discours d'Arno, je dois dire, contrairement à Denis, que ce "W3C Go Home" était aussi très pertinent, malgré son côté démagogique : il y a un Web de l'écran immédiat, indifférent à des problématiques plus complexes, qui a acquis une indéniable légitimité. C'est ce Web du Wysiwyg, du SPIP historique, de monsieur tout le monde, mais aussi de nombreux "pros" jugés conservateurs, qui s'exprimait dans cet article. Je ne crois pas qu'on puisse réduire sa résistance à de la paresse, à de l'incompétence ou au confort de l'habitude. Elle exprime un besoin plus profond. Ce besoin ne disparaîtrait d'ailleurs pas avec de nouveaux langages, quels qu'ils soient. Hixon demandait: "People obviously think they want a page layout language. How do we make them realise they have a page layout language (CSS), but that for the Good of the People they should work with semantics at the lowest level instead of working with formatting?" La réponse qu'on ne pourra pas, car ils n'ont pas vraiment besoin de différencier structuration et présentation. Ils n'ont surtout pas besoin d'un niveau d'abstraction élevé, mais uniquement d'un système concret de présentation à l'écran. XHTML ou tout autre évolution n'y changera sans doute rien : il suffit de voir aujourd'hui le code des skyblogs : du XHTML1.1 (sic) - CSS purement présentatif sans aucun rapport avec les exigences qualitatives de ce format. Les skyblogs en XHTML, c'est une énorme aberation. Pas en raison de leur contenu, mais parce que les objectifs poursuivis ne sont pas ceux du XHTML. HTML restera non seulement nécessaire, mais surtout inévitable en tant que format graphique. Oui, ce n'est pas ce qu'il est supposé être. Mais c'est ce que son histoire en a fait, et c'est ce qu'entérine HTML4.01 transitional. Je préfère de loin qu'on invite à se servir intelligemment du HTML en ce sens, plutôt que de susciter le rejet de la notion même de standard. Heureux de te l'entendre dire On s'est un peu trop focalisé, à mon sens, uniquement sur le rôle des navigateurs. Il me semble que les moteurs vont occuper à présent de plus en plus visiblement le devant de la scène, et le "nofollow" vendu sous son emballage "sémantique" n'est sans doute qu'un premier pas. Un simple constat : il existe aujourd'hui des navigateurs "conformes". Il n'existe aucun moteur "conforme". Et je ne vois aucun mouvement en ce sens chez les moteurs dominants du marché. Tout comme un navigateur en mode quirks, ils traitent de l'existant, dans l'immédiat, et avec toute liberté de modifier leurs pratiques au jugé.
  12. LaurentDenis
    La différence entre FOAF et XFN est que, dans le cas de FOAF, son extensibilité via les espaces de noms permet de d'étendre le langage afin de décrire autant de modes de relations sociales ou familiales qu'on le souhaiterait... Cette extensibilité n'est possible que parce qu'il s'agit d'un standard. Autre exemple, peut-être plus accessible: revenons au XHTML. Si le mode de structuration actuel du XHTML ne répond pas à tes besoins, tu as la possibilité de créer tes propres structures additionnelles, toujours par le biais des espaces de noms (C'est le XHTML modulaire). Et ceci, là encore, n'est possible que parce qu'il s'agit d'un standard : faute de quoi, tes éléments structurels personnels seront dénués de sens pour tout autre personne (et dans n'importe quel navigateur).
  13. LaurentDenis
    La permissivité des navigateurs proprement dite n'a qu'un impact limité, en fait. En quoi consiste-t-elle ? - les éléments HTML propriétaires ? Il n'en existe pas tant que cela (à titre indicatif, audioscope, bgsound, blackface, blink, bq, comment, embed, fn, ilayer, keygen, layer, limittext, listing, marquee, multicol, nobr, noembed, nolayer, nosmartquotes, plaintext, server, shadow, sidebar, spacer, wbr, xmp). Tous les navigateurs alternatifs en supportent quelques-uns parmi les plus courants, comme le célèbre marquee (Opera n'en supporte pas spécialement plus que les autres navigateurs). - les éléments HTML dépréciés par les spécifications (X)HTML strictes, comme applet ? Leur support n'a aucune chance d'être modifié, puisqu'ils font partie des normes transitional. - les extensions CSS propriétaires sont en forte augmentation... sous une forme à présent normalisée via CSS2.1 qui leur réserve une syntaxe spéciale (l'extension -o- pour opera, -moz- pour mozilla, etc) - le javascript propriétaire : peu de changement à prévoir de ce côté depuis l'adoption par Mozilla du support du document.all indétectable, il me semble. - le maintien de deux modes de rendu alternatifs: un mode de respect strict des standards, et un mode de rendu quirks assurant la compatibilité avec le comportement d'anciennes versions de ces navigateurs. On imagine mal sa disparition. Ce qui compte davantage, je crois, c'est le fait qu'HTML ne dictant aucun processus de gestion d'erreur, chaque navigateur recours à ses propres modes de récupération. Et là, effectivement, la question se pose : faut-il "coller" comme c'est souvent le cas au mode de récupération d'erreur du navigateur dominant, autrement dit IE, afin de limiter la casse dans le rendu des pages conçues spécifiquement pour celui-ci ? Le problème est que ce n'est pas toujours possible ni souhaitable. Opera, récemment, semble avoir plutôt revu légèrement à la baisse sa compatibilité avec le modèle IE. Par exemple, dans le traitement des dimensions attribuées abusivement à un élément en ligne non remplacé : la reproduction du comportement d'IE entraînait des erreurs ingérables par ailleurs... Enfin, par le biais des types de contenu, les navigateurs récents peuvent s'ouvrir au support de nouvelles normes (XHTML modulaire par exemple) sans renoncer à la compatibilité avec la "soupe de balise" traditionnelle. Et pour conclure, un constat : "monsieur tout le monde" (raccourci évidemment abusif) n'éprouve aucun besoin de faire des sites "sémantiques" (sic), "indépendants du média", "accessibles" ou autres qualités visées par les standards. Il cherche le plus souvent à faire un site essentiellement visuel. Il faudrait peut-être en tirer la leçon et accepter l'inévitable, c'est à dire une utilisation du HTML (il n'y a pas de X, et c'est volontaire) en tant que format résolument concret, par opposition aux nouveaux formats plus abstraits. J'avoue que quand je vois un éditeur WYSIWYG prometteur comme Nvu se tourner vers la production de XHTML strict... je n'en vois pas l'intérêt. Ne vaudrait-il pas mieux favoriser l'accès de 'monsieur tout le monde" à un HTML sans doute moins ambitieux, mais pour lequel les éditeurs sont plus aisés à mettre en oeuvre ? Tiens, sur ce coup, c'est moi qui vais faire hurler les puristes
  14. LaurentDenis
    J'ai du mal à voir la validité de ce raisonnement, qui consiste à dire: Il existe un processus de consensus... Je choisis de ne pas y participer pour y faire entendre mon point de vue... Ma non participation volontaire rend ce consensus discutable Coïncidence, j'étais en train de relire une critique adressée à un format développé hors du processus W3C, justement. Il s'agit de XFN, qui vise à exprimer les relations sociales à travers les hyperliens. L'un des points de la critique faite à XFN est justement que ce format, lorsqu'il s'agit de décrire les relations de type familiales : - reflète uniquement des modèles occidentaux, - et se limite, dans cette vision occidentale, à une définition très "bien pensante" des relations de couple. Limitations qu'on ne retrouve pas dans FOAF, autre format servant le même propos, mais dans une approche "normalisée W3C"... Je cite cet exemple pour montrer simplement que la recherche d'un "format standard" n'a rien de réducteur en matière culturelle, et que pour être un "standard", il doit justement éviter de tomber dans ce travers...
  15. LaurentDenis
    Une remarque : les spécifications, les "standards" si vous préférez, n'ont pas vraiment pour rôle premier de vous renseigner sur ce genre de choses. Ils ont plutôt pour but de permette l'élaboration et donc l'utilisation d'outils gérant cela à votre place. Ce qui est amusant, là, c'est que très peu de gens, avant de poser ce type de questions, passent simplement leur code à travers un outil comme "Tidy", dont le rôle est justement de gérer cela, en passant automatiquement les noms d'attributs et d'éléments en minuscules AMHA, avant de se poser une question sur la non-validation d'une page Web, on devrait d'abord voir ce que donne la même page après passage dans un outil tel Tidy. Par exépience, le gain de temps est considérable.
  16. LaurentDenis
    Juste une question, avant de commencer à produire des hacks et des bidouilles en série: pourquoi diable vouloir "passer d'une page à l'autre" sans recourir au mécanisme normal de soumission de formulaire ? - Qu'est-ce que tu y gagnes ? - Qu'est-ce que l'utilisateur y gagne ? Je suppose qu'il doit y avoir de bonnes réponses à ces questions.
  17. LaurentDenis
    Disons plutôt que le gain serait nul : - le problème reste entier lorsque le navigateur applique la CSS par défaut si celle-ci dégrade l'affichage dans la résolution du visiteur - tu peux de toutes façons créer une mise page CSS qui s'adapte à la résolution d'écran sans avoir à passer par javascript (ceci est vrai pour les résolutions desktop. Le problème est plus complexe pour les très petits écrans de mobiles ou le web-tv. Mais dans ce cas, c'est le navigateur qui procède aux adaptations nécessaires, s'il est bon). L'idée majeure est créer une mise en page "fluide", et non pas figée dans des dimensions rigides.
  18. LaurentDenis
    Pourquoi faut-il toujours boucler sur les mêmes questions ? La validité (X)HTML n'a jamais été supposée rendre un site accessible (Elle ne le rend même pas "conforme" à la norme (X)HTML visée, en fait). La validité n'est qu'un critère de l'accessibilité, parmi plusieurs dizaines beaucoup plus spécifiques, notament ceux visant la manière dont l'information est véhiculée par les couleurs, ou la façon dont celles-ci contrastent. Et l'accessibilité elle-même se décline en plusieurs niveaux. Et l'accessibilité ne peut faire l'objet d'aucune validation mécanique. Autrement dit un site "valide W3C", s'il prétend être ispo facto accessible, ne dit rien d'autre qu'une énorme sottise.
  19. LaurentDenis
    Tu sais bien que je ne hurle que sur les mécréants. Or ton <a> dans un <h1> est parfaitement canonique, et sanctifié par les plus hauts textes sacrés, comme suit : (Ce qui en langage profane signifie bêtement que les éléments %inline, dont le <a>, peuvent être mis dans les éléments %heading, c'est à dire <h1>...<h6> )
  20. LaurentDenis
    Ha, la vieux malentendu sur le rôle du W3C et des standards dont il permet la définition : cet organisme et ces standards n'ont aucune valeur ni aucune autorité, ni aucune légitimité en eux-mêmes. Et aucun auteur de page Web n'a d'autres obligations envers les standards que celles qu'il choisit d'adopter. Promoteurs et adversaires des "standards" oublient souvent: - que W3C ne fait que permettre une élaboration "sociale", collective, de ces normes qui font l'objet d'un processus (souvent jugé trop long) de critique, de tests, d'amendements, etc. Ce n'est pas le W3C qui édicte, qui choisit. Chaque organisme et même chaque personne intervenant sur le Web peuvent s'y associer. - que ces standards n'ont pas d'intérêt en dehors des objectifs explicites qu'ils ont reçu. Parmi ceux-ci figurent par exemple des notions comme l'interopérabilité, l'accessibilité, l'indépendance envers le media, la réutilisabilité du contenu, etc. Si, dans un projet donné, tu as d'autres priorités que ces objectifs, alors tu n'as en effet pas à te préoccuper des standards : ceux-ci sont totalement hors-sujet en ce qui te concerne. La "dissociation forme fond" en donne d'ailleurs un très bon exemple : revoir simplement la justification qu'en donne le W3C dans . Architecture of the World Wide Web : Si tu ne te préoccupe pas particulièrement de réutilisation du contenu ni d'indépendance envers le media de rendu.... ma foi, fort heureusement, comme tu dis, libre à toi d'user du Web à ta sauce
  21. LaurentDenis
    Je suis pris d'un doute affreux. Tu ne ferais pas quelque-chose comme : <div>Blabla bla blabla, <h1>mot clé</h1> blabla... <h1>Autre mot clé</h1>...</div> Par hasard ?
  22. LaurentDenis
    Voir HTML4.01: ( http://www.w3.org/TR/html401/struct/links.html#adef-rel ) On écrit donc simplement : <a href="document.html" rel="external nofollow">external link</a> Mais bien-sûr, rien, ni personne, ni surtout les inventeurs du "nofollow"... ne peut dire actuellement si "nofollow" sera pris en compte lorsqu'il n'est pas la seule valeur d'attribut. Il y a diverses autres incertitudes de cette ordre... Mais je suppose que c'est ce qui fait le charme des pseudo-spécifications inventées unilatéralement et de manière purement propriétaire
  23. LaurentDenis
    Dommage que l'ouverture du porte-monnaie soit devenue aussi difficile chez les utilisateurs du Web. (Précision: je ne parle pas de sortir son carnet de chèque en ayant au préalable discuté d'un emprunt avec son banquier, ce que nécessitent certaines autres applications parfois indispensables pour l'accessibilité, mais à la fourchette de prix nettement différente).
  24. LaurentDenis
    Opera vocal est actuellement en version bêta :ce n'est pas la version finale, mais une version de test. La version finale est annoncée par Opera... pour "le début de l'année" Pour la lecture en français, il faudra attendre qu'IBM adapte ses librairies vocales, puisque cette partie du navigateur repose sur la technologie d'IBM. Ni Opera ni IBM n'ont donné la moindre information sur la date d'une future version française.
  25. LaurentDenis
    Je ne suis pas allé très loin dans le site : parcours de la page d'accueil, de la page "Navigation au clavier", et dela page "Cinema" avec IBM HPR. Quelques remarques rapides, en vrac : - ton menu étant placé en tête de contenu, fournir un lien d'évitement de la navigation donnant accès directement au contenu. Et racourcir le "L'actualité de la ville de Cholet conforme aux recommandations du w3c sur l'accessibilité du web aux handicapés ", prodigieusement agaçant et inutile. - revoir le choix des accesskeys, inopérants dans de nombreuses applications. Tu as manifestement lu http://openweb.eu.org/articles/accesskey_e...non_transforme/ puisque tu en cites un extrait, me semble-t-il - écrire "cinéma dans le menu, avec son accent. j'ai eu du mal à comprendre ce que voulait dire le "sinnma" que j'entendais - écrire en toutes lettres les noms des jours dans le tableau des horaires de cinéma : "mer" est un peu déroutant.
×
×
  • Créer...