LaurentDenis

Une initiative à suivre (ou à aider ): Etude sur l'impact du support de document.all dans mozilla:

Bonjour simous, et bienvenue sur le Hub Kloobik (service gratuit) et kooliss.net (service commercial)... voilà deux entreprises complémentaires particulièrement intéressantes, et qui proposent manifestement des services de qualité ! Quelques questions/suggestions sur les kit Kooliss : - Connais-tu le récent référentiel Opquast des bonnes pratiques Qualité Web ? Je n'ai pas eu le temps de faire passer Kooliss à la moulinette des critères proposés, mais je pense que cela pourrait suggérer quelques améliorations du site (gestion du panier par exemple) - Il serait peut-être intéressant d'ajouter un critère "accessibilité" sur les kits proposés, voire de développer des kit spécifiquement orienté en ce sens ? C'est un marché porteur... - Sans se focaliser là-dessus, une mention plus explicite "avec/sans" tableaux de mise en page pour chaque kit kooliss serait-elle pertinente ? ça peut être un des critères de choix pour tes clients (apparemment, seuls les designs sans tableaux sont précisés, mais on met quelques temps à s'en apercevoir). - Un autre service que pourrait peut-être proposer Kooliss (sous réserve des questions de licence) : des kits graphiques spécifiques pour des CMS tels que DotClear, Mambo... Est-ce envisagé/envisageable ? Sinon, il va falloir que j'investisse pour regarder de plus près l'un de ces kits (tiens, la présence d'une CSS print, par exemple ?) En tout cas, ravi de te rencontrer sur le Hub : je sens que ça va être intéressant

SIAM : s'agit-il du Service d'Intégration des Aveugles et des Malvoyants des Hauts de Seine ? D'autres initiatives de ce type existent-elles dans d'autres départements ?

Pour nouer des contacts avec la "communauté Tolkien" francophone, te faire connaître et associer ton forum à d'autres initiatives, tu peux également participer au projet : wikipédia. Les articles de l'encyclopédie sur Tolkien sont encore peu nombreux, et le contenu existant aurait besoin de quelques bonnes relectures (par exemple, l'article consacré à Sauron). S'investir dans ce type de projet complémentaire de ton forum peut- être un bon moyen de se "faire un nom" et d'attirer du public

J'oubliais de préciser un détail peut-être intéressant : bon nombre de backlinks d'OpenWeb relevaient des weblogs, sites auxquels Google accordait un traitement de faveur (ce qui est sans doute encore vrai aujourd'hui, mais c'est peut-être un autre serpent de mer en gestation, ça).

Un cas bien concret d'anti-référencement souhaitable : These aren’t the pages you are looking for (désolé, c'est en anglais).

Openweb est un bon contre-exemple : la sortie du site (mars 2003) avait été précédée d'un long teasing et les backlinks (bon et moins bons) ne manquaient pas. Si ma mémoire est bonne, le positionnement du site n'en a pas souffert

Ces problèmes et les questions sont étroitement liées à la démarche purement "graphique" que tu as adoptée: photoshop > Image Ready > export HTML De cette manière, tu t'enfermes dans des contraintes de résolution d'affichage, de support Flash, etc. qui ne seront respectées que par une partie seulement de ton audience potentielle, et qui sont en fait étrangères au principe même de document web : celui-ci n'est pas spécifiquement destiné à être "vu" dans telle ou telle résolution d'écran. Il est destiné à être exploité par une très vaste palette de media, y compris des machines par définition "aveugles" (moteurs de recherche, traducteurs...) Plutôt qu'une démarche graphique, tu gagneras à adopter une approche plus structurelle de tes pages : - déterminer un gabarit HTML indépendamment des contraintes graphiques; - gérer la présentation graphique de ce gabarit avec un tableau de positionnement unique ou avec un positionnement CSS simple, pour ton menu gauche, ta bannière supérieure et ta zone de contenu. Le tout en unités relatives (pas de pixels, des %) pour qu'il s'adapte à l'ensemble des résolutions d'écrans. Tu rencontreras rapidement les limites de la mise en page avec un tableau, qui s'adapte beaucoup moins bien à la palette des résolutions possibles qu'une mise en page CSS. - réaliser alors tes éléments de contenu Flash/graphique pour les placer dans ce gabarit. Le but est de ne "négliger" aucun visiteur potentiel...

Dans : window.open(URL, windowName[, windowFeatures]) ...WindowName ne peut pas contenir d'espace : ce n'est pas un titre de fenêtre, mais un identifiant utilisable avec le target d'un formulaire ou d'un lien. Erreur de syntaxe. utilise plutôt (avec un WindowName vide si tu n'en as pas besoin): <a href=\"info.php?infos=$name_2\" onclick=\"window.open(this.href, '', 'height=75, width=250,toolbar=no, menubar=yes, location=no, resizable=yes, scrollbars=no, status=no'); return false;\">Infos</a> De la sorte, la page ouverte en popup reste accessible sans java script: - sans javascript, le lien est ouvert dans la fenêtre d'origine; - avec javascript, le return false interrompt l'action après ouverture du popup, et donc la fenêtre d'origine ne change pas. Et le popup lui-même est plus accessible: - l'utilisateur peut accéder à son menu s'il ne sait pas ou ne peut pas utiliser le clic droit pour imprimer l'info, par exemple; - comme il n'y a pas de barres de défilement, le popup doit être redimentionable au cas où des paramètres de police, par exemple, empêcherait la totalité du contenu d'être affiché...

je n'ai pas encore eu le temps de tester ce manbo effectivement prometteur. Quelques questions, si tu as testé : - Qu'entends-tu par compatible avec les moteurs de rceherche ? - Quelles sont les fonctionnalités spécifiques de manbo côté inclusion de photos-vignette ? - côté RSS produit ? Quel RSS ? 0.92 ? 1.0 ? 2.0 ? Atomz ? Feed des commentaires ? - commentaires : possibilité de syntaxe wiki ? Validité forcée du code produit ? - quelle articulation template (unique ?) / CSS ? - DTD utilisable selon les capacités du CMS ?

Bah... Tu te doutes de ma réponse : DotClear Blague à part, il répond à tes trois premières exigences, et la 4e est dispo via les DotClear personnalisés par leurs utilisateurs, en attendant d'être officialisée... cela dit, je serais très curieux de savoir ce que d'autres solutions de blog peuvent offrir dans le domaine photoblog...

Moi aussi, car les quelques recherches que j'ai fait ce matin sur le sujet ne m'ont mené nulle part, et m'ont laissé le sentiment d'une grossière erreur sur le fond de cette idée... (Quelque-chose sur le fait que les données ne seront pas transmises si la fonction incluse dans le onclick ne retourne pas True...)

Une chose que j'ai retenu des auteurs des specs ou de leurs meilleurs connaisseurs, c'est qu'une specification réserve toujours des suprises, et qu'on y découvrira toujours de nouvelles implications en la relisant, sous l'éclairage d'un problème bien concret, correspondant à un scénario (terme emprunté à K. Dubost, justement) donné... Donc, pas de pan sur les doigs, très Chère

Lecture trop rapide des specs, Monique ( http://www.la-grange.net/w3c/html4.01/stru...s.html#edef-MAP ) Cette utilisation de map est donc valide, mais à ma connaissance, elle n'apporte rien faute de support dans les agents utilisateurs... Que pourrait-elle apporter, dans un monde meilleur ? Rêvons un peu... - Elle identifierait la série de liens comme telle, que celle-ci soit par ailleurs contenue dans une liste, une liste de définition, un paragraphe, une série de div, ou un frigidaire sémantique. - Ceci devrait permettre à l'agent utilisateur de fournir de lui-même un moyen d'évitement de cette série de lien, ou un moyen de restituer la map en question sous une autre forme (section spécifique de la liste des liens extraits de la page, par exemple)... - Elle permettrait, avec l'ontologie appropriée, de repérer exactement les menus de navigation (title="navbar" par exemple), pour les exploiter, les éliminer lors de l'impression sélective du contenu... - Elle permettrait, toujours avec le vocabulaire normalisé approprié, de différencier au niveau de l'agent utilisateur, un menu de navigation (title="navbar") d'une table des matières (title="toc")... Bref, les scénarios d'utilisation sont multiples. Pour info, une pétition de principe de Jon Gunderson (l'un des membres du groupe de travail du W3C sur l'accessibilité des agents utilisateurs) relevée dans le forum de WebAim, datant de 2002, mais toujours valable: ( http://www.webaim.org/discussion/mail_message.php?id=845 ) On pourrait qualifier ça de méthode Coué

Hum... j'abonde dans le sens de Normand : si tu souhaites conserver cette popup, la solution toute indiquée est de passer la page du formulaire en (X)HTML transitional. C'est un peu un cas d'école sur le choix de la DTD transitional : le choix d'une DTD ne se fait pas sur des critères de "propreté" du code, mais sur l'adéquation avec les conditions de production de celui-ci. Et ici, tu ne contrôles pas la production du code de cette page (script imposé par un prestataire extérieur)... Ton code ne sera pas moins "propre" pour une page transitional au lieu de strict : ton choix de DTD sera en revanche plus rationnel et moins idéologique D'autant plus que les "astuces" envisageables en javascript (onsubmit ?) me semble passablement périlleuses...

Sauf erreur, il me semble bien que l'élément map est encore plus mal exploité par les navigateurs et dispositifs d'aide qu'il n'est reconnu par les validateurs C'est l'une des raison pour lesquels a été développée (hors normes d'accessibilité) la technique du lien d'évitement (skip navigation placé en tête de menu, et renvoyant à une ancre située au-delà du menu...

Merci Monique, j'aurais dû être moins paresseux ce matin, et le faire moi-même

Au passage, le problème était identique dans Opera. C'est bon itou

A vu de nez, utiliser une fonction valide du type getFullYear()

Je n'ai pas suivi en détail les discussions sur le sujet (elles devraient être détaillées prochainement par les blogueurs spécialisés dans ce domaine, je suppose). Mais il me semble qu'il s'agit, pour Mozilla, de pouvoir plus facilement concurencer IE en levant plusieurs obstacles à la consultation sous les navigateurs Gecko des sites "optimisés IE". En quelque sorte, pouvoir dire : "avec Mozilla, vous avez tout IE (y compris une partie du propriétaire) et plus encore". En tous cas, le changement relèverait plus de raisons de stratégie commerciale que d'autre chose.

Toutes mes excuses, Vincent : ce n'est pas parce qu'on est dimanche qu'on a le droit d'être malpoli, en effet Le "coder n'importe comment" ne visait pas spécifiquement ce que tu proposais... mais aussi bien le script de départ et les problèmes qu'il pose (voir l'article d'Openweb mentionné plus haut).

Plutôt que de coder n'importe comment, pourquoi ne pas faire proprement pour chaque image quelque-chose comme : <a href="..." onclick="window.open(this.href, 'Agrandissement', 'height=400, width=400, toolbar=no, menubar=yes, location=no, resizable=yes, scrollbars=no, status=no'); return false;"> (en reprenant la taille de popup de ton script de départ) Pour la couleur de background... franchement... Si l'image met tellement de temps à se télécharger que le fond par défaut en devient gênant, c'est plutôt du côté de l'optimisation des images qu'il faut chercher.

Ce n'est pas simple de faire la part des choses, mais oui, la permissivité abusive des navigateurs est un obstacle à l'amélioration de la qualité des pages. Tiens, un exemple très actuel, puisqu'il concerne les versions à venir de FireFox et Mozilla : pour améliorer la compatibilité avec les sites optimisés pour IE, Firefox supportera Document.all : - seulement dans le cas où le script présume qu'il s'exécute dans IE sans avoir vérifié auparavant que document.all fonctionne; - aussi bien en mode standard qu'en mode quirks; - avec une implémentation encore différente de celle d'IE... On a donc: - à l'origine une fonctionnalité propriétaire (Document.all n'existe pas dans le DOM W3C) dans un navigateur donné... - d'où des scripts incompatibles avec les navigateurs standards... - qui finissent par devenir plus permissifs jusque dans leur mode de respect strict des standards... - et surtout qui vont à présent encourager une très mauvaise pratique (utiliser Document.all sans au moins tester auparavant que le navigateur l'implémente).

Pas tout à fait. Le HTML s'est développé de manière anarchique, tiraillé et constamment enrichi par des implémentations propriétaires (guerre des navigateurs netscape / microsoft). Dans ce cadre, netscape a amené à produire autant de mauvaises habitudes de codage que microsoft Ce n'est pas la permissivité qui était en cause, mais les implémentations propriétaires. L'histoire de la spécification HTML3.0 avortée (1995) est assez instructive : elle comportait plusieurs avancées originales et très intéressantes... Mais cette spec était sans rapport avec les implémentations réellemet possibles à l'époque, d'où son abandon au profit de HTML3.2 qui intérinait bon nombre de compromis foireux. Actuellement, le problème est différent, puisqu'il faut faire avec : - des normes plus rigoureuses ((X)HTML4.01 strict, XHTML basic...) - des navigateurs conçus pour traiter de la soupe. Merci !

Ce qui est gênant ici, Wanbli, ce n'est pas l'erreur du webmestre. C'est le comportement déroutant du navigateur qui ne révèle pas l'erreur... ça n'aurait jamais dû marcher pour IE, ce qui t'aurais immédiatement amené à chercher l'erreur de codage. La permissivité des navigateurs face à un langage normalisé ne bénéficie pas auattn qu'on voudrait le faire croire à ceux qui utilisent ce langage...